great article highlighting how a programming language's design philosophy can make such a big difference - the UUID example, fantastic.
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 ;-)
Very fun article to read!
There's one catch: Go styleguides strongly recommend short variable names.
They do have a whole chapter about single/double letter vars [1] which boils down to:
They have their place, as receiver variables and in any place where the short name would be too repetitive.
It is hard for me to rebut all the points in this article because my experience is entirely the opposite save for the point of simple syntax.
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."
Maybe I haven't used Rust enough (still at the very beginning of the learning process) but the post fits my experiences.
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.
Verbosity in Rust I think is natural because of what the language is trying to achieve. It's understandable that people would rather not bother with it and I definitely don't advocate everyone use Rust (and definitely not use Rust for all their projects). A lot of times it is because Rust isn't the right tool, but the article is just comparing languages and not really their uses.
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.
I get why it might not matter depending on the work you do, but if non-trivial work is required just to keep your code building due to fast non-backward compatible changes in libraries you use, that might introduce hesitation.
Quantum number of dependencies for the uuid crate? By default it actually has none. If you were to enable the `v4` feature, it only pulls in `getrandom` for platform independent rng. All other dependencies are disabled by default or are dev dependencies used in tests.
State typing is there to enforce rules at build time. This can be an amazing thing to put on a problem where valid states aren’t obvious. Maybe I’m alone but I like stuff that enforces rules at compile time.
What I don’t like is getting phone calls in the middle of vacations or weekends. I like to optimize for that.
I'm also at the early stages of learning Rust, but looking at the comments regarding a large number of transient dependencies I can't help but wonder if a tradeoff is being ignored.
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.
16 comments
[ 3.2 ms ] story [ 44.4 ms ] threadI 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 ;-)
1: https://google.github.io/styleguide/go/decisions.html
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.
https://archive.ph/wip/hppQO
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.