this post was submitted on 01 Oct 2023
23 points (89.7% liked)
Golang
2207 readers
3 users here now
This is a community dedicated to the go programming language.
Useful Links:
Rules:
- Posts must be relevant to Go
- No NSFW content
- No hate speech, bigotry, etc
- Try to keep discussions on topic
- No spam of tools/companies/advertisements
- It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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?
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.
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.
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!
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