Programming vs. Software Engineering (Rust vs. Go)
kerkour.com
kerkour.com
In opposition to another comment here claiming the UUID example is fantastic, the author admits that their criticism is surface level at best:
"Here is a telling example: Go's most popular UUID library ... has 165 commits and 0 dependencies. Rust's most popular UUID library ... has 1594 commits. *I didn't analyze* why so many commits were needed to generate UUIDs, *but* something is clearly wrong."
When first starting a project with a REST interface (using axum and axum-login for auth) everything worked until like 1-2 month later when the login crate changed the interface completely. It wasn't much work to adapt but it feels like many crates are still in pretty active development and the recommendations on whats the current way to go change often.
Also regarding the syntax, it is often very verbose and if you start using async it gets even worse. I know it's still in development and as far as I know the async part is still far away from a full blown stable implementation but that doesn't make it more usable. The syntax isn't meant to be precise/easy to read but to encapsulate everything which otherwise might be a trap and fall on your feet later so I think a lot of the verbosity comes from the borrow checker.
Regarding the UUIDs, its a nice anecdote, it feels like it might point to something. On the other hand UUIDs do change (or at least get new features or versions) and the interfaces can be enhanced if the way the library is used changes. So I see why they would need many releases/commits but (without checking the GO library) I would expect it to be a fully functional UUID library with a good interface also.
If you build something in Rust and version lock like you would in any other package management system, why would you have issues with a dependency on something that is happily running and doing it's thing? If you must be on the latest version of everything, this is going to be problem in every language. I notice people tend to forget that not long ago everyone vendored their deps in Go for the same reasons and still do if stable is the ultimate goal. Save updating for when it's necessary, like security updates.
Be careful about just following the UUID anecdote. I actually did take a look at the commits for the Rust UUID crate. Frankly, it just seems to be popular and well maintained. Many commits are very small spelling and documentation updates. Rust has really great documentation features and the community is very good about leveraging those features. Go see for yourself.
Rusts verbosity (and thus, harder to read syntax) is there on purpose and it's nice you do not have to worry about a lot of things because the compiler does for you.
You are right with the updating part. I think what annoys me the most is that you often have to update (because you need feature x, just now released) and you will also get a new api. It feels (highly subjective here) as it is not yet so stable as in other languages.
I also scrolled over some commits from the UUID repo. You are right, the maintainers seem to be doing a good job publishing a good crate with great documentation and the required maintenance work.
What I don’t like is getting phone calls in the middle of vacations or weekends. I like to optimize for that.
For example take the implementation of the New Relic agent in elixir lang. There the maintainers at some point swung between using httpc or httpoison as the HTTP client. Neither of these clients are perfect and in some cases don't account well for scenarios like the presence of a Proxy. It would be better to able to switch to better, newer clients but unfortunately the project has the client baked in.
Now this problem can be simply attributed to the project, but something tells me while rust's "use your own building blocks" approach has bled into projects beign used here. This might result in some exessive tediousness for an end user, it is still a better approach to building apps in a language environment that is obviously still in early days.
I found it funny when I was reading, in the middle article there was an ad for a book to be a production grade Rust programmer - if anything, that article convinced me to go with Go ;-)