Why Rust and Not Go: A Rebuttal | Hacker News Reader

Why Rust and Not Go: A Rebuttal

blog.juliobiason.net

31 pointscodesections17 comments

Really 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.

[1] https://norvig.com/21-days.html

But Rust and Go have different goals.

If there was ever a definition of apples to oranges, Rust and Go would be it.

Depends on what axes you're looking at. There are a large class of tasks where 10 years ago I would have used C, C++, Python, or Java for, which I could now use Rust or Go and get an improved result with either.

> 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.

Not 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.

Agreed. Also, when someone says they have not written anything in some language, it makes me less interested in reading them ramble on about it (positively or negatively).

It comes across like: "X-Drink is better than Y-Drink, even though I've never tasted Y-Drink!"

Kudos to them for admitting that fact at least, I guess?

The original article is pretty well written and much more of a structured discussion than this one.

Both of these languages make people feel passionate in a way that other languages do not, and so we will continue to see these kinds of discussions, which I think is a good thing.

Better to have the overall software development community lively and engaged with the tools than cynical or disinterested.

> > The Go compiler is fast.

> Ah crap, not that shit again.

> The whole point is "compiler is fast, tests run faster". Well, what if I said the compiler would catch bugs before the tests? That would be even faster, 'cause then you can focus your tests on system behaviour, which is way more important than function behaviour or class/structure/module behaviour.

No.

A fast compiler is not only good for unit tests. And even when it comes to unit tests, it is not at all idiomatic Rust to omit them; on the contrary, unit test support is built into the language!

Rust having a slow compiler is a serious downside. The language has many upsides that can hopefully make up for it, depending on your priorities, but that doesn't make compilation speed a non-issue.

That said, the compiler is significantly faster than it used to be and hopefully will continue to improve as time goes on.

I don't understand how these 2 languages always get into these comparisons.

They are mostly aimed for different audiences and different purposes.

They'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.

> > As I already mentioned, Go was created to solve Google problems, and Google problems are definitely enterprise-scale problems.

> You know who has Google problems? GOOGLE! You know who else has Google problems? NO ONE!

That's true, but guess what, Google still uses C++ and Java for the vast majority of its critical infrastructure. So even at Google, C++ and Java reign supreme at handling "Google scale". And it's not surprising really, the maturity, performance, tooling, etc. available for Java and C++ are far superior to what golang has to offer. Not to mention both being far better languages than golang (even with how complex C++ is). golang is a weak language not suited for modeling complex domains.

Secondly, golang was developed by some employees at Google, not Google itself. And if it weren't for the brand name behind it, it would have gone nowhere.

> 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

I don't like the aesthetics of rust as a language, and I don't like the behavior of certain members of the rust community who vacillate between overzealous evangelism and dismissive rudeness.

As far as my understanding goes, I see this kind of comparisons as a "Please-consider-to" list to the language teams.

I'm a heavy Go user and light Rust user. I enjoy them both, and they gives me different set of advantages in return.

Please, don't use/treat comparisons as an attack, make it "So-this-can-help-me-do-that".

I totally see what the author of this post is saying, and I agree with most...But, that original post wasn’t half bad. It was entertaining and well written. I frankly don’t think anyone took it for anything other than an opinion piece.

Reply on news.ycombinator.com