Should I Rust or Should I Go? (opens in new tab)

As someone building my startup [0] on Rust (and a fan of the language since ~2014) I don't think this is a very compelling list of points.

> Rust is overhyped

People are excited about Rust! Not sure why this is a reason you _shouldn't_ use the language.

> Rust projects decay

The text doesn't match the headline here; Rust takes backwards compatibility very seriously, and rust code I wrote in 2016 against Rust 1.10 still compiles with Rust 1.72 in 2023.

> Rust is still in beta

Mentions missing async traits, which is legitimately annoying, but the workaround with the async_trait crate works in practice

> The standard library is anemic

This is a tradeoff; big standard libraries become graveyards over time (the classic article on this: https://leancrew.com/all-this/2012/04/where-modules-go-to-di...). How long was Python stuck with a terrible HTTP client because that was the one in the standard library? In Rust we have an incredible, state of the art regex library because it's a separate crate and is allowed to evolve.

> async is hard

Rust's async is hard to get started with; it's a barrier to get over like learning the borrow checker and lifetime system. But once you do I've found it productive and incredibly performant.

--

Overall, I don't think that Rust is the right solution to all problems. Rust makes you think about everything you're doing, the ways in which your programs use resources, and every possible class of errors. This is incredibly useful for writing fast and correct software, but will be overhead for people who just want to move fast.

I also think that static memory management is not the right tradeoff for most application software, although a GC language with Rust's ergonomics and crate ecosystem would be amazing for those use cases.

I'd personally always choose Java over Go especially given recent developments like ZGC, GraalVM, and Project Loom which essentially makes Java a better Go.

[0] https://arroyo.dev

In what world is Go more reliable or faster than Java? Especially modern Java (or other good JVM languages like Kotlin).

It compiles faster but that is about it. Which is a good thing too because it's verbose AF and heavily reliant on code generation even after generics shipped so that compiler lines/s actually matters.

The only knock you can put on Java for reliability is null-safety but lets be real, nil pointers, bad slice initalisation, etc are 10x worse in Go especially these days with @NotNull and powerful editors like IDEA stopping you from doing dumb things. Or simply using Kotlin which is non-nullable by default.

That and all the things Go is good at Java is simply better at. (especially once Java 21 ships in the next few days).

- Low pause GC? ZGC has Go beat, not just on pause times but on throughput and heap size scalability up into the terabytes. - Non-blocking code with synchronous coding style? Virtual Threads are much much better than goroutines. - Channels? ArrayDeque and friends are faster and have a lower learning curve.

Maybe the only area I think I prefer Go to JVM-land is the good parts of the stdlib. Go has lots of shit stdlib cough collections cough but there are some real gems. Namely the x509 and ASN.1 libraries are absolutely top notch.

Learning curve is also lower ofcourse, it's a very very simple language which is good for beginners and those taking their first steps out of JS/Ruby/Python into static types, pointers, etc.

Anyways, my real point was Java is easily faster and more reliable than Go and it seems pretty insane to reach the opposite conclusion if you have been on top of developments in both languages.

- Webcrap - use Go. The arguments for Go for that use case is that 1) Google provides the libraries for most web back-end things you'll need, and since Google uses those libraries internally, even the obscure cases have been exercised, and 2) Goroutines are both low-cost and can block, so you don't have to face Rust async/thread combo hell.

- Hard problems that have concurrency, performance issues, or have to be highly reliable such as a database - use Rust.

The features vs versions graph is more than a little nonsensical, and its conclusions even more so.

> They should be stable and move slowly so that most of the time of your develoeprs is not spent fighting with their tools.

I can't speak to Go's tooling base, but Rust's is head and shoulders above any other ecosystem that I've had to work with. This is definitely more a point in Rust's favor than against.

I don't agree with much of this - especially if the alternative is Go. I'm a semi-fan of Go but there are really very few situations I'd pick it over Rust.

> Rust is the 14th most used language

I think the author is a bit confused about "most loved" - that means that people who already use it want to keep using it. 14th most used language is great for such a young and not beginner friendly language. It's only 1 place behind Go and that is 3 years older.

Additionally Rust is mainly replacing C/C++ codebases which are generally much older and slower moving than other languages.

> Now imagine being the developer tasked with updating the dependencies of a service that is 31 versions behind... > During the same period, there was 8 Go releases, 7 Node.js releases (but only 2 LTS) and 3 Python releases.

This is obvious nonsense. The stability of a language is not measured by the number of releases. Come on, did this guy really write a successful book about Rust? Is this satire?

> Rust is actually still in the beta phase, with some important features such as async Traits still missing, which brings more churn to the ecosystem.

