15 ms·

Should I Rust or Should I Go?

106 points by cjg 3y ago

rich_sasha 3y ago
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++.
cutler 3y ago
Glad I read this. No need to waste my time learning Rust.
lakomen 3y ago
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.
cozzyd 3y ago
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.
anta40 3y ago
My POV: Rust for OS kernel programming, e.g https://github.com/dancrossnyc/rxv64 https://github.com/dancrossnyc/rxv64 And go for practically anything outside that scope: web service, CLI tool, etc.
horeszko 3y ago
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.
- deleted 3y ago
  [deleted]
willtemperley 3y ago
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.
nsonha 3y ago
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.
spiffytech 3y ago
> 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.
neonsunset 3y ago
Never touch Go and your life will be better.
NoZZz 3y ago
You should probably C that wherever you go there you are.
sibeliuss 3y ago
GO
hsnewman 3y ago
Go
deleted 3y ago
[deleted]
rcarr 3y ago
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 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?
- goku12 3y ago
  I have experience in Rust, but not in Go. The video was more informative than I expected - a lot of comparative insights into the type systems. Ocaml sounds interesting. And while personally prefer Rust for everything, I agree that Go might be the better choice if the developers have to learn it from scratch or have to develop the application quickly. Rust takes a lot of effort to reach the level where you can appreciate its advantages. Once in a while, you can see someone cursing Rust because they were forced by the management to use Rust to develop an application under a tight deadline. Rust, on the other hand, guarantees memory safety, pushes you to design better programs and cuts down on debugging time a lot. Rust is the better choice when correctness and performance matters. And if you are comfortable with Rust, it's good for almost any task. > The general gist of the video is the creator prefer Rust for functional programming and programs without much state and Go for everything else. Rust has no problems with handling states, as you guessed. They can't be global states (like in Go?). You have to group the state variables logically and pass them around. An additional constraint is that the data structures should be in a tree form. The ownership rules make it hard to have circular and mutual references in data structures (it's still possible with things like Rc and unsafe blocks). Whether all this is an advantage or disadvantage really depends upon your preference. For example, I usually have a single large config object in my Python programs, whereas Rust forces me to split it up into manageable pieces. Frankly, I prefer the Rust style for multiple reasons: 1. Global states and circular references are an easy recipe for disastrous bugs. 2. Splitting up large state variables into smaller ones make it easier to reason about the purpose of each code section - it encourages more modular, refactorable and reusable code. (Splitting up data feels magical. All the problems seem to suddenly disappear when you reach a certain level of segregation) I haven't yet worked on a program that can't be written in Rust.
lagniappe 3y ago
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.
- Alifatisk 3y ago
  What’s your thoughts on Ocaml? I’ve been curious Facebooks heavy use of it
  - trollerator23 3y ago
    They do?? Sauce?
    - ysleepy 3y ago
      I remember reading years ago that the hack compiler was built in ocaml. compilers and such are often built using languages with nice ADTs afaik.
      - itishappy 3y ago
        The Rust compiler was bootstrapped from OCaml as well!
    - deleted 3y ago
      [deleted]
    - stefanos82 3y ago
      https://github.com/facebook/pyre-check https://github.com/facebook/pyre-check https://github.com/facebook/flow https://github.com/facebook/flow https://github.com/facebook/infer https://github.com/facebook/infer https://github.com/facebook/hhvm/tree/master/hphp/hack https://github.com/facebook/hhvm/tree/master/hphp/hack
- bborud 3y ago
  [flagged]
vb-8448 3y ago
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
- jeremyjh 3y ago
  The context is wanting to write an article that makes the front page of Hacker News.
  - vb-8448 3y ago
    haha .. well, it definitely makes sense
Animats 3y ago
- 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.
- tejinderss 3y ago
  Why Go for web and not Typescript with nodejs/deno. The ecosystem is also huge and widely used. The type system is miles ahead of Go and is closer to rust. The async await is single threaded too.
  - husarcik 3y ago
    I question this myself as bun.js is approaching golang speeds.
    - jpgvm 3y ago
      I highly doubt it's doing type checking though so you aren't going to be eliminating tsc from the picture even if you are using bun.js unless you want to just cross your fingers and hope for the best.
      - postalrat 3y ago
        My ide does a pretty good job saying something is wrong without using tsc.
  - jpgvm 3y ago
    Why use an ecosystem that needs 2-3 layers of build tooling, none of which is designed to work together when you can use any of the sane stacks instead? Not to mention the hell that is Jest, Eslint and trying to make those play with aforementioned 2-3 layers of crap. Then you also have to put up all the downsides of purely single threaded concurrent programming instead of Go M:N model which is much less prone to problems like event loop exhaustion. Go for all it's faults has one build system/tool and spits out machine code, hell it does that probably 10x faster than just tsc can typecheck. Personally I don't like either but Go > Typescript seems like a no-brainer unless you are hell bent on the isomorphic code thing and all the extra work that entails. i.e. making sure someone doesn't reference window in an isomorphic lib or node APIs in the opposite scenario, etc.
ketralnis 3y ago
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"
ngrilly 3y ago
> 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.
- deleted 3y ago
  [deleted]
- pcwalton 3y ago
  Regarding Zig, note that the author writes "starting a new project in a memory unsafe language in 2023 is foolish as demonstrated by the endless flow of vulnerabilities."
  - cozzyd 3y ago
    Yes but that's a silly argument for most software, which will never see adversarial contact.
- vrmiguel 3y ago
  Maybe once Zig supports WASIX
  - meepmorp 3y ago
    No, let's actually have a standard with some thoughtful design instead of just bunging a bunch of ancient POSIXisms along into another platform. Also, as far as I can tell, it's being pushed exclusively by Wasmer which looks to be a bit shady as a company.
  - ayewo 3y ago
    Wasmer attempted to do this in the Ziglang repo barely 4 days ago: https://github.com/ziglang/zig/issues/17115 https://github.com/ziglang/zig/issues/17115
    - ngrilly 3y ago
      I’m pretty sure that’s what the parent is referring to :)
