Oddbean new post about login | logout I'm not sure how to continue my programming journey, so I'm asking here: I've only ever used Python, and I love it, except when it's slow (which is *always* when you're interested in writing very efficient graph algorithms like I am). I like simple, clean code, I've mostly never used objects or classes, they're not particularly useful for what I'm doing. So, after some research, I am thinking about learning C or Go. The thing is, C is much more widely used and supported, but I don't want to become a hardcore developer who has to manage memory and shit. I want to be a mathematician who can write good code, that's all. Also, I like that Go makes concurrency easier, at least that's what I've read, which is something I'll need to use a LOT because of the particular algos I have in mind. What do you guys recommend? cc @mleku
In a choice between C or Go I recommend Rust
lol. why?
Because that is where it sits. It is as perfomant and capable as c but safer than go. For distributed and secure systems it is probably the "right" language.
"safer" what is safer about a language that has macros and the ability to tamper with memory directly versus another that has a lot of obstacles to doing this kind of tampering? the only difference in memory safety between the two languages is you can get a performance problem in Go if you just fling out a bazillion new buffers for no reason, use them once and then forget about them... and then you need to consider a freelist there is no buffer overflow vulnerability in valid code in either language i tell you what the safety problem with rust is the protocol has to be designed to be secure, most vulns these days are protocol level not buffer overflow so, Rust is fixing a problem from 20 years ago with an overly complex syntax that really is just hints for a really dumb GC, and go has a sophisticated, 15 year old GC that builds upon its own experience and that of Java's GCs and other GC using languages this "safety" thing is illusory what's unsafe is hard to read code, and complex syntax and the red flag is that it takes 100 times longer to compile it
Ok fine, good points all. But it is safer in that I don't have to tell my friends that I program in go. I use rust, I don't have any friends.
what has programming got to do with your social life exactly? how does this in any way have anything to do with the best choice for writing simulators for a mathematician who is not greatly experienced with programming? most mathematicians and similar pick python because of its simplicity Go is simple also, but if you are doing large graph calculations like WoT then it's also 10x faster safety has nothing to do with his question, nor does your social standing with your hipster mates
Sorry, that was me admitting I was wrong and throwing in some self-deprication.
i have used go to write complex dynamic adjustment algorithms that do EMAs and suchlike over prescribed time windows of data, structs are quite memory efficient and can map graphs quite nicely... the default normal size of array indexes is 32 bits so you can use them in place of 64 bit pointers in data structures, and quite efficiently represent lookup tables between longer values and these serial values to do really big stuff you have to go with pointers but if you are gonna have under 4bln nodes in your graph you can do it more efficiently with arrays i'm pretty sure this is along the lines of how 3d rasterizing mesh graphs are represented in memory, i know for sure that 32 bit integers are the main thing you deal in on a GPU (they only have 32 bit integer dividers, for example) i'd say for the most part, 32 bit array indexes for nodes and 32 bit floating points are gonna be plenty of precision for your algorithms and it's really easy to do this in Go also, just to explain something, arrays in go are like structs, they are constructed the same way as C but the dynamic sizing stuff is taken care of automatically for you, though if you really have a lot of growth in arrays you save a lot of time shuffling memory by over-allocating compared to the default (which is a doubling cycle iirc)
If you want something high performance but don't want to go low level, I can't recommend julia enough. Syntax is clean, JIT compiles, multi processing/threading is simple. You can even use Python libraries for anything that isn't implemented in Julia - meaning after doing anything requiring performance you can use Sklearn for extra analysis and matplotlib for plotting. Deep learning and autodiff libraries, while not fully fledged out as Python's ecosystem is 🤌
Yeah, that's an interesting suggestion, thanks! Some people I know in academia use Julia and love it
Feel free to reach out if you need some advice, always love going back to it when I can. Used it for some dynamical systems a while back and did 99% of my deep learning assignments in Julia. Here's a code comparison of PyTorch vs Julia implementing AlexNet https://i.nostr.build/ZLXx.png https://i.nostr.build/rayB.png
depends what you want to code. think about what you want to create / work on then narrow down your list.
R
Have you considered Haskell or other functional languages? Haskell is often the favorite of Math-ier minds.
not yet. I've used Mathematica, it was cool but the fact that it's proprietary it's a super no for me.
Try Haskell! "Learn you a haskell for great good" is the oft-recommended source. I have a copy, DM if you want it
Go fits best to your profile "mathematician that can code". You can learn it fast, and its a powerful and safe language. C has way more gotchas and its much more tedious to write larger applications in it than Go. Great for understanding how computers work but wouldn't recommend it for your use case. I enjoy Rust most, it's package manager is great, there are tons of useful libraries and you can develop quality stuff in a very reasonable pace. But the learning curve is steeper than Go, not sure if you have the motivation/need for it.
learning curve for a 4 year experienced Go programmer on Rust was nearly 2 months until i sorta almost understood lifecycle annotatations, and was able to write a servicable microservice for gRPC/Protobuf on Go, concurrently, i was writing a tutorial how to do the same thing and it would take you a weekend to go through it really thoroughly and be able to instantly adapt it to any data architecture you had in mind
I've been programming in Go for about 7 years and have come to appreciate it's simplicity and speed. I call it baby C because it's almost as powerful but a lot more expressive and easier to use. Rust is a dumpster fire designed by eggheads and l33t hipsters who think they are solving the problem of poorly written code by beginners but have just made the problem worse with their assumptions.
You can either learn it yourself or trust the language to do it for you. It's only tradeoffs. I'm a C engineer because I want control, it's that simple.
That makes sense, and I have an answer, I trust engineers like you more than me in dealing with low level stuff. So probably not C
It's also crazy how many opinions there will be, and it turns out any language is only as performant and safe as the person writing it, and the algorithms used. I'm pretty fluent in like 5 or 6 languages and I continue to gravitate toward C-ish languages. I can write much better, large scale applications in C# than I can in C generally. So I cut out the high performance components, write it in C and link my C# app at load time. It also depends on how much time you want to spend farting with things too. For me, I've spend hundreds of hours hacking C# to avoid the GC and work directly with memory when I need to. I suggest trying a few langs and seeing what sticks. Most languages will get you there, maybe you could make a list of YOUR OWN tradeoffs and avoid some online opinions for the time being. It matters what you can write best in. Finally, I'm not a traditional developer, I generally don't prioritize the standards that (what I call) "trade" developers care about, such as readability being #1. I refuse to sacrifice obvious efficiency for the sake of it being easier for lazy and whiny developers to read. If it happens it happens, but it's like 3rd on my list.
there is no question that C is more complicated to learn than Go, but Go gives you a lot of teh performance (about 90%, and the main limitations are that Go is not so good at parallelism compared to using pthreads) i'd also suggest trying C because it's pretty good for writing simple mathematical algorithms with, but the implicit types get messy, and personally one of the things i hate about Go is the fact that the `int` type is 32 bit on 32 bit hardware, and you see this sometimes in code, people using explicit int64 (signed) in a lot of places even though in practice, almost nobody puts serious servers on 32 bit processors
I think it's fair to say threading it's an apples to oranges comparison because there isn't a pattern or a standard library in C for threading. So if you need jump into a highly multi threaded or even async, C probably isn't it. Not unless you want to spend a bunch of time implementing the patterns yourself. I think as a fun analog, in noscrypt I implemented the concept of a Span taken from C# to help me more safely work with buffers, except with macros and inline functions to make it nearly invisible when compiled. > i'd also suggest trying C because it's pretty good for writing simple mathematical algorithms with Completely agree on this! >but the implicit types get messy Also yes, some libraries work well with an int being 8,16,32,or even 64 bits wide without your knowledge. I usually use explicit types but many libraries don't because it can often be easier to trust the compiler to manage sizing correctly for you. That takes more brain power than I wanted to dedicate to noscrypt right now, but I may switch back to implicit types for compat reasons.
using the pthreads library would be a bit more performant than Go's concurrency if you can fan out your processing for bulk stuff like what nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qgkwaehxw309ash2arg9ehx7um5wgcjucm0d5hsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshsqg8ks058qd0h4485fc9e3naaj5m7zez44ykd8r80cn9nrkm42l677g2aakns wants to do, and really the flexibility of Go's concurrency is overkill for simple parallel work, it's a little confusing to do it that way, it's more optimized towards event processing for servers, but the design of it was originally created for GUI (newsqueak) go is actually not so great at parallelism, you can gain as much as 20% even while adding the overhead of an IPC and using single threaded worker processes (at least that was the situation in 2020, not sure maybe they have improved it by now) - but having said that, it's so much faster than for example python or javascript, that losing that last 20% of parallelism is probably not gonna hurt that much, and if you want it scaled up that much, like on a threadripper or epyc or something, well, you'd probably not be using Go, but C and pthread go is pretty fast for single thread processing, not much slower than C, especially if you don't allocate and discard a lot of memory, walking trees and graphs is cheap, everything stays on the stack/registers but yes, explicit types are a thing... i ported a hamming code algorithm from C some years back and the hardest part of the process was figuring out the implied bid widths, and this is pretty much par for teh course with C, your use of explicit types is probably a bit uncommon among C programmers personally, i would remove the distinction in Go where on 32 bit hardware it treats the `int` type as 32 bits... it should just always be 64 bits, except where used in array indexes, this is one area it's implicit, and 64 bit array indexes is a waste of space, ain't nobody got that much memory lol, but it's not a difference that anyone really encounters because Go on embedded 32 bit devices is pretty much not a thing, except for tinygo, which is not really go, though it is go (has more controls for memory management, but still lets you do all the nice interface/dynamic array stuff, and Go's concurrency can even operate on a single thread
Also as you get into it, you'll hear the term patterns. TLDR patterns are the way to use the language and standard libraries to perform operations, usually in an engineered way. Such as the way you store variables, call functions, lay out your functions, store state, pass variables and so on. https://en.wikipedia.org/wiki/Software_design_pattern New users heavily rely on patterns documented in the language articles and APIs as the intended way to use a language. This also means there is a large cycle of influence on patterns between users, and languages. PHP was intentionally designed to have very straightforward design patterns for an easy learning curve at the sacrifice of mostly performance IMO, which is the reason why Larvel and other "hacks" exist. That said, C's design patterns are mostly made up by developers on the fly, some classes teach a "standard" patterns based on some well known publishers, but its such a free language nearly every C project you look at has a totally different design pattern, it's very anarchistic and I love every ounce of it. I think because of this it's easy for C to apply the "unsafe" moniker, the language doesn't enforce any sort of safe patterns by design IMO. That's where things like C++ come in and it's standard library come in. Nearly every proficient C developer will have a blog post on their website expressing their ideal design patterns they expect the world to adopt, and I've taken influence but, no one C library or exe is written the same :) I started in electrical engineering, so C was the first logical language we learn beside VHDL and other hardware description languages, and assembly of course. My brain works loosly assembly and C is a pretty close logical mapping and it can be rather simple to assume what the compiler will do with your code.
let me just put it this way: when i was 12 years old, i got to do a stint of some kind of work experience at the Department of Primary Industries, in my home town of Toowoomba i was being supervised by a guy who wrote simulators for crops that models rainfall, genetics, etc... his main go-to language was Forth if you know Forth, it's like one step away from Assembler in my time there i learned a bit about C and Lisp, lisp was very cool, but for doing math, the C and Forth were the best options back then (1988) it's not that i'm some kind of a fanatic about the language i prefer, it's literally really easy for doing this kind of work, easy syntax, you will probably grasp it mostly straight away, and everything as regards to mathematics is very explicit, though if you need to do work with sets, you have to write your own stuff, and scaling it up gets complicated because of thread safety with maps, and the last point is not only simple, but fast
Uh sounds kind of silly, but also maybe consider building a team if possible? Then get crack smoking engineers like myself to do it for you?? Less time implementing and more time designing? That's how @liminal tricked us XD
why silly?
Not everyone wants to depend on others nor want a to work with a team etc. The idea of me telling you to "just get a team that will work with you for no money on your projects" is a bit laughable on the outside is all.
I make no claims to trickery! nostr:nprofile1qqs06gywary09qmcp2249ztwfq3ue8wxhl2yyp3c39thzp55plvj0sgprdmhxue69uhhg6r9vehhyetnwshxummnw3erztnrdakj7qguwaehxw309a6xsetrd96xzer9dshxummnw3erztnrdakj7qgcwaehxw309ahx7um5wgh8xmmkvf5hgtngdaehgtcw45ql5 on the other hand... 🤣
little update; - C is nice but not for the faint of heart - C++ I found it to be C with added garbage that one has to learn not to mess up memory - Go is beautiful, thanks @mleku for letting me discover it I am following https://quii.gitbook.io/learn-go-with-tests and fucking hell, finally a guide for noobs that explain to me how I should work and think when I program, how I should do tests and so on. nostr:note1jvr0e5vk2386r3ne3kwme7vms7lkewvzn8vhh0qjk9qsgx4d834qf9l78p
Good luck on your journey, but know that you will have artificial intelligence both as an ally and a rival, as it is constantly improving and creating complex code, which is reducing the market for many programmers. I also program in Python, and I had to reinvent myself and use tools to my advantage. I confess that at first, I was reluctant because I prefer the traditional method of doing things. However, in a market that increasingly seeks speed in everything, I ended up expanding my knowledge to other areas, including low-code and no-code platforms. There, we can do a lot of things relatively quickly, take the code, edit a few things, improve it, and some platforms even include AI. So how much time do we gain using this? The future is heading in this direction, so we must adapt.
If I had to pick a next language to learn, it’d be Elixir. Concurrency and fault-tolerance are built into the language. It is built on top of the Erlang VM which was specifically designed to handle concurrent workloads at scale.
