Rust Vs Go: A Hands-On Comparison
Rust Vs Go: A Hands-On Comparison
Rust versus Go is a controversial topic that pops up from time. In this post, we will compare both languages in the context of web development by writing a small web service which shows weather data in both languages.
Oh no, not another 'Is Rust better than Go?' article. Seriously, haven't we all had our fill of these comparisons by now? But before you sigh in exasperation, hear us out!
Permanently Deleted
0This isn't really true though. Rust has integrated versioning and it cordons things off between editions. If you're within the same edition, you get updates without breaking changes. Even if you aren't in the same edition, you can grab specific compiler versions. Granted, in these circumstances you won't get security updates, but you have to be very out of date for that to be a problem.
I wrote an app using brand new Rust features for work 2 years ago. Despite upgrading the compiler version several times, I never needed to make a single code change. It is still being used daily as well.
1You don't even need an old compiler to compile an old edition! That's part of the brilliance of the edition mechanism. An up-to-date compiler must be able to compile code from all editions; it can then statically link libraries from multiple different editions together.
1
Its already the case the language and ecosystem is so much in flux that code that's been written today has been made obsolete by a language feature in the latest nightly build.
This is just...not actually true, depending on what you mean by "obsolete". Rust has been stable since 2015; almost all code written for version 1.0 still compiles today.
Rust is risking of going the C++ way: have some many freatures bolted on that even as an experienced developer, you can checkout a random project on Github and discover a new language feature.
This is more subjective, but most of the current feature-stabilization work in Rust is not "bolting on" completely new functionality, but rather focused on reducing places in the language where different features are currently incompatible. This blog post is a bit old, but expresses what I mean: https://smallcultfollowing.com/babysteps/blog/2022/09/22/rust-2024-the-year-of-everywhere/
1code that's been written today has been made obsolete by a language feature in the latest nightly build
I mean couldnt you say that about any language? There's lots of old C code that's obsoleted by features in C11. There's lots of stuff written in python today that's obsoleted by stuff in the 3.13 alpha. It's just kinda how things go.
Doesnt the edition system prevent this from being too big of an issue anyway?
0I mean couldnt you say that about any language?
Looks at a standardised language like common lisp
The language itself has been locked for decades, but you've got libraries and compiler instructions that add features like OOP, strict typing, async, etc.
Long live the macro!
There's lots of stuff written in python today that's obsoleted by stuff in the 3.13 alpha
Didn't rust base a lot of its marketing on the promise that there will never be a rust 2, and that all code will be backwards compatible?
0Sure you could say it about “any language,” but I think you’re skipping a lot of nuance with your examples: python has notoriously had a long transition from 2 -> 3. C is 40+ years old, and the semantics and idioms of the language aren’t changing from month to month.
I think the parent comment is making the point that the pace of change and evolving idioms/features of Rust means that code you write today may need to be updated in a far shorter timespan than the typical timeline for working code (a few months, rather than several years). The bitrot is just a lot faster right now than other languages.
0