necubi 3y ago
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-die/ 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 https://arroyo.dev
- pnpnp 3y ago
  > ZGC, GraalVM, and Project Loom which essentially makes Java a better Go. GraalVM is still nowhere near as nice as Go when you need to compile quickly. Last time I checked, the compiler needed orders of magnitude more time and memory to make a binary. ZGC is pretty nice, though.
- jasfi 3y ago
  Nim is another alternative. Fast to write and excellent performance. Needs a bigger community though.
anoncow 3y ago
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.
- zelphirkalt 3y ago
  I think you need to qualify the aspects, in which you think Rust is 7-8 years back. I rather have the impression, that the designers of the Go language had a too simplistic view of what Go should offer and then it took them 12 years to get something as common as generics. Rust has many language features and of course had generics waaay before Go. In general it seems the Rust ecosystem does sometimes have things later, but therefore better or correct when it arrives at a solution. In terms of language design Go is the one that seems way behind.
  - pram 3y ago
    Shocking but true: you could program things in Go before generics.
    - erik_seaberg 3y ago
      Now a pile of legacy code needs to be burned to the ground and replaced (it sounds like a lot of Kubernetes was generated to work around it). In the Java ecosystem we’re fortunate that this is long since finished.
dwroberts 3y ago
> 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
jpgvm 3y ago
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.
- za3faran 3y ago
  Having worked on one of the largest golang code bases on the planet, I agree completely. I would always think to myself how much simpler and more reliable the programs I saw would have been in Java. But hype is hype I suppose, not to mention so many unsubstantiated claims.
  - super_flanker 3y ago
    Could you please tell a bit more about your project, I'm very curious.
    - za3faran 3y ago
techn00 3y ago
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
- IshKebab 3y ago
  Some languages are better than others. I don't see what's wrong with debating it. Do you also get annoyed at people debating which football team is the best or the best cars?
- jackmott42 3y ago
  This is about how to determine what is more fit for what you are doing.
