by cjg on 9/15/23, 3:59 PM with 170 comments
by necubi on 9/15/23, 6:07 PM
> 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.
by jpgvm on 9/15/23, 6:08 PM
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.
by Animats on 9/15/23, 5:59 PM
- Hard problems that have concurrency, performance issues, or have to be highly reliable such as a database - use Rust.
by seurimas on 9/15/23, 6:15 PM
> 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.
by IshKebab on 9/15/23, 6:35 PM
> 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?
by ryanjshaw on 9/15/23, 6:19 PM
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.
by eikenberry on 9/15/23, 7:29 PM
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.
by whatrg on 9/15/23, 7:01 PM
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
by lagniappe on 9/15/23, 5:58 PM
by ketralnis on 9/15/23, 5:59 PM
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"
by dwroberts on 9/15/23, 6:08 PM
It’s missing a subheading for “anytime you do not want a garbage collector” which is true for almost anything real-time / graphical etc
by vb-8448 on 9/15/23, 5:58 PM
by flashgordon on 9/15/23, 6:47 PM
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.
by lakomen on 9/16/23, 2:22 AM
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.
by spiffytech on 9/16/23, 2:06 PM
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.
by willtemperley on 9/16/23, 6:32 AM
by nixpulvis on 9/15/23, 6:28 PM
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.
by jackmott42 on 9/15/23, 6:21 PM
by rcarr on 9/15/23, 5:55 PM
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?
by rich_sasha on 9/15/23, 9:04 PM
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++.
by techn00 on 9/15/23, 6:09 PM
by synergy20 on 9/22/23, 8:46 PM
rust, java, etc are much more complex.
by horeszko on 9/16/23, 4:38 AM
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.
by endisneigh on 9/15/23, 6:17 PM
:P
by ngrilly on 9/15/23, 6:02 PM
Zig is also a good option for that, but the language is still in development.
by anoncow on 9/15/23, 6:07 PM
by tubthumper8 on 9/15/23, 7:21 PM
> 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.
by nsonha on 9/16/23, 7:13 AM
by throwawa14223 on 9/15/23, 6:38 PM
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.
by axegon_ on 9/15/23, 6:47 PM
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.
by Gualdrapo on 9/15/23, 7:08 PM
by taylodl on 9/15/23, 8:20 PM
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...)
by NoZZz on 9/17/23, 6:02 PM
by hinkley on 9/15/23, 6:23 PM
by anta40 on 9/16/23, 4:15 AM
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.
by chx on 9/15/23, 6:52 PM
by cutler on 9/16/23, 1:57 AM
by neonsunset on 9/16/23, 4:49 PM
by sibeliuss on 9/15/23, 4:00 PM
by hsnewman on 9/15/23, 4:18 PM
by cozzyd on 9/16/23, 2:33 AM