That was informative... and it reinforced my perception of Rust as something to look into if I ever have to do something that absolutely necessitates the use of something low level like C++/Assembly. But for everything else that I can get away with (and that is a lot so far) I'll stick with Go because it's so much faster and shorter to write.
I think it's, in general, useful to differentiate the speed of code-writing as a new developer and the speed of code-writing as an experienced developer.
The reality is that people have very little time to try out new languages, and have to rely on anecdotes about the long-term cognitive costs of things like this.
My personal experience is that many of the seemingly more-onerous things about Rust end up falling away once the rhythm of programming sets in.
This is likely similar to how the error-handling approach of Go looks onerous at first, but seems to be something that doesn't slow people down too much in practice.
This is not obviously true to me, Rust provides more tools for building abstractions, even just "handle errors less manually"-abstractions, so they're possibly not that different (this certainly applies to the 'shorter' section).
I guess it may be true for the things Go is suited/designed for; time and experience will tell.
I'm pretty happy with the speed at which I write Rust code, but I can definitely churn out Go code more quickly. (Probably on the order of how quickly I can write Python, although refactoring Go code is much faster.) I'm not sure exactly why, but my guess is that there are fewer abstractions to deal with (and fewer opportunities to make abstractions). I have written several medium Go applications (near or above 10 KLOC, which ideally, I would never hit in a dynamic language), and I'm pretty happy with how the code turned out in all but one of them. (But that one is a window manager.) I haven't yet written a similarly sized Rust application, though.
I do write Rust code more quickly that I write Haskell code though. :-)
I was referring to "development using C++", which encompasses the language, compilers, build tools, code editors, ecosystem, basically everything that is involved when you're doing work and distributing result binaries.
There are IDEs that have their proprietary project formats that are incompatible.
Having header files makes refactoring by hand much more difficult than necessary, yet refactoring tools for C++ are mostly not possible.
Irregardless of IDEs, I'd still need to learn how to use cmake and other systems to build and use libraries. It's a large pain compared to `pip install ...`.
...need to learn how to use cmake and other systems to build and use libraries.
On OSes for which this is true you'd be forced to compile python yourself as well, because it's also just a dependency (of pip, for one!) written in a compiled language.
Edit: My point is: usually it's as easy as 'yum install', but on the rare occasion you will need to compile, I admit. However, that could happen with pip too; don't tell me its repos are always completely up to date. And in those cases it won't be quite as simple as 'pip install'.