seurimas 3y ago
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.
- dontlaugh 3y ago
  Go’s is ok. Not as good though.
  - icholy 3y ago
    Can you provide an example of where rust has better tooling than Go?
    - saghm 3y ago
      Offhand, I like rustfmt a lot more than gofmt because it handles long lines rather than only changing things within a given line; in my opinion, any time I need to manually format something myself, that's a failure of the formatting tool. I also find rustdoc to be much more flexible than Go's documentation functionality (which I forget the name of, but I assume it's something like `go doc`). At least the last time I used it Go required me to prefix any doc comment for a given function, type, etc. to start with the name of the item I was documenting; not only is this redundant, but it also means that any typo I make will cause the comment to be omitted completely, whereas Rust only requires a third slash for doc comments (i.e. `///` rather than just `//`). It's a minor thing, but small quality of life things add up across an entire ecosystem.
      - icholy 3y ago
        Prefixing doc comments with the ident name is a convention that isn't enforced in any way. You must have been using a 3rd party linter.
endisneigh 3y ago
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
- gadflyinyoureye 3y ago
  Typescript uses an order of magnitude memory that Go. It also doesn’t support concurrency. With on Go pod you can have a web server that automatically uses multiple cores. You’ll get better performance in the real world as a result. You’ll pay less for it too.
  - endisneigh 3y ago
    Yes, Javascript is single threaded. This has its benefits and drawbacks. In many applications using the Cluster API is enough, but as you said you'll never be able to do super performance stuff with Javascript, but you can use NAPI and call Rust if you'd like. Memory usage is pretty good with Go, yes. I'm skeptical how much this matters in a real world application, though.
    - a_wild_dandan 3y ago
      HN's memory usage obsession is basically a meme now. You'll see vastly more JS consternation here for RAM usage than praise for benefits like getting MVPs up stunningly fast, having a gigantic hiring pool, using one codebase to deploy on every major platform, etc. (These critics are often ironically the same folks who endorse avoiding premature optimization.) And hey, memory usage can be crucial! But the community's distorted emphasis on it is almost comical, when compared to reality. I think it's an understandable perspective, given some devs' proximity to bare metal. But man I wish it wasn't such an omnipresent refrain here. :/
ryanjshaw 3y ago
> 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.
- winrid 3y ago
  Did you try using a python IDE like Pycharm? Also python has type hints now and many libraries expose them.
jackmott42 3y ago
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)
- horeszko 3y ago
  Finally, a pragmatist on this Rust vs Go maddness. Thank you
- goku12 3y ago
  > Do you need the performance of Rust? If not, use Go Or, if GC is not an option - like operating systems, embedded software, web engines and game engines. That said, why not just use Rust for everything if you know it?
  - lycopodiopsida 3y ago
    You can use any language you like for your pet project with a single contributor, but there are more considerations if you want to have/move a team to that language in business environment.
    - goku12 3y ago
      Agreed. That's certainly a good criterion.
hinkley 3y ago
If you Go, there will be trouble. But if you Rust, it will be double.
nixpulvis 3y ago
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.
- thesuperbigfrog 3y ago
  >> What would a non-anemic STD look like? More like the standard libraries found in C++, Ada, Go, or Python. Why can't Rust do something like C++ does with Boost? If everyone is using a given crate (for example, serde) why not "adopt" it into the standard library? Give the maintainer a plaque that looks cool and a small fee for initial adoption and a recurring stipend for continued maintenance. The crate becomes official, gets guaranteed maintenance and there is less need to reinvent the wheel or worry that a good crate will go unmaintained or have issues.
  - steveklabnik 3y ago
    Note that boost is also not the C++ standard library. A few people have tried to make boost-like meta-packages in Rust over the years, but in practice, people don’t use them, and they die out. Also, like, serde's main maintainer is also a member of the libs team, so it being moved into the standard library meaning more maintenance doesn't really make sense to me.
    - thesuperbigfrog 3y ago
      >> Note that boost is also not the C++ standard library. I know, but many components that are now in the C++ standard library were previously in Boost or were heavily influenced by / inspired by Boost: https://stackoverflow.com/questions/59912393/boost-libraries-that-made-it-into-the-c-standard https://stackoverflow.com/questions/59912393/boost-libraries... Similar events also happened in Java 8 with the Joda time library: https://www.joda.org/joda-time/ https://www.joda.org/joda-time/ >> serde's main maintainer is also a member of the libs team, so it being moved into the standard library meaning more maintenance doesn't really make sense to me. I did not know that. I was just using serde as an example of a widely-used crate that feels essential enough to be included in the Rust standard library. At what point does a third-party crate become so useful that it might be considered for inclusion in the Rust standard library? Is there a process for adding crates to the Rust standard library? If so, how do such crates get nominated and approved?
