https://kerkour.com/should-i-rust-or-should-i-go
"Is Rust a great fit for this project?" I get this question quite frequently so I think it's time to write down my thoughts if it can avoid you some painful and costly mistakes. Short answer: no. Coming from someone who wrote a successful book about Rust (Black Hat Rust)
I think some raised points are relevant...
I know it's clickbait and all, but I can't really let their comments about "decay" go without saying anything.
I spent a weekend updating a Python project after updating the OS. Fuck Python's release methodology.
Yeah, Rust has a lot of releases, but they're all backwards compatible. I'm pretty sure a modern Rust compiler can compile any historic Rust program. Meanwhile every "minor" Python release has backwards incompatible changes and there's no guarantee of backwards compatibility at all. And that's without even bringing up the big major bump from 2 to 3 which... Was not handled well.
Honestly, if there's any language that people should be angry at for "decaying", it should be Python. Hell, even C and C++ have got this right.
I maintain a long-term Rust + Node.js project, and the Node side is the painful one.
Node makes backwards-incompatible changes, and doesn’t have anything like the editions to keep old packages working. I can end up with some dependencies working only up to Node vX, and some other deps needing at least Node v(X+1).
That's an issue with almost the entire js ecosystem. I'm part of a project that has rather high security standards, so we have to keep everything updated. The Java side is almost trivial, update some version number, let the tests run and you're fine. The js side is a constant battle against incompatibilities, weird changes for no reason and simply tons of vulnerabilities.
I'm of course only one single anecdotal sample, but the release cadence has probably been the least of my problems. My experience is that it's fine to not update for quite some time. I have a crate with 1.60 (released about one and a half years ago) as MSRV, which means I run unit tests with that version, as well as stable, beta and nightly. The only pressure to upgrade is that some dependencies are starting to move on. Not that the newer compilers reject my code, not even anything deprecated.
Also, small, frequent releases usually takes away a lot of the drama around upgrading, in my experience. Not the opposite. A handful of changes are easier to deal with than a whole boatload. Both for the one releasing and for the users.
That honestly makes me curious, what issues have you encountered when upgrading your python(3) version?
They removed a flag that didn't do anything any more. It also didn't hurt anybody, but since they removed it, my JavaScript project doesn't build on Python 3.11 and needs Python 3.10. I can't upgrade the version of node-gyp, because it's a transitive dependency of another package I can't upgrade.
So first of all, I had to upgrade something from Python 2.something to 3.something. I forget the specifics of what went wrong, but modern versions of pip just do not handle Python2 gracefully, at least when working with virtual environments. I tried to freeze to get a list of current dependencies, but pip freeze in a virtualenv just ended up writing out the system's packages, not those in the virtual environment. I get it, Python2 isn't officially supported any more, but at the same time, why is a language version not supported? Why is it not handled gracefully? This doesn't happen in other programming languages.
Anyway, as for bumping up through Python 3 versions. I used a framework to do most of the heavy lifting in my project, but I think Python 3.8 or 3.9 introduced some syntax changes which made it not compatible any more. Changing how string literals are handled, and adding/removing arguments to functions. So I had to bump to a new version of the framework. Of course, because this was a webdev project, updating the framework also meant changing my project itself because of the "move quickly and break things" mindset that they have. So yeah, bumping up through versions of my framework until I got to one which was officially supported with the current python version.
I also used a python program to automatically run some scripts on boot. Turns out a while ago they decided that they wanted to redesign how they did everything, so you have to know to use the 1.x branch (which is still being updated) rather than the 2.x branch.
It honestly feels like everyone has a mindset that anything you write in Python and Node will be perpetually updated, and that long term maintenance isn't a thing that happens. That you should always be using the latest version of anything.
And yes, I know I could probably work around all of this using Anaconda or docker or some other rube goldberg machine of programs. But I can't be bothered dealing with that nonsense. I just want to keep something I wrote many years ago running.
If I start a new webdev project, I'm just going to use some Rust framework for the backend, and plain JS for the frontend.
I think they introduce new keywords every now and then. Match and async I think?
Edit: I was wrong, this is done in a backwards compatible manner
Those doesn't break backwards compatibility though. Naturally you can't use match with a python 3.7 interpreter, but what scripts written for python 3.7 wouldn't work with a 3.11 interpreter?
I haven't encountered that issue before, so I'm curious what those problems OP have encountered looks like.
Huh, ok. I thought something like match = 0 in an old script might break a more recent version.
But you may very well be correct.
Some wheel didn't install for me, so I downgraded 1 minor version and then it installed. Some cuda wheel I think.
I work on a team that has some old projects in python that we're gradually deprecating. A major one is stuck on 3.7 because 3.8 added automatic async mocking (which is great!), but this broke the existing third-party async mocking framework and it's never been updated to be compatible with newer Python versions. So we'd have to invest time in porting all the tests from the 3rd-party framework to the standard library, but it's not worth it because we're hoping to deprecate the whole project soon anyway.
I think this old article exemplify the bad design of Go, and why I think Rust is very well designed.
TL;DR Go takes many shortcuts, in the name of simplicity, that ends up with pure lies. Like providing Unix like permissions for Windows and silently ignore it.
https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride
And don't get me wrong, I think Go is ok and I use it from time to time. When Go and Rust started to get traction, I actually laughed at Rust thinking it was a stupid language. Why would anyone use Rust when you had Go, it sounded so great with its go routines and all. I then started to use it, and it wasn't bad, but it wasn't something that got me all excited either. And it was the horrible error handling and all these simplifications that sacrifices correctness that made me feel it was only an ok language. It is the correctness of Rust and that you have to handle all errors aso, that makes it a bit annoying, but it is also these things that makes it great.
I learnt go first, and used it in production for years. I loved it at first. It made a lot of promises that I agreed with and it wa easy to learn. But over the years it fell short time and time again.i kept getting issues in production like forgetting to close a file handle ending up eating all resources or random panics from null pointers.
Then I started learning rust. It was not easy to do, I think I have up a couple of times before I really got it. But the more I learn it the more I love it. The promises it made have held up far better than gos and quite often now when I find an issue in some go I have written I realise that it would not even be possible in rust to encounter.
Rust makes sure the things you write are more correct so you spend more time upfront and avoid time spent sweating over issues in production and trying to figure out why something has now fallen over in the dead of night when you just want to be sleeping.
I don't mind the error handling in Go, what bothers me is a bunch of safety issues. For example:
println(interface{}(nil) == nil)
println(interface{}((*int)(nil)) == nil)
Depending on how your logical flow works, this can end up causing bugs in a very surprising and hard to detect way.
Also, you can call methods on nil values, like this:
type A int
func (a *A) doStuff() {
*a = 3
}
var a *A = nil
a.doStuff()
This panics inside doStuff, not at the call site, which can mean functions could run fine and fail later, making it harder to track down the nil value.
There's a lot of other footguns, especially as you get into multithreading. I started building code with Go back at 1.0, and they didn't turn on multithreading by default until 1.4 or 1.5 (I forget which), at which point our assumption that the built-in map type was multithreading-safe didn't hold (at least for assignments and reads). That was in the documentation, but the fact that it worked fine for multiple releases made it that much worse.
I still think Go is a fine language, but it should be limited to smaller scale projects like microservices because there are enough gotchas that the simplicity of the language hides for me to not recommend it.
It's not uncommon in the professional world™ to have a project that is left untouched for 3 years and then suddenly needs an update. Now imagine being the one tasked with updating the dependencies of a service that is 31 versions behind...
Yea you do rustup update and you're done because obviously it still compiles because it compiled before and there are no breaking changes. Funny how easy that was?