this post was submitted on 01 Oct 2023
22 points (89.3% liked)

Golang

2197 readers
1 users here now

This is a community dedicated to the go programming language.

Useful Links:

Rules:

founded 1 year ago
MODERATORS
[email protected]
[email protected]
[email protected]
22
Rust Vs Go: A Hands-On Comparison (www.shuttle.rs)
submitted 1 year ago by [email protected] to c/[email protected]
13 comments fedilink hide all child comments
 

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!

top 13 comments
sorted by: hot top controversial new old
[–] [email protected] 4 points 1 year ago (7 children)

However, don’t underestimate the long-term benefits of Rust

I think the author is underestimating the long term issues with Rust. 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. 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. That is not a good situation for projects that require longevity, especially in a professional setting. When working on software in a professional setting, you will often have cases where you revisit code bases that you have not touched for half a year. You will have a hard enough time to stitch your thoughts on how your business cases worked back together. You really don't need syntax patterns that you haven't seen in half a year to get on your way.

Using Rust for projects with a long lifespan requires something from developers that we are especially bad at: the ability to be disciplined when presented with new, shiny things. Go on the other hand has this by design, which makes it admittedly boring but also relieves you of such burdens so you can focus more on getting things done.

[–] [email protected] 9 points 1 year ago

I’ll have to disagree with this. Adding new features is a problem if old things break but otherwise it just makes future programs easier to write.

You should be writing your next set of code with the newest features if they cut down dev time, cut down bugs or make that area more maintainable

[–] [email protected] 6 points 1 year ago (2 children)

code 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?

[–] [email protected] 3 points 1 year ago (1 children)

Sure 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.

[–] [email protected] 2 points 1 year ago

Updating the language doesn't mean the code will be broken. It just might just not be the best way to do thst anymore. Like a lot of traits I have written over the years got similar ones in std now and I could switch to them, but my old code still works.

[–] [email protected] 0 points 1 year ago (1 children)

I 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?

[–] [email protected] 1 points 11 months ago

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?

I think that's Golang, not Rust

[–] [email protected] 4 points 1 year ago

I don't have an opinion in this debate. I just started playing with Go and planning on doing so with Rust.

I wanted to point to the fact that Go is also in flux and is also seeing changes to its semantics, and this is relavent in the current events with Go 1.21 being released less than a month ago.

https://go.dev/blog/go1.21

In a future version of Go we’re planning to address one of the most common gotchas of Go programming: loop variable capture. Go 1.21 comes with a preview of this feature that you can enable in your code using an environment variable. See the LoopvarExperiment wiki page for more details.

[–] [email protected] 4 points 1 year ago (1 children)

This 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.

[–] [email protected] 3 points 1 year ago

You 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.

[–] [email protected] 2 points 1 year ago* (last edited 1 year ago)

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/

[–] [email protected] 1 points 1 year ago

Coming back to code after a year is hard regardless of language. I’ve had C code I came back to after a year that was dead simple language feature wise but hard as hell to follow business wise. I would actually argue more modern features like Union types in typescript has actually made it easier for me. “Oh this function has to handle two cases of objects an object with an id and without an id”

[–] [email protected] 1 points 11 months ago

I disagree. Rust has editions, in which long term stability is guaranteed. On top of that the stdlib has guaranteed backwards compatibility as well. You're not required to chase nightly (and you shouldn't).