IshKebab 3y ago
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?
throwawa14223 3y ago
> 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.
- steveklabnik 3y ago
  All of these things are a spectrum. For network services especially, Go's standard library is generally considered pretty comprehensive, yes. In comparison to Rust specifically, like the context of the post, I don't think anyone could really argue a different way, though if you're comparing to something else, or for a different kind of task, it's possible that you may have a different opinion, sure.
  - throwawa14223 3y ago
    I felt like it had a lot to do things web related but was pretty lacking on primitives for algorithms and data structures out of the box.
flashgordon 3y ago
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.
axegon_ 3y ago
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.
chx 3y ago
Luckily I have written up my heartache with Rust at https://news.ycombinator.com/item?id=30954078 https://news.ycombinator.com/item?id=30954078 so I don't need to do it again.
deleted 3y ago
[deleted]
whatrg 3y ago
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
- goku12 3y ago
  > If you want a mediocre speed application with fast development, use Go I don't know if you can describe much of Kubernetes like that.
Gualdrapo 3y ago
https://www.youtube.com/watch?v=BN1WwnEDWAM https://www.youtube.com/watch?v=BN1WwnEDWAM
tubthumper8 3y ago
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.
eikenberry 3y ago
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.
- vrmiguel 3y ago
  One point that a lot of those "actually, just use Go" articles fail to recognize is that there is a sizable amount of developers who simply dislike programming in Go. Despite its impressive compilation speed and bundled tooling and whatnot, some (myself included) find it tedious and uninteresting to program in Go, with tons of repetition and verboseness. Some people are more utilitarian and don't mind, but not all think the same.
  - eikenberry 3y ago
    Yep. For me Concurrency and CSP are why I learned Go and why I still use it today. I love thinking concurrently about problems and how data and control flow through those systems. It was a natural fit for me in those aspects and the other language warts don't get in the way enough to matter.
taylodl 3y ago
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...)
synergy20 3y ago
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.

106 points by cjg 3y ago

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

cutler 3y ago

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

lakomen 3y ago

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.

cozzyd 3y ago

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.

anta40 3y ago

My POV: Rust for OS kernel programming, e.g https://github.com/dancrossnyc/rxv64 https://github.com/dancrossnyc/rxv64 And go for practically anything outside that scope: web service, CLI tool, etc.

horeszko 3y ago

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.

deleted 3y ago
[deleted]

willtemperley 3y ago

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.

nsonha 3y ago

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.

spiffytech 3y ago

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

neonsunset 3y ago

Never touch Go and your life will be better.

NoZZz 3y ago

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

sibeliuss 3y ago

hsnewman 3y ago

deleted 3y ago

[deleted]

rcarr 3y ago

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

