this post was submitted on 01 Oct 2023
21 points (88.9% liked)
Golang
2161 readers
9 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.
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”