Why Rust and Not Go: A Rebuttal
blog.juliobiason.net
Why Rust and Not Go: A Rebuttal
1–10 of 19 posts
Re: Why Rust and Not Go: A Rebuttal
#2Really who cares?
Pick a language. They are both fine. Both will probably solve whatever problem you have without too many issues. Arguing over which one you should use its probably pointless 99% of the time.
I wish I had a link to the twitter exchange between both accounts where the answer they both agreed with was learn both, and lets have this conversation in a week. It feels 100% relevant here.
Re: Why Rust and Not Go: A Rebuttal
#3I don't understand how these 2 languages always get into these comparisons.
They are mostly aimed for different audiences and different purposes.
Re: Why Rust and Not Go: A Rebuttal
#4Not sure how good the original article is, but this is a poor rant.
And I very much dislike Go as a language.
Re: Why Rust and Not Go: A Rebuttal
#5Really who cares? Pick a language. They are both fine. Both will probably solve whatever problem you have without too many issues. Arguing over which one you should use its probably pointless 99% of the time. I wish I had a link to the twitter exchange between both accounts where the answer they both agreed with was learn both, and lets have this conversation in a week. It feels 100% relevant here.
Programming languages are tools that require significant career investment. Sure you can learn the basics in a 21 Days[1], but that's not going to land you a Senior Developer salary. You're choosing a horse to ride for many years, and if you chose the wrong horse, you're going to find yourself in a crimp.
But horses/languages don't have value in a vacuum. They have value because the industry recognizes them. You'll have fewer options if your main expertise is D or OCaml than if you're a C++ developer.
So you get advocacy posts about this or that language to increase their recognition in the industry. Attract developers to build the libraries and ecosystem needs. Attract developers to improve the compiler in ways that are useful to everyone.
So you need to cheer for this horse over that horse, because your career depends on it.
Re: Why Rust and Not Go: A Rebuttal
#6> Honestly, I haven't seen -- even with Rust -- something as dead simple as Flask
What about warp? https://github.com/seanmonstar/warp/blob/master/README.md
Re: Why Rust and Not Go: A Rebuttal
#7Really who cares? Pick a language. They are both fine. Both will probably solve whatever problem you have without too many issues. Arguing over which one you should use its probably pointless 99% of the time. I wish I had a link to the twitter exchange between both accounts where the answer they both agreed with was learn both, and lets have this conversation in a week. It feels 100% relevant here.
Programming languages are tools that require significant career investment. Sure you can learn the basics in a 21 Days[1], but that's not going to land you a Senior Developer salary. You're choosing a horse to ride for many years, and if you chose the wrong horse, you're going to find yourself in a crimp. But horses/languages don't have value in a vacuum. They have value because the industry recognizes them. You'll h…
But Rust and Go have different goals.
If there was ever a definition of apples to oranges, Rust and Go would be it.
Re: Why Rust and Not Go: A Rebuttal
#8They're just fundamentally for different things. For most classes of problems where the distinct features of one or the other would make any difference, if you're choosing between Rust and Go, then you may consider that you might not entirely understand either your problem and/or why either of these should be considered as part of a solution.
We chose Rust for a bunch of reasons related to enabling high-assurance software development with better ergonomics & efficiency than attempting to do the same with C and bolting a bunch of disjointed augmentations onto either it or its toolchain.
Substructural type system + HM type system + ease of integration into embedded targets is fantastic for the platform we're building and the markets we're addressing. Using Go would make no sense at all for us, but may be perfect for a use case where the same kinds of guarantees & assurances aren't necessary.
Re: Why Rust and Not Go: A Rebuttal
#9Not sure how good the original article is, but this is a poor rant. And I very much dislike Go as a language.
Agreed. The original article made a good point of the language being simple (feature-light) makes it appealing for enterprises, as an alternative to Java, for building enterprise solutions. Go is easy to pick up and the language is opinionated, forcing teams to adhere to a uniform way of doing things.
I was interested in a rebuttal which would address these points. Instead, it comes across as just addressing the points in the article as an attack on Rust.
Re: Why Rust and Not Go: A Rebuttal
#10Really who cares? Pick a language. They are both fine. Both will probably solve whatever problem you have without too many issues. Arguing over which one you should use its probably pointless 99% of the time. I wish I had a link to the twitter exchange between both accounts where the answer they both agreed with was learn both, and lets have this conversation in a week. It feels 100% relevant here.
> learn both
This is a common advice but it isn't realistic.
It takes a lot of time to learn a language, its tools, its most popular libraries, its best practices, to interact with its community, to see in what problem domains it shines, etc.
I'd say you need to give it more than a year, more than two if you're not doing it on the job. You can churn code much sooner than that obviously, that's not what we are taking about.
Nobody does that to see which language is best. And those that do are doing it superficially, writing a hello world or two and then jumping to conclusions.
This advice basically makes no sense and yet people keep repeating it.