goku12 3y ago
I have experience in Rust, but not in Go. The video was more informative than I expected - a lot of comparative insights into the type systems. Ocaml sounds interesting. And while personally prefer Rust for everything, I agree that Go might be the better choice if the developers have to learn it from scratch or have to develop the application quickly. Rust takes a lot of effort to reach the level where you can appreciate its advantages. Once in a while, you can see someone cursing Rust because they were forced by the management to use Rust to develop an application under a tight deadline. Rust, on the other hand, guarantees memory safety, pushes you to design better programs and cuts down on debugging time a lot. Rust is the better choice when correctness and performance matters. And if you are comfortable with Rust, it's good for almost any task. > The general gist of the video is the creator prefer Rust for functional programming and programs without much state and Go for everything else. Rust has no problems with handling states, as you guessed. They can't be global states (like in Go?). You have to group the state variables logically and pass them around. An additional constraint is that the data structures should be in a tree form. The ownership rules make it hard to have circular and mutual references in data structures (it's still possible with things like Rc and unsafe blocks). Whether all this is an advantage or disadvantage really depends upon your preference. For example, I usually have a single large config object in my Python programs, whereas Rust forces me to split it up into manageable pieces. Frankly, I prefer the Rust style for multiple reasons: 1. Global states and circular references are an easy recipe for disastrous bugs. 2. Splitting up large state variables into smaller ones make it easier to reason about the purpose of each code section - it encourages more modular, refactorable and reusable code. (Splitting up data feels magical. All the problems seem to suddenly disappear when you reach a certain level of segregation) I haven't yet worked on a program that can't be written in Rust.

lagniappe 3y ago

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.

Alifatisk 3y ago
What’s your thoughts on Ocaml? I’ve been curious Facebooks heavy use of it
- trollerator23 3y ago
  They do?? Sauce?
  - ysleepy 3y ago
    I remember reading years ago that the hack compiler was built in ocaml. compilers and such are often built using languages with nice ADTs afaik.
    - itishappy 3y ago
      The Rust compiler was bootstrapped from OCaml as well!
  - deleted 3y ago
    [deleted]
  - stefanos82 3y ago
    https://github.com/facebook/pyre-check https://github.com/facebook/pyre-check https://github.com/facebook/flow https://github.com/facebook/flow https://github.com/facebook/infer https://github.com/facebook/infer https://github.com/facebook/hhvm/tree/master/hphp/hack https://github.com/facebook/hhvm/tree/master/hphp/hack
bborud 3y ago
[flagged]

vb-8448 3y ago

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

jeremyjh 3y ago
The context is wanting to write an article that makes the front page of Hacker News.
- vb-8448 3y ago
  haha .. well, it definitely makes sense

Animats 3y ago

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

tejinderss 3y ago
Why Go for web and not Typescript with nodejs/deno. The ecosystem is also huge and widely used. The type system is miles ahead of Go and is closer to rust. The async await is single threaded too.
- husarcik 3y ago
  I question this myself as bun.js is approaching golang speeds.
  - jpgvm 3y ago
    I highly doubt it's doing type checking though so you aren't going to be eliminating tsc from the picture even if you are using bun.js unless you want to just cross your fingers and hope for the best.
    - postalrat 3y ago
      My ide does a pretty good job saying something is wrong without using tsc.
- jpgvm 3y ago
  Why use an ecosystem that needs 2-3 layers of build tooling, none of which is designed to work together when you can use any of the sane stacks instead? Not to mention the hell that is Jest, Eslint and trying to make those play with aforementioned 2-3 layers of crap. Then you also have to put up all the downsides of purely single threaded concurrent programming instead of Go M:N model which is much less prone to problems like event loop exhaustion. Go for all it's faults has one build system/tool and spits out machine code, hell it does that probably 10x faster than just tsc can typecheck. Personally I don't like either but Go > Typescript seems like a no-brainer unless you are hell bent on the isomorphic code thing and all the extra work that entails. i.e. making sure someone doesn't reference window in an isomorphic lib or node APIs in the opposite scenario, etc.

ketralnis 3y ago

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"

ngrilly 3y ago

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

deleted 3y ago
[deleted]
pcwalton 3y ago
Regarding Zig, note that the author writes "starting a new project in a memory unsafe language in 2023 is foolish as demonstrated by the endless flow of vulnerabilities."
- cozzyd 3y ago
  Yes but that's a silly argument for most software, which will never see adversarial contact.
vrmiguel 3y ago
Maybe once Zig supports WASIX
- meepmorp 3y ago
  No, let's actually have a standard with some thoughtful design instead of just bunging a bunch of ancient POSIXisms along into another platform. Also, as far as I can tell, it's being pushed exclusively by Wasmer which looks to be a bit shady as a company.
- ayewo 3y ago
  Wasmer attempted to do this in the Ziglang repo barely 4 days ago: https://github.com/ziglang/zig/issues/17115 https://github.com/ziglang/zig/issues/17115
  - ngrilly 3y ago
    I’m pretty sure that’s what the parent is referring to :)

necubi 3y ago

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-die/ 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 https://arroyo.dev