Really? Is C++ "still in beta" because it doesn't have async?

> The standard library is anemic

Sure that is an issue in C++ where using third party libraries is a huge pain. Doesn't really matter so much when you can just `cargo add regex`.

> async is hard

This is the only vaguely valid point. But on the other hand 90% of the time the solution is simple: don't use async.

Very disappointing article. I was expecting an actual good comparison of the pros and cons. Go does have some notable advantages over Rust - compile time, ease of cross compilation, simplicity, goroutines, built in fuzzing support, arguably better dependency management. Why not talk about them?

> almost as easy to use as Python

At risk of starting a flame war, I don't find Python easy to use at all so I have to question anything the author says at this point.

I was first introduced to Python 25 years ago and stuck with QuickBasic, C and assembly. I recently tried to do some opencv stuff with Python and the dynamic typing made even the simplest things exhausting. Then there's the virtual environment and dependencies situation which is easy to make a mess of if you don't know about it upfront.

I found a C# library to do the same and was way more productive and finished the task at hand quickly.

Which do you like better? Programming languages are not things to be judged based on some random criteria, but by how well they fit how your mind works and let you express the ideas you want to express. Different languages hit these points for different people.

Best advice you'll get is to try both (and more) and use the language you like best and that best aligns with the type of work you enjoy.

Go and Rust do not compete at all in the same domain. A long time ago, Rust did not have the focus it as now and even included a GC

But now, asking Go vs. Rust does not make sense at all.

If you want a mediocre speed application with fast development, use Go

If you want good memory footpeint with mediocre development use rust

Why not both? I spend most of my time in Go, but learning other languages is always on my radar, most recently OCaml. It's just fun and helps keep me spry, if that makes sense.

Like any time this is asked the real answer is "it depends" while the answer given in the post as in all posts like it is "you should use my favourite instead of your favourite". There's no depth here and nothing that hasn't been said before, don't waste your time.

I know HN isn't a fan of "middlebrow dismissal" but go on, read it and tell me it says anything beyond "I like red better than blue"

> When Rust makes sense

It’s missing a subheading for “anytime you do not want a garbage collector” which is true for almost anything real-time / graphical etc

I think the main point it's missing: what is the context? In the absence of context, any answer is both correct and incorrect, like Schrödinger's cat :D

So Ive been tugging on this myself. I came up with one heuristic for myself.

If you need to write microservices (especially for control planes where there good concurrency and distributed system patterns needed) - I find Go be a fine combination of performance (GC hit will be there over Rust), ease of deployment, programming model (CSP) - at a slight expense on verbosity (say compared to python and you also get used to this with your patterns).

If you need high perf/low latency/near C (embedded systems level) performance - with a type system assisted memory management - then Rust.

I have found Go's stdlib to be pretty thorough (and the ecosystem to be awesome too). Yes you will always find that set of X things hard to find that others dont care about. But horses for courses.

I have invested in learning both (but I also find learning languages a joy). But if you absolutely only have time for one consider your use case and pick appropriately. Yes you can do Rust for services too but given all this dual asyn model discussion still ongoing and a lot of real world services/control planes in Go there are already good Go patterns you can leverage right away at a much lower learning curve.

This feels like the beginning of a long blog post I'd like to read.

Go feels natural to me, Rust feels like an ugly looking, needlessly complicated language.

Go has decay too. Many packages are abandoned or not properly taken care of. Generics did their own to slow the language down. But even if it's not the fastest language, it's fast and robust enough to get things done. And that's what counts for me.

> Rust was Stack Overflow's most loved language for 7 years in a row ... and yet, was ranked as the 14th.

Go is ranked 13th. Seems weird to use language popularity as a criticism when you're only choosing between the 13th and 14th place options.

Besides, in 2023 their "All Respondents" usage is almost identical, with Rust showing stronger year-over-year growth than Go.

Use the tool for the job. I use Rust where it makes sense - georust is very useful to me. If I need simple web services I use Typescript. Image processing? Python and numpy. Low latency event handling over web sockets? Java and Lmax disruptor. Modern tooling and IDEs are great, using four or five languages is not that hard.

I’m curious, given the current state of Rust, what can be done to help with these issues?

Most of them seem related to the way the community organizes itself, and what they value at any given moment.

What would a non-anemic STD look like? Could the STD be broken into smaller pieces while still being a standard library?

Async has been a point of major frustration for me from the onset. Some people love it some hate it. Is there a good way to appease both sides? What can be done to make the libraries more generic between the two? Having to reimplement everything for async is a nightmare.

