Interesting. On the trifecta of money vs pain vs speed, Go seems to be a reasonable compromise.
- With Zig I kept running into compiler bugs, plus no package manager (I’ve vendored SDL and Clap into the source tree)
- C++ I’d occasionally shoot myself in the foot in ways that other languages would have caught, plus no package manager (OS-level package management does an OK job, so long as you don’t mind using old versions, and faffing about with different operating systems acting very differently)
- The pain from Rust was one time where the compiler wanted me to specify a lifetime, and I didn’t understand, so I just spammed lifetime specifiers in various places until it compiled. I’ve been using Rust for a couple of years now and I still don’t really understand lifetimes, but thankfully 99% of the time I can avoid them.
- Nim was a relatively nice language but massively lacking in available libraries (like even parsing command line arguments took me a day just trying to find a library which worked)
- Go is pretty nice, my main pain is the tolerable but constantly-annoying verboseness of error handling (`err := foo(); if err != nil {return err}` compared to rust’s `foo()?`)
- PHP I just hate on a deep and personal level thanks to years of being a PHP4/5 developer. The language is actually mostly-ok-ish these days, but the standard library is still full of frustration like inconsistent parameter orders within a family of functions.
- Python is all-round really nice to write, but the test suite takes like 20 minutes to run, which really messes with my flow-state
" I’ve been using Rust for a couple of years now and I still don’t really understand lifetimes"
Seems like a major pain point.
They do look intimidating to start with, admittedly, and I'll concede that's a negative point for Rust. But it does get better if you practice for a bit.
Lifetimes are necessary when you want to explicitly say "variable X will live just as long as variable Y", or sometimes it's more complex (i.e. you have to specify 2 or more separate lifetimes and then return something that pertains to only one of them) but it's still fairly predictable if you keep it all in your head while coding.
Don't get me wrong I still hate it but it's not as terrible as many people make it out to be. It's hard to get into but also very logical and graspable.
I ran a quick pprof and indeed it's spending a lot of time in cgo:
Showing nodes accounting for 28720ms, 67.67% of 42440ms total
Dropped 145 nodes (cum <= 212.20ms)
Showing top 10 nodes out of 53
flat flat% sum% cum cum%
13080ms 30.82% 30.82% 16600ms 39.11% runtime.cgocall
4720ms 11.12% 41.94% 4750ms 11.19% main.(*RAM).get
2840ms 6.69% 48.63% 33070ms 77.92% main.(*GPU).tick
1970ms 4.64% 53.28% 3720ms 8.77% runtime.mallocgc
1450ms 3.42% 56.69% 1470ms 3.46% main.(*RAM).set
1160ms 2.73% 59.43% 41350ms 97.43% main.(*GameBoy).tick
1000ms 2.36% 61.78% 3160ms 7.45% runtime.exitsyscall
890ms 2.10% 63.88% 1610ms 3.79% main.(*CPU).tick_interrupts
820ms 1.93% 65.81% 850ms 2.00% runtime.casgstatus
790ms 1.86% 67.67% 5530ms 13.03% main.(*CPU).tickThe other languages are also using SDL via their respective interacting-with-C interfaces - what makes Go special here?
https://stackoverflow.com/questions/28272285/why-cgos-perfor...
Even if it is SDL slowing it down, Go FFI being slow is still a real disadvantage compared to the other languages, and you can't just pretend like it doesn't exist in this case.
By these standards a 10 year old cpu with a beefy GPU will beat any new cpu as well.
It absolutely does. A simple for loop in the standard Python interpreter will literally take 100x longer than the same thing in a language like C/C++, try for yourself if you don't believe me. CPython is unbelievably slow.
I couldn't reproduce 100x (no optimization flags, otherwise it won't do anything)
Apple clang version 14.0.0 (clang-1400.0.29.102) -> 0m0.347s
ruby 3.1.2p20 -> 0m11.314s
Python 3.8.12 -> 0m19.662s
I thought the differences would be smaller these days