pnpnp 3y ago
> ZGC, GraalVM, and Project Loom which essentially makes Java a better Go. GraalVM is still nowhere near as nice as Go when you need to compile quickly. Last time I checked, the compiler needed orders of magnitude more time and memory to make a binary. ZGC is pretty nice, though.
jasfi 3y ago
Nim is another alternative. Fast to write and excellent performance. Needs a bigger community though.

anoncow 3y ago

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.

zelphirkalt 3y ago
I think you need to qualify the aspects, in which you think Rust is 7-8 years back. I rather have the impression, that the designers of the Go language had a too simplistic view of what Go should offer and then it took them 12 years to get something as common as generics. Rust has many language features and of course had generics waaay before Go. In general it seems the Rust ecosystem does sometimes have things later, but therefore better or correct when it arrives at a solution. In terms of language design Go is the one that seems way behind.
- pram 3y ago
  Shocking but true: you could program things in Go before generics.
  - erik_seaberg 3y ago
    Now a pile of legacy code needs to be burned to the ground and replaced (it sounds like a lot of Kubernetes was generated to work around it). In the Java ecosystem we’re fortunate that this is long since finished.

dwroberts 3y ago

> 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

jpgvm 3y ago

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.

za3faran 3y ago
Having worked on one of the largest golang code bases on the planet, I agree completely. I would always think to myself how much simpler and more reliable the programs I saw would have been in Java. But hype is hype I suppose, not to mention so many unsubstantiated claims.
- super_flanker 3y ago
  Could you please tell a bit more about your project, I'm very curious.
  - za3faran 3y ago

techn00 3y ago

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

IshKebab 3y ago
Some languages are better than others. I don't see what's wrong with debating it. Do you also get annoyed at people debating which football team is the best or the best cars?
jackmott42 3y ago
This is about how to determine what is more fit for what you are doing.

seurimas 3y ago

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.

dontlaugh 3y ago
Go’s is ok. Not as good though.
- icholy 3y ago
  Can you provide an example of where rust has better tooling than Go?
  - saghm 3y ago
    Offhand, I like rustfmt a lot more than gofmt because it handles long lines rather than only changing things within a given line; in my opinion, any time I need to manually format something myself, that's a failure of the formatting tool. I also find rustdoc to be much more flexible than Go's documentation functionality (which I forget the name of, but I assume it's something like `go doc`). At least the last time I used it Go required me to prefix any doc comment for a given function, type, etc. to start with the name of the item I was documenting; not only is this redundant, but it also means that any typo I make will cause the comment to be omitted completely, whereas Rust only requires a third slash for doc comments (i.e. `///` rather than just `//`). It's a minor thing, but small quality of life things add up across an entire ecosystem.
    - icholy 3y ago
      Prefixing doc comments with the ident name is a convention that isn't enforced in any way. You must have been using a 3rd party linter.

endisneigh 3y ago

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

gadflyinyoureye 3y ago
Typescript uses an order of magnitude memory that Go. It also doesn’t support concurrency. With on Go pod you can have a web server that automatically uses multiple cores. You’ll get better performance in the real world as a result. You’ll pay less for it too.
- endisneigh 3y ago
  Yes, Javascript is single threaded. This has its benefits and drawbacks. In many applications using the Cluster API is enough, but as you said you'll never be able to do super performance stuff with Javascript, but you can use NAPI and call Rust if you'd like. Memory usage is pretty good with Go, yes. I'm skeptical how much this matters in a real world application, though.
  - a_wild_dandan 3y ago
    HN's memory usage obsession is basically a meme now. You'll see vastly more JS consternation here for RAM usage than praise for benefits like getting MVPs up stunningly fast, having a gigantic hiring pool, using one codebase to deploy on every major platform, etc. (These critics are often ironically the same folks who endorse avoiding premature optimization.) And hey, memory usage can be crucial! But the community's distorted emphasis on it is almost comical, when compared to reality. I think it's an understandable perspective, given some devs' proximity to bare metal. But man I wish it wasn't such an omnipresent refrain here. :/

ryanjshaw 3y ago

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

winrid 3y ago
Did you try using a python IDE like Pycharm? Also python has type hints now and many libraries expose them.

jackmott42 3y ago

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)