As for feature bloat in general. I agree, Rust still feels sorta like beta software, but it’s also matured a lot. I’m not sire there’s an optimal rate of feature addition, though I do wish existing feature polish was a higher priority over new stuff. Funny, I was just thinking about this last night while I was stuck trying to fall asleep.

This is usually a very simple decision. Do you need the performance of Rust? If not, use Go (or Java or F# or C# or whatever GC language you prefer)

As someone who doesn't know either language, would love HN's opinion on this video that was recommended to me by another HN user on a Rust thread a few days ago:

https://www.youtube.com/watch?v=p-tb1ZfkwgQ

The general gist of the video is the creator prefer Rust for functional programming and programs without much state and Go for everything else. As someone who's coming from a React background I don't see why if Rust is brilliant for functional programming why it can't also be good for programs with state if the right design decisions are taken to handle it - can you not just use a redux style store with actions and reducers?

One argument/scenario for the use of Rust I'm surprised not to see more often is interop with Python.

A ton of code, ML/AI etc goes through Python sooner or later. For example, as I understand it, PyTorch and Tensorflow, for instance, are written in C++, but primarily to be used in Python.

There are very few languages I know of that have compelling interop with Python. C, C++, Rust... Nim? All other major languages have something but as far as I can tell, it is usually some kind of hack/rpc kind of thing.

Clearly doesn't apply to every project, but one key reason why I'm learning Rust is precisely that I care about Python interior, and don't much love C++.

I'm a little tired of this endless discussion ... it always pops up with programming languages, they are tools, use whatever is more fit for what you're doing, move fast, break things, learn

I'm going to restate here again: Go is static compiling friendly, you just ship a single executable and you're done, can't believe how easy is it to upgrade down the road.

rust, java, etc are much more complex.

Ok, so I'm no expert on Rust or Go or whatever, but I've noticed that many posts and comments seem to rip on Go, and that Go is bad, Rust is better, language X is better than Go, etc etc.

My question is why all the hate on Go? And if Go is so bad as these posts claim, why compare everything against it?

I'm not saying Rust isn't good or anything like that, but why the never ending hit pieces on Go? Lets just evaluate Rust or any language on its own merits.

I agree comparisons can be useful but its getting out of hand with these never ending Rust vs. Go pieces.

You should Typescript. Performance comparable to Go. A more flexible typing system than both. Easier to learn than both. A worse package system, but that can be mitigated with discipline. What Typescript currently lacks the most is affordances for embedded or performance intensive work as it's single threaded, but when performance matters use NAPI to use Rust in your Typescript, but the trajectory of performance of V8 and Webkit is such that I wouldn't be surprised if Typescript is within the same order of magnitude for performance as Rust soon enough.

:P

> As far as I know, today, Rust is the only programming language (other than C) able to create efficient WebAssembly (wasm) libraries

Zig is also a good option for that, but the language is still in development.

As someone with very little expertise in this, and from the very little time that I can spare for experimental webdev, from a webdev framework perspective, Rust is where Go was 7-8 years back. There are some Rust frameworks available which look promising (rocket), but golang has much more. On the flipside, There is nothing wrong with golang (or at least it has less wrong going for it as compared to the js frameworks), but Rust is appealing because it IS the next big thing.

This author has a habit (in this posts and prior posts) of the content of the paragraphs not connecting the dots for the claims made in the headings.

> Rust is (over)hyped

Whether it is or isn't, the content of the following paragraph does not justify the heading. It cites the StackOverflow surveys that says people like Rust and then cites adoption, but doesn't connect these points. It's possible for something to be hyped but not adopted much if it's new-ish.

The heading itself is also unclear. Is the author saying "overhyped" or "hyped"? Pick one.

Additionally, the author doesn't connect this heading to the overall article. They should explain why something being (over)hyped means you should not pick it.

> Rust projects decay

The rest of the paragraph talks about the Rust release cycle but doesn't connect the dots to why this causes Rust projects to decay.

Any Rust code written after the v1.0 release is guaranteed to compile forever. If you upgrade your compiler by 30 versions your code will still compile. A new release of Rust doesn't mean you have to drop everything you're doing and upgrade. If you want to upgrade once per year, you can do that.

The same points were raised on the author's previous article ("Programming Languages are Platforms") which was another article that raises points in the headings that are not described further in the paragraphs.

> Rust is still beta (despite the 1.0)

This paragraph says "related to the point above" but it's not related. In this section they say that Rust is missing features (it is) and in the previous section they were implying that it's bad that Rust is adding features.

This heading is also obviously intentionally inflammatory. If Rust not having async Traits makes it "beta", would the author have considered Go to be "beta" for 10+ years when it didn't have generics. Generics as a feature are *much* more integrated with fundamental parts of the language and cause ecosystem churn & split. See also Java and C#.

(For the record, I wouldn't consider either of those situations to be "beta" and think the suggestion is preposterous)

> The standard library is anemic

Meh, "anemic" is a pretty inflammatory word and I wouldn't go that far. It's intentionally bare bones to avoid bad design decisions that can't be removed in the future and so far that's been pretty successful.

Does the Go standard library even have map/filter yet?

It seems like this author's idea of a non-anemic standard library is that it has a builtin HTTP server. They also suggest in other articles that Rust needs to have a builtin templating language as well. They suggest that not having this builtin leads to bugs, as if a standard library can't have bugs as well? The link between these points is tenuous at best.

> async is hard

These paragraphs are pretty good.

___

All in all, it's a provacatively written article that's sure to generate discussion, and especially discussion unrelated to the article itself, but unfortunately there's little to no logical flow in the points that it's trying to make.

Isn't it obvious, just use what everyone use (golang at the moment)? Is your role as a software engineer NOT a job/creating values for other people, but to "influence technology" or some sort of activism? I know that there are software engineers like that, but I just don't think most people are. Many seem to be confused why they do what they do apparently.

> I think that a modular and rich standard library such as Go's or Node.js's offers way higher productivity to developers, consistency to the ecosystem and reduced costs for businesses.

Is the Go standard library really considered rich? Coming from languages like python or ruby I found it pretty lacking. Admittedly I haven't used Go in 3 years.

Honestly? Though I am forced to write go at work, I take Rust in a heartbeat(and it is a constant moaning from my end to ditch go and use Rust all the way almost every day). First thing to keep in mind is that Rust today is nothing like the Rust of 2015, even 2020. Way too many things are wrong with go: The packaging is one thing which I absolutely hate. I can't find words to express how much I hate the import "github.com/whatever" and that is a clear indication of the fact that packaging is an afterthought, which historically was a problem the language designers chose to ignore and kick the bucket down the road, hoping the community figures it out. Another clear indication of this is everything around the environmental variable hell: GOROOT, GOPATH and all that. Error handling is another horrible thing: ok, err := whatever() is absolutely wretched, even more so when you have to write the function definitions. Even when all linters are happy with the code, I can't look at it without thinking "this looks as beautiful and idiomatic as a roadkill". While coroutines(I hate the name goroutines) are cheap, they are not a universal solution to all problems and with that in mind, having a compiled language with no actual threading is ridiculous: threads are a great thing to have(I know this goes much deeper but let's not turn this into a novel). While both languages don't have inheritance, at least with Rust you have some tools to help you generalize basic things: macros. The statement that golang has all you need in it's standard library is a complete joke. While the ecosystem has grown immensely over the years, I feel like it's reaching the point where it's comparable to the npm hellhole.

With Rust you get a perfectly thought out packaging. You also get the best of both worlds - runtimes and threads. By design you are pushed hard to properly handle errors. Some of my large Rust projects take forever to compile, I'll give you that, but there is a good reason for it. The compiler is actually helpful and in a lot of the cases it tells you exactly what you need to fix when you mess up. And don't even get me started on performance. I have the exact same microservice implemented in both go and rust. And while I did not opt for the most performant rust web framework (poem), it's not even a race, it's a straight up massacre: when I benchmark the two with wrk, the difference in performance is literally 11 times - same database, same openapi specification, same logic. While the Rust standard library lacks a lot of things, even some basic functionalities, cargo takes care of it for you with 0 effort: cargo new whatever, echo 'rand = "0.8.4"' >> whatever/Cargo.toml and you are done.

Don't get me wrong, this is not a "bash-golang" comment. But I can't deny that when I put the two side by side, go looks like a toy language.

Should I Rust or should I Go now?

Should I Rust or should I Go now?

If I Go there will be trouble!

If I Rust it will be double!

So you gotta let me know!

Should I Rust or should I Go?!

(I'll see myself out now...)

You should probably C that wherever you go there you are.

If you Go, there will be trouble. But if you Rust, it will be double.

My POV:

Rust for OS kernel programming, e.g https://github.com/dancrossnyc/rxv64

And go for practically anything outside that scope: web service, CLI tool, etc.

Luckily I have written up my heartache with Rust at https://news.ycombinator.com/item?id=30954078 so I don't need to do it again.

Glad I read this. No need to waste my time learning Rust.

Never touch Go and your life will be better.

GO

Go

Rust is not a good match for embedded Linux so long as binary sizes are so gigantic (same is true for a lot of C++). When your binary takes 100 MB of a few GB emmc, you have a problem.