horeszko 3y ago
Finally, a pragmatist on this Rust vs Go maddness. Thank you
goku12 3y ago
> Do you need the performance of Rust? If not, use Go Or, if GC is not an option - like operating systems, embedded software, web engines and game engines. That said, why not just use Rust for everything if you know it?
- lycopodiopsida 3y ago
  You can use any language you like for your pet project with a single contributor, but there are more considerations if you want to have/move a team to that language in business environment.
  - goku12 3y ago
    Agreed. That's certainly a good criterion.

hinkley 3y ago

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

nixpulvis 3y ago

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.

thesuperbigfrog 3y ago
>> What would a non-anemic STD look like? More like the standard libraries found in C++, Ada, Go, or Python. Why can't Rust do something like C++ does with Boost? If everyone is using a given crate (for example, serde) why not "adopt" it into the standard library? Give the maintainer a plaque that looks cool and a small fee for initial adoption and a recurring stipend for continued maintenance. The crate becomes official, gets guaranteed maintenance and there is less need to reinvent the wheel or worry that a good crate will go unmaintained or have issues.
- steveklabnik 3y ago
  Note that boost is also not the C++ standard library. A few people have tried to make boost-like meta-packages in Rust over the years, but in practice, people don’t use them, and they die out. Also, like, serde's main maintainer is also a member of the libs team, so it being moved into the standard library meaning more maintenance doesn't really make sense to me.
  - thesuperbigfrog 3y ago
    >> Note that boost is also not the C++ standard library. I know, but many components that are now in the C++ standard library were previously in Boost or were heavily influenced by / inspired by Boost: https://stackoverflow.com/questions/59912393/boost-libraries-that-made-it-into-the-c-standard https://stackoverflow.com/questions/59912393/boost-libraries... Similar events also happened in Java 8 with the Joda time library: https://www.joda.org/joda-time/ https://www.joda.org/joda-time/ >> serde's main maintainer is also a member of the libs team, so it being moved into the standard library meaning more maintenance doesn't really make sense to me. I did not know that. I was just using serde as an example of a widely-used crate that feels essential enough to be included in the Rust standard library. At what point does a third-party crate become so useful that it might be considered for inclusion in the Rust standard library? Is there a process for adding crates to the Rust standard library? If so, how do such crates get nominated and approved?

IshKebab 3y ago

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?

throwawa14223 3y ago

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

steveklabnik 3y ago
All of these things are a spectrum. For network services especially, Go's standard library is generally considered pretty comprehensive, yes. In comparison to Rust specifically, like the context of the post, I don't think anyone could really argue a different way, though if you're comparing to something else, or for a different kind of task, it's possible that you may have a different opinion, sure.
- throwawa14223 3y ago
  I felt like it had a lot to do things web related but was pretty lacking on primitives for algorithms and data structures out of the box.

flashgordon 3y ago

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.

axegon_ 3y ago

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.

chx 3y ago

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

deleted 3y ago

[deleted]

whatrg 3y ago

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

goku12 3y ago
> If you want a mediocre speed application with fast development, use Go I don't know if you can describe much of Kubernetes like that.

Gualdrapo 3y ago

https://www.youtube.com/watch?v=BN1WwnEDWAM https://www.youtube.com/watch?v=BN1WwnEDWAM

tubthumper8 3y ago

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.

eikenberry 3y ago

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.

vrmiguel 3y ago
One point that a lot of those "actually, just use Go" articles fail to recognize is that there is a sizable amount of developers who simply dislike programming in Go. Despite its impressive compilation speed and bundled tooling and whatnot, some (myself included) find it tedious and uninteresting to program in Go, with tons of repetition and verboseness. Some people are more utilitarian and don't mind, but not all think the same.
- eikenberry 3y ago
  Yep. For me Concurrency and CSP are why I learned Go and why I still use it today. I love thinking concurrently about problems and how data and control flow through those systems. It was a natural fit for me in those aspects and the other language warts don't get in the way enough to matter.

taylodl 3y ago

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

synergy20 3y ago

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.