12 ms·

Rust vs. Go in 2023

90 points by saikatsg 3y ago

peefy 3y ago
[dead]
IshKebab 3y ago
> You may have read articles and blog posts aiming to convince you that Go is better than Rust, or vice versa. But that really makes no sense; every programming language represents a set of trade-offs. Each language is optimised for different things, so your choice of language should be determined by what suits you and the problems you want to solve with it. That's sort of true, but I wish people would stop cowardly saying that you can't say that one language is better than another overall. That's clearly not true. IMO this article is very very long and doesn't really highlight the differences well, which IMO are: * Go has much faster compile times. * Rust's tooling is very good but I would still say Go's is better. It has built in fuzzing support! Cross compilation is as simple as setting an environment variable. * Rust is a little faster, and avoids GC. * Go's standard library is much more comprehensive than Rust's. * Go is much easier to learn and to read. * Rust is a better language if you have learnt it. It has much more powerful features (especially the functional ones) and is more principled. Going back to Go from Rust is frustrating. * Rust has a much stronger type system and the borrow checker. Both make bugs far less likely. * Async Rust is probably the worst bit about Rust. Go's goroutines are much easier to use. Though I would say traditional multithreaded code in Rust is pretty easy - it's just that a lot of the ecosystem forces you into async.
- LambdaComplex 3y ago
  Yeah, I really felt like this article had a lot of words and yet didn't actually convey much useful information—nor did it convey any information that hasn't been written about at length elsewhere. I also found this sentence to be confusing: > If you only have time to invest in learning one language well, don’t make your final decision until you’ve used both Go and Rust for a variety of different kinds of programs, large and small. So, if I only have the time to learn one language, I should...use two languages? For multiple projects? But somehow without learning them, because I don't have time?
- rapsey 3y ago
  If you are interfacing with other languages or running on mobile (as a library not a full app) Rust is the obvious right choice imo. In other situations the choice is not as clear cut.
- k_bx 3y ago
  Rust is your "last language". It's good for writing Python native modules, PostgreSQL native modules, compiling to WASM, all using the same libraries you love and know already. That is a big deal for me.
  - sgt 3y ago
    Can do the same with C, and it is still being improved. Safety is IMHO a bit overrated.
    - pjmlp 3y ago
      Until we finally get liability across the industry, then devs will think twice about shipping CVEs into production.
      - bombolo 3y ago
        Yeah multiple attempts are done to put liability on open source library developers. Terrible idea.
        pjmlp 3y ago
        Great idea, so far computing has been the exception, it is time to join the grow ups in responsibility how software affects the society. Everywhere else people ask for who's responsible when products don't match expectations, or are sold with faulty capabilities, unless the consumer protection laws of the country suck in protecting the citizens.
        bombolo 3y ago
        Do engineers often download projects from university students and then decide that the university student should get no money and all the jail time if the building falls?
        pjmlp 3y ago
- threeseed 3y ago
  > Rust is a little faster, and avoids GC Depending on what you're doing. I am finding that Rust is easily beating all of the non-C languages in terms of full support for the latest performance technologies e.g. io_uring, SIMD (AVX2/AVX512/NEON), DirectStorage, CUDA etc as well as the highest quality wrappers for C/C++ libraries. So for many applications Rust will simply leave Go for dust. In fact for me the only benefits of Go are single binary and startup time. Otherwise I find Rust to be ideal for when I need low level performance. And Scala to be significantly better for backend apps since its faster, has access to more libraries, better concurrency and a stronger type system resulting in much more reliable code.
  - ssokolow 3y ago
    > In fact for me the only benefits of Go are single binary and startup time. I hope you mean "compilation time" or "time to first prototype". My experience has been that, if a Rust binary doesn't start instantly, it's the fault of a specific library, not the language in general. Also, they ARE working on single-binary deployment for Rust... they just have a much more "Take your time and do it right. Don't hack around ecosystem flaws" approach than Go. If you're not cross-compiling/cross-deploying, Rust is already on par with non-cgo Go... you just need to use a musl-libc build target for Linux, specify RUSTFLAGS="-C target-feature=+crt-static" for Windows, etc. to get statically linked libc. (The musl-libc targets are a simple `rustup target add` away if your only C dependency is the libc itself.)
- diarrhea 3y ago
  > * Rust is a little faster, and avoids GC. I always wondered: how is it not much faster? Dealing with the borrow checker is immense overhead, yet performance gains are low compared to Go. Is Go's GC simply that good? Is Rust's compile-time GC about something other than performance somehow? I realize Go still needs to ship a minimal runtime in its binaries, but don't feel that's a meaningful burden compared to borrow checker fighting.
  - amedvednikov 3y ago
    GC is often faster than ownership. All the extra clones are costly.
    - _ahxg 3y ago
      That's a fair point, although there is a simple solution in Rust (and other RAII languages) to use heap allocation if what you want is moving big chunks of data (so only the pointer is moved) or in case you really want copies, reference counting (Rc/Arc in Rust).
    - thumbuddy 3y ago
      You don't have to clone... Really you don't. If you want fast rust code, learning how to avoid that is probably step 1.
  - lordnacho 3y ago
    It's not just a question of on average how much faster it is, it's a question of whether the distribution of latencies matters.
  - antonvs 3y ago
    > Is Rust's compile-time GC about something other than performance somehow? Predictability and determinism: In some environments, GC pauses are problematic. Modern GCs in Go and Java running on fast enough CPUs can generally keep pause times down below 1 ms, but on a multi-GHz CPU that's multiple million clock cycles - a virtual eternity in some contexts. Memory usage: GCs waste memory in exchange for performance. Go's GC doesn't compact (last I checked), so fragments the heap. Ability to have no runtime: in some environments, the need for a runtime is problematic. That's a big part of why the Linux kernel supports Rust but not Go. All of these issues tend to be more significant in e.g. hard real time contexts, in embedded environments with less powerful processors, etc. Also btw "borrow checker fighting" is not much of an issue for experienced Rust developers. You quickly get used to how to write code to avoid borrow checker issues. And in general, writing code that way tends to be a good thing anyway.
- atmosx 3y ago
  > Go's goroutines are much easier to use. True. Golang multithreading is easy to reason to about. I had to make some mental gymnastics to write multithreaded scripts in Ruby and Python. The Golang implementation was the easiest by far.
- brabel 3y ago
  > Rust has a much stronger type system and the borrow checker. Both make bugs far less likely. I really prefer strong type systems over weak ones, but despite that, I always like to point out that there's no evidence that strong type systems cause "bugs to be far less likely". No study I've seen (quite a few) has ever shown that. There's a few bugs that become impossible (in Rust, some kinds of data races for example) but the vast majority of bugs can still occur and in practice, do occur.
  - orwin 3y ago
    The main advantage to me is more that I don't have to write tests to test type integrity accross functions.
    - lelanthran 3y ago
      I've never found myself doing that in Go.
      - orwin 3y ago
        I was talking about strongly typed languages, which Go is. That's why I'd rather use go than python at my job (not an option though).
        IshKebab 3y ago
        Rust is even more strongly typed than Go, so it reduces the chance of bugs even more. The borrow checker also reduces the chance of bugs. It was originally created just for memory safety, but it turns out that the ownership structures that it enforces are less bug prone. It's quite similar to how using immutable data structures leads to less bug prone code.
  - IshKebab 3y ago
    > No study I've seen (quite a few) has ever shown that. There's a really great one that shows that Typescript or Flow prevents around 15% of Javascript bugs. It would be difficult for a study to show that Rust's strong typing or borrow checker prevents bugs, but anyone who has used Rust extensively knows it to be true. It's similar to Haskell's strong types and immutability preventing bugs. Google "if it compiles it works". I think you could do a study to prove this, but experiments aren't the only way to get knowledge. They are the best when possible but sometimes they are impractical. Programming language studies tend to focus on "get some students to spend a few hours writing code from scratch" tasks which can even lead to conclusions that are the opposite of reality for realistic programming. For example that static types hurt productivity. > the vast majority of bugs can still occur and in practice, do occur. Right, but they are much less likely to occur.
- luuio 3y ago
  At least two reasons I'm not choosing Go: - Go (the language) is missing the ability to declare something immutable. I don't mean making fields in a struct private then exposing getters. I mean the equivalent of an immutable reference in Rust or `const ref` in C++. - Go mod and go workspace still can't get a cohesive story together [1]: - - If my module wants to depend on another module in a workspace, `go mod tidy` would freak out. - - If I use replace in my go mod file to point to the other modules in the same workspace, `go mod vendor` will copy these workspace modules to the vendor folder as well. [1] https://github.com/golang/go/issues/50750 https://github.com/golang/go/issues/50750
gerardpg 3y ago
Go needs more syntactic sugar.
- barnabee 3y ago
  I honestly think the only remaining thing I'd need from Go to almost never pick up Rust for a new project is sum types. If there was a NewGo with no concept of a raw 'nil' value (replaced by Maybe<T>) and err, res in the standard library replaced with Result<T, E>, I'd have vanishingly few reasons to use Rust. If we got TinyNewGo too for embedded/WASM… uh oh
  - efnx 3y ago
    If Go had sum types it would be a completely different language - compile times would skyrocket and it would likely look like Rust without the borrow checker. Personally I think it would be better than Go, but I think most Go folks would dislike it. For me the big draw of Go (which are few) is the compile time.
    - SkiFire13 3y ago
      What makes you think that sum types make compile time skyrocket?
      - efnx 3y ago
        Because it introduces a different type system like Hendly-Milner. One of the reasons Go has incredible compile times is because it doesn’t have to calculate types the way Haskell, Rust and other ML-like languages do.
        fl0ki 3y ago
        Go already faces a subset of this type system challenge in an arguably much worse way: interfaces are implicitly implemented by any type with the corresponding set of method signatures, unlike Rust where traits are implemented explicitly. In that sense, Go already has sum types with how it handles interfaces, but having to check every single method instead of a single trait. In Rust trait solving can only affect compile time, in Go it affects runtime [1]. Anyone who has looked into optimizing Go performance enough has seen what a horror this can be, and it's hard to watch people say that Go's type system is one of its strengths. Really, most of the people speculating on why Rust compiles are slow simply haven't read how much analysis has already gone into it [2]. We already know the majority of why they're slow: Rust generates a lot of LLVM IR and LLVM has to process that as-is before it can eliminate the redundant parts and optimize the rest. A complementary issue is that if you use a lot of proc macros, their code has to run before the rest of the compile can even begin, and they often emit a lot of code that becomes a lot of LLVM IR. There are workarounds for both parts -- you can optimize the proc macro compilation itself, and you can keep proc macro code (serde schemas, etc) to a separate crate in the same workspace so they are cached for more of the time. These remain real issues with real tradeoffs, but either way, this has absolutely nothing to do with how long type checking itself takes. If anything, it seems pretty quick given how much macro-generated code it has to check. The easiest way to see that is to run cargo clippy instead of cargo build. Even despite the enormous breadth & depth of analysis that clippy does -- far beyond simply checking if types are satisfied, and worlds beyond what golangci-lint can analyze -- it doesn't take that much longer than golangci-lint alone. That's bearing in mind it still has to expand the proc macros too. Finally, Go does a good job at transparently caching a lot of its build artifacts, much more than Cargo/Rust. If you completely clear your compile cache, you'll notice it can take a lot longer in Go as well. I'm not saying that's not an advantage to Go in practice, just that -- again -- it has nothing to do with the type system. I urge people to speculate less about what makes Rust compiles take longer and catch up on the analysis already done. Even if you don't care about Rust, at least you'll have a better idea of what tradeoffs Go can explore in future, instead of simply assuming that any deviation from what Go does today would make compile times "skyrocket". That's not a useful way to reason about language and toolchain tradeoffs, especially not when real data are never more than a web search away. [1] https://planetscale.com/blog/generics-can-make-your-go-code-slower https://planetscale.com/blog/generics-can-make-your-go-code-... [2] https://www.pingcap.com/blog/reasons-rust-compiles-slowly/ https://www.pingcap.com/blog/reasons-rust-compiles-slowly/
amedvednikov 3y ago
[flagged]
- born-jre 3y ago
  Love the hustle. :D
- fuzztester 3y ago
  >(no err != nil checks), How does that work in practice? Example please.
  - amedvednikov 3y ago
    V uses Result types for handling errors, and the developer must handle them by propagating the error or breaking/returning or panicing. For example: // os.v fn open(path string) !File {} // main.v file := os.open('out.txt') or { panic('failed to open: $err') } file := os.open('out.txt') or { return } file := os.open('out.txt')! // propagate the error if file := os.open('out.txt') {} // alternative scoped syntax
    - deleted 3y ago
      [deleted]
    - fuzztester 3y ago
      Thanks. V syntax looks somewhat clear.
- parabyl 3y ago
  Spent a few months writing a pretty hefty Cqrs app in Go last year, had a fun but pretty unintuitive experience with rustlingss, and V really does seem like a cool in between! I look forward to taking it for a spin
- microtonal 3y ago
  Would be nice to add a short disclaimer that you are the author of the V language (at least it seems from your username, correct me if I'm wrong). There are many new languages in the same space (Zig, Nim, V). However, if you use a language outside hobby projects, you are dependent on a language having a long-term healthy ecosystem. Of the newer native languages, only Rust, Go, and Swift have enough traction to bet your livelihood on. In the end, having a rich ecosystem with good libraries and tools is going to leave a far bigger mark on productivity than relatively small differences between Rust, V, Zig, Nim, D, or whatever.
zarzavat 3y ago
Rust vs Go is like Jeep vs Prius. They both do the same kind of thing, but in such contrary ways that I don’t think anyone is confused which one they want.
anyfactor 3y ago
I don't get paid to write code in these languages; my enthusiasm in exploring them is limited by the amount of energy I have over the weekend. Honestly, I don't see Rust as anything but a code-rewrite language. I find Rust to be unintuitive, and I don't think it is a language designed to be a "problem solver. So, what do I mean by a problem solver? If you have a problem and you write code by exploring different solutions, continuously improve, and write hacky stuff where the goal is to simply solve a problem. Rust is not a problem solver; it is going to fight you all the way through because of its emphasis on programmatic correctness. With Rust, you have to have the solution first, consider the language-specific caveats, and write something in such a way that you don't go back and have to improve it. I suppose that is how programming is supposed to be done - in a clear and structured manner. But let's admit it, nobody does that. On the other hand, Go is a language that sits between Python and Rust. Python is THE problem solver language, and Rust is an elegant and good etiquette language. Go just works as a hackable language with the benefits of a compiled language and type support. My plan with Rust vs Go for the time being: - If I need to solve a problem and can do continuous improvement on the codebase → Go - If I have the problem solved, I have the resources to do a rewrite → Rust
- peterfirefly 3y ago
  My first (and so far only) Rust program was an 8088 disassembler. Rust made it easy for me to try "different solutions, continuously improve, and write hacky stuff". Perhaps it's more a question of background? Rust contains many features I already know from the ML family + it formalizes the way I've already been thinking about memory since the early 90's.
  - brabel 3y ago
    Now try that on some domain you're not familiar with... If you ever have to change lifetimes of existing functions/structs on a non-trivial Rust code base, you're screwed.
    - baq 3y ago
      Observation: Lifetimes are Rust’s checked exceptions in that regard. Changes propagate in the wrong direction - from leafs of the import tree down to the root. Solutions though… can’t really imagine one that makes sense.
zozbot234 3y ago
Go is only memory safe for simple sequential code. Most concurrent Go programs share memory among threads/goroutines in an unsafe way.
- kaba0 3y ago
  That causes concurrency issues, but that is not what is commonly understood by memory safety. With that said, Go indeed gives you plenty of rope to hang yourself with in relation to concurrency (among others).
  - skitter 3y ago
    Technically, there's memory unsafe memory sharing: Interfaces and slices are mutable and consist of multiple word that are accessed without synchronization, sharing a reference to a interface or slice between goroutines means you can get a mismatch between vtable ptr/data ptr or data ptr/length.
    - kaba0 3y ago
      That is again, language-dependent. Java for example can memory-safely have data races, even those that tear (what you are referring to here). Not the standard, but OpenJDK itself also has a guarantee that every value that any thread could observe was actually set by some other thread, so on incrementing a number from 0 from multiple threads you can never get -37, but for surely can observe an older value.
- jedisct1 3y ago
  On the other hand, goroutines makes it very easy to write concurrent code. And the built-in checker for race conditions works well. Async Rust, OTOH, can quickly become a horrible spaghetti mess that's virtually impossible to debug, and where common things such as cancellation are very challenging. My networks servers written in Rust are unsafe. I know they have dead locks, memory safety issues (due to usage or shared arrays and slabs to avoid allocations and work around the borrow checker), can be remotely DOS'd, leak memory (due to Rc, cycles or whatever), and have hacks to work around APIs that are not easy to use, just to make the borrow checker happy. Doing simple things such as listening to multiple IP addresses can require a major refactor. At the end of the day, after the excitement of having written a first version of these projects, I have a hard time understanding and fixing the remaining bugs, and eventually stop maintaining them. The ecosystem is also unstable. Dealing with major changes, or crates that need to be replaced because of deprecation/abandon makes applications unsafe. "crap, after cargo upgrade, that doesn't compile any more. Let's randomly fiddle around so that it compiles again". The version with the new crates doesn't get tested as much as the previous one. If they behave differently, or if to get the behavior of function X, now one should call function Y because X now does something else, the application is not as safe as when originally written. My network servers written in Go probably have plenty of bugs, but I can understand what's going on and fix them. I can dive into the code of the dependencies and of the standard library, follow and understand how things work under the hood. With Go's rich standard library, I also don't need to rely on a ton of dependencies, that will constantly be abandoned or introduce breaking API changes. So I can stay focused on the application logic, and eventually, the Go servers are way safer from a practical perspective. And for something that must be maintained on the long term, Go also wins hands down.
xyproto 3y ago
Pretty balanced article, but I think it skips over the (for me) main points of using Go: * Go was developed within Google, mainly as a response to C++ projects that had grown unwieldy, in terms of dependencies and compilation speed. As a result, the language is designed from scratch with compilation speed in mind, and unused dependencies are disallowed. * There are few changes to the language. When a new Go compiler is released, I go "nice, wonder which tooling and performance improvements are present" and not "oh no, how many repositories will need patches". Go code can be expected to compile 10+ years ahead. The same is not always the case for C, C++, Zig and possibly even Rust. * Deployment and crosscompilation is straightforward.
- usrnm 3y ago
  > The same is not always the case for C, C++ That's just completely not true, especially for C. There is a lot of C code older than most commenters on this site that's still used in production and compiled with modern compilers
  - deleted 3y ago
    [deleted]
- bestouff 3y ago
  > and possibly even Rust. This is patently false. Rust has a severe backwards compatibility policy.
- deaddodo 3y ago
  > Go code can be expected to compile 10+ years ahead. The same is not always the case for C, C++, Zig and possibly even Rust. I'm sorry, but this comment just seems so blind to reality that it's hard not to comment on. C has a few particularly strong selling points: * Orthogonality to machine architectures * Freestanding (STD-free, in modern language parlance) compilation * An extremely conservative ruling body The latter is usually listed as a double-edged sword, since there are many new features people would like in C: true generics, polymorphic (overloaded) functions (without using the pre-processor), a true module system, etc; but it also means extremely old code compiles just fine on modern C compilers. Now, it might not work because it might be built for some bespoke hardware/environment, but the code will compile fine and be correct. For instance, here's a perfectly valid ANSI C application that will compile on any C compiler in the last 35 years (three times as long as Go has existed): https://godbolt.org/z/ja6WM5feT https://godbolt.org/z/ja6WM5feT Most of the features added in C11, C17 and C23 are additional features, usually with no backwards breaking changes. However, in some cases they do clarify undefined behavior; which can break old code. This is why most of the major modern compilers add flags to compile in specific dialects. Additionally, there are plenty of Go 1.0 (the first [and only] "10+" [11] year old version) codebases that won't compile without major changes.
Havoc 3y ago
I was agonizing over this choice too. Eventually rust won: * Feels closer to the good old Pascal days where you control everything * Safer bet should wasm & friends explode * Already have python for quick & dirt so picking something more extreme made sense. Go feels sorta in the middle * Its in kernel & loads of hype so unlikely to go away
ducktective 3y ago
>Which is better, Rust or Go? Go or Rust? Which language should you choose for your next project in 2023, and why? Meanwhile, I'm here considering Common Lisp :) Not being able to generate a statically compiled binary is an issue though...
- fuzztester 3y ago
  I've read that SBCL can. Some other Lisps may too.
  - ducktective 3y ago
    > I've read that SBCL can. No, it would depend on host libc
    - fuzztester 3y ago
      Why? Something to do with static or dynamic linking? Anyway, I'm almost sure I've read multiple times on HN that SBCL can do it, in some threads about Lisp, including recent ones.
- cookiengineer 3y ago
  If you aren't nailed down on lisp but scheme would be an option for you, there's cyclone [1] which also has FFI and C ABI support iirc. [1] https://github.com/justinethier/cyclone https://github.com/justinethier/cyclone
bamazizi 3y ago
I've tried Rust for a short while to get a good feel. I've been Go developer for nearly a decade. Unfortunately there's a bit of a forced and misleading Rust favoritism the days but from my experience in various startups, including my current one, Go is by far the best choice for backend development! - Rust is not suitable for fast paste startup environment - Rust is not suitable if the initial team members are not Rust experts - Rust is not suitable if the startup doesn't have money (Rust devs are very expensive and scarce) - Rust is not general hire friendly - Rust is not ideal for iterative and high refactor potential of startup culture - Rust is painful/heartbreaking when eventuality of a pivot approaches - Rust is not an advantage in anything startup related Go is the exact opposite of above points! Note: I didn't talk about performance, feature or whatever else ... both languages are very very close to each other!
- toasted-subs 3y ago
  I’d hire a Python developer any day of the week over either Go/Rust. Need some data science work done, easy. Need a web server done, easy. Need things to be fast and relatively performant done, easy.
  - smolder 3y ago
    > Python > fast This is only true if you are relying mainly on compiled extensions to do the performance-critical work. Unassisted raw python is super slow compared to Go or Rust.
    - memefrog 3y ago
      So what? That's how things are structured in Python. It's one of the advantages of the language. Sure it'd be nice to be like Common Lisp, where you can write dynamic/slow and optimised/fast code in the same language, depending on (declare). But Python is the next best thing. If you want to write slow, dynamic, hacky code in Rust you have to write 'unwrap' and 'clone' all over the place, obscuring the logic.
      - 3y ago
kaba0 3y ago
Rust and Go have almost no relation to each other - one is a low-level language, like C, C++, the other is a high-level one like Java, C#, Haskell. These articles and this general notion that the two has some relevance to each other is just plain wrong and harmful.
- impulser_ 3y ago
  There are definitely relations between them. They are often used in the same domains. Servers, DevOps, CLI, tooling ect. Just because one has manual memory management and other is GC doesn't mean they aren't relatable.
  - kaba0 3y ago
    Python is also used in those niches, let’s add that also to the list.
  - orwin 3y ago
    The only 'natural' niche for Rust in your list is CLI. Which, by the way, I wouldn't really use go for unless it's a CLI for a daemon/remote program. I guess Rust can be used for the rest but imho you won't use rust's advantages. One of my favorites being memory manipulation. Rust truly shine for low-level programming imho, but more power to you if you're using it as your generalist language.
    - ssokolow 3y ago
      I think they're all natural niches, because Rust's performance and ability to tightly control memory allocation are over-promoted and the strength of the type system as a means of ensuring correctness at compile time is underpromoted. Especially web use is one of the biggest places you want to be able to rely on the compiler, aided by patterns like the newtype pattern and the typestate patterns, to catch as many potential DoS or security bugs as possible. I use Rust as "Haskell, but without having to put up with writing Haskell". (Or, more commonly, I say that Rust is the sweet spot where you've taken pretty much everything functional programming has to offer before you start falling off a return-on-investment cliff.)
kif 3y ago
What is the recommended resource that helps one become proficient at Rust nowadays?
- speedgoose 3y ago
  I would recommend ChatGPT. It’s pretty good at pretending to understand your struggles with rust. You can explain your issues and swear a lot and you will get a nice explanation in return.
  - jedisct1 3y ago
    Joke apart, yes. ChatGPT can sometimes be more useful than rustc error messages. However, the code you need it to explain have to be small and self-contained. When it's part of an actual project, preparing a proper prompt requires a bit of work.
  - mariusor 3y ago
    > and you will get a nice explanation in return Which might or might not be correct.
    - speedgoose 3y ago
      Like everything your read yes.
      - mariusor 3y ago
        No, not like everything you read at all.
- peterfirefly 3y ago
  What has worked for me so far: https://doc.rust-lang.org/book/ https://doc.rust-lang.org/book/ (do the exercises!) plus a little bit of: https://doc.rust-lang.org/cargo/ https://doc.rust-lang.org/cargo/ and https://doc.rust-lang.org/std/index.html https://doc.rust-lang.org/std/index.html (There's no need to remember the last URL -- just google "rust xxx" and you will get the right page.) I'm looking forward to reading this: https://nnethercote.github.io/perf-book/introduction.html https://nnethercote.github.io/perf-book/introduction.html Sprinkle some blog posts on top: https://xxchan.me/cs/2023/02/17/optimize-rust-comptime-en.html https://xxchan.me/cs/2023/02/17/optimize-rust-comptime-en.ht... https://matklad.github.io/2021/05/31/how-to-test.html https://matklad.github.io/2021/05/31/how-to-test.html https://matklad.github.io/2021/08/22/large-rust-workspaces.html https://matklad.github.io/2021/08/22/large-rust-workspaces.h... https://fasterthanli.me/articles/a-half-hour-to-learn-rust https://fasterthanli.me/articles/a-half-hour-to-learn-rust https://fasterthanli.me/articles/working-with-strings-in-rust https://fasterthanli.me/articles/working-with-strings-in-rus... ... and the rest is just a matter of applying enough sweat :)
satvikpendem 3y ago
Whenever I see comparisons between Rust and Go, I'm always reminded of fasterthanlime's I want off Mr Golang's wild ride [0] as well as its sequel Lies we tell ourselves to keep using Golang [1]. Having used both, Go hides its complexity behind the veneer of simplicity while being more tedious and error prone as the codebase grows while Rust brings the complexity to you upfront while preventing errors later. Personally, even simply due to language features like algebraic data types in other languages, I really have no reason to use Go anymore. There's an oft-said quip that says that the Go language designers took the last 50 years of programming language theory and simply...threw it away. Plus, to those saying it's easier to hack stuff together in other languages than Rust, I simply clone everywhere and Rust then becomes the same as a garbage collected language. You don't have to deal with lifetimes and excessive cloning from the get go, deal with that after experimenting then optimize, same as you would for any other language. The plethora of language features in Rust make it easier to hack around in, in actuality. [0] https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... [1] https://fasterthanli.me/articles/lies-we-tell-ourselves-to-keep-using-golang https://fasterthanli.me/articles/lies-we-tell-ourselves-to-k...
- thumbuddy 3y ago
  Infact... Early stages of a project should make heavy use of owned and cloned types while you figure out the bottlenecks and work out how to architect the solution.
pjmlp 3y ago
Most of my complaints against Go are kind of waned, however can we at very least have Pascal like enumerations without iota const dance?
- fuzztester 3y ago
  I don't like that iota stuff either.
colonwqbang 3y ago
Interesting that he selected "match" as example of a complex Rust feature. To me, "match"/"case" is one of the simplest and cleanest abstractions in programming languages.
- glandium 3y ago
  Honestly, I've found match more annoying (and I suspect it's more confusing for newcomers), ever since match ergonomics were stabilized. I do see how it helps some simple cases, but it makes things awfully confusing in so many other cases...
  - thumbuddy 3y ago
    That's wild. First time I saw a match case, if let, and matches! Invocation I was freaking relieved. No by hand type checking in a dynamic language, having to consider corner cases, etc. LSP even autocompletes the cases with a single hotkey. Escape from boilerplate hell.
- ssokolow 3y ago
  *nod* Aside from the obvious (compile-time guarantees beyond MyPy's ability to offer), the lack of pattern matching and an accompanying ecosystem that evolved in its presence is my number one discomfort when writing Python for things like my QWidget GUI frontends for Rust backends.
benrutter 3y ago
I think this article is a nice summary of the languages, but the opening set up bugs me: > Which is better, Rust or Go? Go or Rust? Which language should you choose for your next project in 2023, and why? I blame the "rewrite everything in Rust" crowd, but there seems to be a resurgence lately of the idea that there is One True Programming Language you should use for everything. I don't particularly fancy using an OS written in Go, and I don't want to work on web architecture projects in Rust. Similarly, I don't want to work with someone who is going to write shell scripts or basic utility tasks in Rust because the performance is faster.
- ssokolow 3y ago
  Odd. I wish Rust had Django's ecosystem so I could do more Rust web stuff, and I do use Rust for "shell scripts" and basic utility tasks, not for the performance, but for the compile-time guarantees. I'd much rather pay a little extra up-front in resolving compiler errors, so I can know I'm not going to wake up to something like a six-hour batch job that failed 5% through or slam face-first into needing to debug an exception when I'm already in a rush and stressed over it. Likewise, I find Rust's syntax much more pleasant than Go's... probably because I can see that Rust's syntactic complexity means things that have value to me, while Go's is just repetitive boilerplate to make my time a sacrifice on the altar of dogmatic language simplicity.
revskill 3y ago
The fact that, in the official Rust Book, the author even don't know how to write Higher order function in Chapter 1 said something about Rust. Just write down how to do good functional programming with currying, HOC right in chapter 1 and all is good. Don't treat reader as "zero-knowledge beginner".
- peterfirefly 3y ago
  Why would you want currying? It is one of least useful/most dumb features of old-skool applicative languages. It is often combined with a really dumb "no parentheses" attitude to arguments. If you really need something akin to currying (which you rarely do), why not use a closure as a wrapper? // x and y are captured from the environment | a | func_that_takes_3_args(x, y, a)
truth_seeker 3y ago
The difference/tradeoff shown in the blog fades away in developers psychology as they write more code and ship apps, so I would not held them high. In my experience, compared to Golang, the only (mild) downside of Rust is not so big STD lib, compilation time and initial learning curve. Frankly speaking its neither a blocker nor a big deal. Once learning phase of Rust is passed, you have one language which you can use anywhere and can trust to produce efficient code both from readability and performance point of view.
msie 3y ago
After reading many comments here the one that appeals to me is the readability of go code. There was this moment of ruby vs python where I was delighted by the readability of python code and how I could easily read the code of python libs as well. I feel this is the same with go. I can imagine the rust wizards easily making hard to read code.
luuio 3y ago
At least two reasons I'm not choosing Go: - Go (the language) is missing the ability to declare something immutable. I don't mean making fields in a struct private then exposing getters. I mean the equivalent of an immutable reference in Rust or `const ref` in C++. - Go mod and go workspace still can't get a cohesive story together [1]: - - If my module wants to depend on another module in a workspace, `go mod tidy` would freak out. - - If I use replace in my go mod file to point to the other modules in the same workspace, `go mod vendor` will copy these workspace modules to the vendor folder as well. [1] https://github.com/golang/go/issues/50750 https://github.com/golang/go/issues/50750
leighmcculloch 3y ago
The article doesn't discuss one of the most significant differences between building in Go and Rust: tooling.

Rust vs. Go in 2023

90 points by saikatsg 3y ago

[dead]

> You may have read articles and blog posts aiming to convince you that Go is better than Rust, or vice versa. But that really makes no sense; every programming language represents a set of trade-offs. Each language is optimised for different things, so your choice of language should be determined by what suits you and the problems you want to solve with it. That's sort of true, but I wish people would stop cowardly saying that you can't say that one language is better than another overall. That's clearly not true. IMO this article is very very long and doesn't really highlight the differences well, which IMO are: * Go has much faster compile times. * Rust's tooling is very good but I would still say Go's is better. It has built in fuzzing support! Cross compilation is as simple as setting an environment variable. * Rust is a little faster, and avoids GC. * Go's standard library is much more comprehensive than Rust's. * Go is much easier to learn and to read. * Rust is a better language if you have learnt it. It has much more powerful features (especially the functional ones) and is more principled. Going back to Go from Rust is frustrating. * Rust has a much stronger type system and the borrow checker. Both make bugs far less likely. * Async Rust is probably the worst bit about Rust. Go's goroutines are much easier to use. Though I would say traditional multithreaded code in Rust is pretty easy - it's just that a lot of the ecosystem forces you into async.

LambdaComplex 3y ago
Yeah, I really felt like this article had a lot of words and yet didn't actually convey much useful information—nor did it convey any information that hasn't been written about at length elsewhere. I also found this sentence to be confusing: > If you only have time to invest in learning one language well, don’t make your final decision until you’ve used both Go and Rust for a variety of different kinds of programs, large and small. So, if I only have the time to learn one language, I should...use two languages? For multiple projects? But somehow without learning them, because I don't have time?
rapsey 3y ago
If you are interfacing with other languages or running on mobile (as a library not a full app) Rust is the obvious right choice imo. In other situations the choice is not as clear cut.
k_bx 3y ago
Rust is your "last language". It's good for writing Python native modules, PostgreSQL native modules, compiling to WASM, all using the same libraries you love and know already. That is a big deal for me.
- sgt 3y ago
  Can do the same with C, and it is still being improved. Safety is IMHO a bit overrated.
  - pjmlp 3y ago
    Until we finally get liability across the industry, then devs will think twice about shipping CVEs into production.
    - bombolo 3y ago
      Yeah multiple attempts are done to put liability on open source library developers. Terrible idea.
      - pjmlp 3y ago
        Great idea, so far computing has been the exception, it is time to join the grow ups in responsibility how software affects the society. Everywhere else people ask for who's responsible when products don't match expectations, or are sold with faulty capabilities, unless the consumer protection laws of the country suck in protecting the citizens.
        bombolo 3y ago
        Do engineers often download projects from university students and then decide that the university student should get no money and all the jail time if the building falls?
        pjmlp 3y ago
threeseed 3y ago
> Rust is a little faster, and avoids GC Depending on what you're doing. I am finding that Rust is easily beating all of the non-C languages in terms of full support for the latest performance technologies e.g. io_uring, SIMD (AVX2/AVX512/NEON), DirectStorage, CUDA etc as well as the highest quality wrappers for C/C++ libraries. So for many applications Rust will simply leave Go for dust. In fact for me the only benefits of Go are single binary and startup time. Otherwise I find Rust to be ideal for when I need low level performance. And Scala to be significantly better for backend apps since its faster, has access to more libraries, better concurrency and a stronger type system resulting in much more reliable code.
- ssokolow 3y ago
  > In fact for me the only benefits of Go are single binary and startup time. I hope you mean "compilation time" or "time to first prototype". My experience has been that, if a Rust binary doesn't start instantly, it's the fault of a specific library, not the language in general. Also, they ARE working on single-binary deployment for Rust... they just have a much more "Take your time and do it right. Don't hack around ecosystem flaws" approach than Go. If you're not cross-compiling/cross-deploying, Rust is already on par with non-cgo Go... you just need to use a musl-libc build target for Linux, specify RUSTFLAGS="-C target-feature=+crt-static" for Windows, etc. to get statically linked libc. (The musl-libc targets are a simple `rustup target add` away if your only C dependency is the libc itself.)
diarrhea 3y ago
> * Rust is a little faster, and avoids GC. I always wondered: how is it not much faster? Dealing with the borrow checker is immense overhead, yet performance gains are low compared to Go. Is Go's GC simply that good? Is Rust's compile-time GC about something other than performance somehow? I realize Go still needs to ship a minimal runtime in its binaries, but don't feel that's a meaningful burden compared to borrow checker fighting.
- amedvednikov 3y ago
  GC is often faster than ownership. All the extra clones are costly.
  - _ahxg 3y ago
    That's a fair point, although there is a simple solution in Rust (and other RAII languages) to use heap allocation if what you want is moving big chunks of data (so only the pointer is moved) or in case you really want copies, reference counting (Rc/Arc in Rust).
  - thumbuddy 3y ago
    You don't have to clone... Really you don't. If you want fast rust code, learning how to avoid that is probably step 1.
- lordnacho 3y ago
  It's not just a question of on average how much faster it is, it's a question of whether the distribution of latencies matters.
- antonvs 3y ago
  > Is Rust's compile-time GC about something other than performance somehow? Predictability and determinism: In some environments, GC pauses are problematic. Modern GCs in Go and Java running on fast enough CPUs can generally keep pause times down below 1 ms, but on a multi-GHz CPU that's multiple million clock cycles - a virtual eternity in some contexts. Memory usage: GCs waste memory in exchange for performance. Go's GC doesn't compact (last I checked), so fragments the heap. Ability to have no runtime: in some environments, the need for a runtime is problematic. That's a big part of why the Linux kernel supports Rust but not Go. All of these issues tend to be more significant in e.g. hard real time contexts, in embedded environments with less powerful processors, etc. Also btw "borrow checker fighting" is not much of an issue for experienced Rust developers. You quickly get used to how to write code to avoid borrow checker issues. And in general, writing code that way tends to be a good thing anyway.
atmosx 3y ago
> Go's goroutines are much easier to use. True. Golang multithreading is easy to reason to about. I had to make some mental gymnastics to write multithreaded scripts in Ruby and Python. The Golang implementation was the easiest by far.
brabel 3y ago
> Rust has a much stronger type system and the borrow checker. Both make bugs far less likely. I really prefer strong type systems over weak ones, but despite that, I always like to point out that there's no evidence that strong type systems cause "bugs to be far less likely". No study I've seen (quite a few) has ever shown that. There's a few bugs that become impossible (in Rust, some kinds of data races for example) but the vast majority of bugs can still occur and in practice, do occur.
- orwin 3y ago
  The main advantage to me is more that I don't have to write tests to test type integrity accross functions.
  - lelanthran 3y ago
    I've never found myself doing that in Go.
    - orwin 3y ago
      I was talking about strongly typed languages, which Go is. That's why I'd rather use go than python at my job (not an option though).
      - IshKebab 3y ago
        Rust is even more strongly typed than Go, so it reduces the chance of bugs even more. The borrow checker also reduces the chance of bugs. It was originally created just for memory safety, but it turns out that the ownership structures that it enforces are less bug prone. It's quite similar to how using immutable data structures leads to less bug prone code.
- IshKebab 3y ago
  > No study I've seen (quite a few) has ever shown that. There's a really great one that shows that Typescript or Flow prevents around 15% of Javascript bugs. It would be difficult for a study to show that Rust's strong typing or borrow checker prevents bugs, but anyone who has used Rust extensively knows it to be true. It's similar to Haskell's strong types and immutability preventing bugs. Google "if it compiles it works". I think you could do a study to prove this, but experiments aren't the only way to get knowledge. They are the best when possible but sometimes they are impractical. Programming language studies tend to focus on "get some students to spend a few hours writing code from scratch" tasks which can even lead to conclusions that are the opposite of reality for realistic programming. For example that static types hurt productivity. > the vast majority of bugs can still occur and in practice, do occur. Right, but they are much less likely to occur.
luuio 3y ago
At least two reasons I'm not choosing Go: - Go (the language) is missing the ability to declare something immutable. I don't mean making fields in a struct private then exposing getters. I mean the equivalent of an immutable reference in Rust or `const ref` in C++. - Go mod and go workspace still can't get a cohesive story together [1]: - - If my module wants to depend on another module in a workspace, `go mod tidy` would freak out. - - If I use replace in my go mod file to point to the other modules in the same workspace, `go mod vendor` will copy these workspace modules to the vendor folder as well. [1] https://github.com/golang/go/issues/50750 https://github.com/golang/go/issues/50750

gerardpg 3y ago

Go needs more syntactic sugar.

barnabee 3y ago
I honestly think the only remaining thing I'd need from Go to almost never pick up Rust for a new project is sum types. If there was a NewGo with no concept of a raw 'nil' value (replaced by Maybe<T>) and err, res in the standard library replaced with Result<T, E>, I'd have vanishingly few reasons to use Rust. If we got TinyNewGo too for embedded/WASM… uh oh
- efnx 3y ago
  If Go had sum types it would be a completely different language - compile times would skyrocket and it would likely look like Rust without the borrow checker. Personally I think it would be better than Go, but I think most Go folks would dislike it. For me the big draw of Go (which are few) is the compile time.
  - SkiFire13 3y ago
    What makes you think that sum types make compile time skyrocket?
    - efnx 3y ago
      Because it introduces a different type system like Hendly-Milner. One of the reasons Go has incredible compile times is because it doesn’t have to calculate types the way Haskell, Rust and other ML-like languages do.
      - fl0ki 3y ago
        Go already faces a subset of this type system challenge in an arguably much worse way: interfaces are implicitly implemented by any type with the corresponding set of method signatures, unlike Rust where traits are implemented explicitly. In that sense, Go already has sum types with how it handles interfaces, but having to check every single method instead of a single trait. In Rust trait solving can only affect compile time, in Go it affects runtime [1]. Anyone who has looked into optimizing Go performance enough has seen what a horror this can be, and it's hard to watch people say that Go's type system is one of its strengths. Really, most of the people speculating on why Rust compiles are slow simply haven't read how much analysis has already gone into it [2]. We already know the majority of why they're slow: Rust generates a lot of LLVM IR and LLVM has to process that as-is before it can eliminate the redundant parts and optimize the rest. A complementary issue is that if you use a lot of proc macros, their code has to run before the rest of the compile can even begin, and they often emit a lot of code that becomes a lot of LLVM IR. There are workarounds for both parts -- you can optimize the proc macro compilation itself, and you can keep proc macro code (serde schemas, etc) to a separate crate in the same workspace so they are cached for more of the time. These remain real issues with real tradeoffs, but either way, this has absolutely nothing to do with how long type checking itself takes. If anything, it seems pretty quick given how much macro-generated code it has to check. The easiest way to see that is to run cargo clippy instead of cargo build. Even despite the enormous breadth & depth of analysis that clippy does -- far beyond simply checking if types are satisfied, and worlds beyond what golangci-lint can analyze -- it doesn't take that much longer than golangci-lint alone. That's bearing in mind it still has to expand the proc macros too. Finally, Go does a good job at transparently caching a lot of its build artifacts, much more than Cargo/Rust. If you completely clear your compile cache, you'll notice it can take a lot longer in Go as well. I'm not saying that's not an advantage to Go in practice, just that -- again -- it has nothing to do with the type system. I urge people to speculate less about what makes Rust compiles take longer and catch up on the analysis already done. Even if you don't care about Rust, at least you'll have a better idea of what tradeoffs Go can explore in future, instead of simply assuming that any deviation from what Go does today would make compile times "skyrocket". That's not a useful way to reason about language and toolchain tradeoffs, especially not when real data are never more than a web search away. [1] https://planetscale.com/blog/generics-can-make-your-go-code-slower https://planetscale.com/blog/generics-can-make-your-go-code-... [2] https://www.pingcap.com/blog/reasons-rust-compiles-slowly/ https://www.pingcap.com/blog/reasons-rust-compiles-slowly/

amedvednikov 3y ago

[flagged]

born-jre 3y ago
Love the hustle. :D
fuzztester 3y ago
>(no err != nil checks), How does that work in practice? Example please.
- amedvednikov 3y ago
  V uses Result types for handling errors, and the developer must handle them by propagating the error or breaking/returning or panicing. For example: // os.v fn open(path string) !File {} // main.v file := os.open('out.txt') or { panic('failed to open: $err') } file := os.open('out.txt') or { return } file := os.open('out.txt')! // propagate the error if file := os.open('out.txt') {} // alternative scoped syntax
  - deleted 3y ago
    [deleted]
  - fuzztester 3y ago
    Thanks. V syntax looks somewhat clear.
parabyl 3y ago
Spent a few months writing a pretty hefty Cqrs app in Go last year, had a fun but pretty unintuitive experience with rustlingss, and V really does seem like a cool in between! I look forward to taking it for a spin
microtonal 3y ago
Would be nice to add a short disclaimer that you are the author of the V language (at least it seems from your username, correct me if I'm wrong). There are many new languages in the same space (Zig, Nim, V). However, if you use a language outside hobby projects, you are dependent on a language having a long-term healthy ecosystem. Of the newer native languages, only Rust, Go, and Swift have enough traction to bet your livelihood on. In the end, having a rich ecosystem with good libraries and tools is going to leave a far bigger mark on productivity than relatively small differences between Rust, V, Zig, Nim, D, or whatever.

zarzavat 3y ago

Rust vs Go is like Jeep vs Prius. They both do the same kind of thing, but in such contrary ways that I don’t think anyone is confused which one they want.

anyfactor 3y ago

I don't get paid to write code in these languages; my enthusiasm in exploring them is limited by the amount of energy I have over the weekend. Honestly, I don't see Rust as anything but a code-rewrite language. I find Rust to be unintuitive, and I don't think it is a language designed to be a "problem solver. So, what do I mean by a problem solver? If you have a problem and you write code by exploring different solutions, continuously improve, and write hacky stuff where the goal is to simply solve a problem. Rust is not a problem solver; it is going to fight you all the way through because of its emphasis on programmatic correctness. With Rust, you have to have the solution first, consider the language-specific caveats, and write something in such a way that you don't go back and have to improve it. I suppose that is how programming is supposed to be done - in a clear and structured manner. But let's admit it, nobody does that. On the other hand, Go is a language that sits between Python and Rust. Python is THE problem solver language, and Rust is an elegant and good etiquette language. Go just works as a hackable language with the benefits of a compiled language and type support. My plan with Rust vs Go for the time being: - If I need to solve a problem and can do continuous improvement on the codebase → Go - If I have the problem solved, I have the resources to do a rewrite → Rust

peterfirefly 3y ago
My first (and so far only) Rust program was an 8088 disassembler. Rust made it easy for me to try "different solutions, continuously improve, and write hacky stuff". Perhaps it's more a question of background? Rust contains many features I already know from the ML family + it formalizes the way I've already been thinking about memory since the early 90's.
- brabel 3y ago
  Now try that on some domain you're not familiar with... If you ever have to change lifetimes of existing functions/structs on a non-trivial Rust code base, you're screwed.
  - baq 3y ago
    Observation: Lifetimes are Rust’s checked exceptions in that regard. Changes propagate in the wrong direction - from leafs of the import tree down to the root. Solutions though… can’t really imagine one that makes sense.

zozbot234 3y ago

Go is only memory safe for simple sequential code. Most concurrent Go programs share memory among threads/goroutines in an unsafe way.

kaba0 3y ago
That causes concurrency issues, but that is not what is commonly understood by memory safety. With that said, Go indeed gives you plenty of rope to hang yourself with in relation to concurrency (among others).
- skitter 3y ago
  Technically, there's memory unsafe memory sharing: Interfaces and slices are mutable and consist of multiple word that are accessed without synchronization, sharing a reference to a interface or slice between goroutines means you can get a mismatch between vtable ptr/data ptr or data ptr/length.
  - kaba0 3y ago
    That is again, language-dependent. Java for example can memory-safely have data races, even those that tear (what you are referring to here). Not the standard, but OpenJDK itself also has a guarantee that every value that any thread could observe was actually set by some other thread, so on incrementing a number from 0 from multiple threads you can never get -37, but for surely can observe an older value.
jedisct1 3y ago
On the other hand, goroutines makes it very easy to write concurrent code. And the built-in checker for race conditions works well. Async Rust, OTOH, can quickly become a horrible spaghetti mess that's virtually impossible to debug, and where common things such as cancellation are very challenging. My networks servers written in Rust are unsafe. I know they have dead locks, memory safety issues (due to usage or shared arrays and slabs to avoid allocations and work around the borrow checker), can be remotely DOS'd, leak memory (due to Rc, cycles or whatever), and have hacks to work around APIs that are not easy to use, just to make the borrow checker happy. Doing simple things such as listening to multiple IP addresses can require a major refactor. At the end of the day, after the excitement of having written a first version of these projects, I have a hard time understanding and fixing the remaining bugs, and eventually stop maintaining them. The ecosystem is also unstable. Dealing with major changes, or crates that need to be replaced because of deprecation/abandon makes applications unsafe. "crap, after cargo upgrade, that doesn't compile any more. Let's randomly fiddle around so that it compiles again". The version with the new crates doesn't get tested as much as the previous one. If they behave differently, or if to get the behavior of function X, now one should call function Y because X now does something else, the application is not as safe as when originally written. My network servers written in Go probably have plenty of bugs, but I can understand what's going on and fix them. I can dive into the code of the dependencies and of the standard library, follow and understand how things work under the hood. With Go's rich standard library, I also don't need to rely on a ton of dependencies, that will constantly be abandoned or introduce breaking API changes. So I can stay focused on the application logic, and eventually, the Go servers are way safer from a practical perspective. And for something that must be maintained on the long term, Go also wins hands down.

xyproto 3y ago

Pretty balanced article, but I think it skips over the (for me) main points of using Go: * Go was developed within Google, mainly as a response to C++ projects that had grown unwieldy, in terms of dependencies and compilation speed. As a result, the language is designed from scratch with compilation speed in mind, and unused dependencies are disallowed. * There are few changes to the language. When a new Go compiler is released, I go "nice, wonder which tooling and performance improvements are present" and not "oh no, how many repositories will need patches". Go code can be expected to compile 10+ years ahead. The same is not always the case for C, C++, Zig and possibly even Rust. * Deployment and crosscompilation is straightforward.

usrnm 3y ago
> The same is not always the case for C, C++ That's just completely not true, especially for C. There is a lot of C code older than most commenters on this site that's still used in production and compiled with modern compilers
- deleted 3y ago
  [deleted]
bestouff 3y ago
> and possibly even Rust. This is patently false. Rust has a severe backwards compatibility policy.
deaddodo 3y ago
> Go code can be expected to compile 10+ years ahead. The same is not always the case for C, C++, Zig and possibly even Rust. I'm sorry, but this comment just seems so blind to reality that it's hard not to comment on. C has a few particularly strong selling points: * Orthogonality to machine architectures * Freestanding (STD-free, in modern language parlance) compilation * An extremely conservative ruling body The latter is usually listed as a double-edged sword, since there are many new features people would like in C: true generics, polymorphic (overloaded) functions (without using the pre-processor), a true module system, etc; but it also means extremely old code compiles just fine on modern C compilers. Now, it might not work because it might be built for some bespoke hardware/environment, but the code will compile fine and be correct. For instance, here's a perfectly valid ANSI C application that will compile on any C compiler in the last 35 years (three times as long as Go has existed): https://godbolt.org/z/ja6WM5feT https://godbolt.org/z/ja6WM5feT Most of the features added in C11, C17 and C23 are additional features, usually with no backwards breaking changes. However, in some cases they do clarify undefined behavior; which can break old code. This is why most of the major modern compilers add flags to compile in specific dialects. Additionally, there are plenty of Go 1.0 (the first [and only] "10+" [11] year old version) codebases that won't compile without major changes.

Havoc 3y ago

I was agonizing over this choice too. Eventually rust won: * Feels closer to the good old Pascal days where you control everything * Safer bet should wasm & friends explode * Already have python for quick & dirt so picking something more extreme made sense. Go feels sorta in the middle * Its in kernel & loads of hype so unlikely to go away

ducktective 3y ago

>Which is better, Rust or Go? Go or Rust? Which language should you choose for your next project in 2023, and why? Meanwhile, I'm here considering Common Lisp :) Not being able to generate a statically compiled binary is an issue though...

fuzztester 3y ago
I've read that SBCL can. Some other Lisps may too.
- ducktective 3y ago
  > I've read that SBCL can. No, it would depend on host libc
  - fuzztester 3y ago
    Why? Something to do with static or dynamic linking? Anyway, I'm almost sure I've read multiple times on HN that SBCL can do it, in some threads about Lisp, including recent ones.
cookiengineer 3y ago
If you aren't nailed down on lisp but scheme would be an option for you, there's cyclone [1] which also has FFI and C ABI support iirc. [1] https://github.com/justinethier/cyclone https://github.com/justinethier/cyclone

bamazizi 3y ago

I've tried Rust for a short while to get a good feel. I've been Go developer for nearly a decade. Unfortunately there's a bit of a forced and misleading Rust favoritism the days but from my experience in various startups, including my current one, Go is by far the best choice for backend development! - Rust is not suitable for fast paste startup environment - Rust is not suitable if the initial team members are not Rust experts - Rust is not suitable if the startup doesn't have money (Rust devs are very expensive and scarce) - Rust is not general hire friendly - Rust is not ideal for iterative and high refactor potential of startup culture - Rust is painful/heartbreaking when eventuality of a pivot approaches - Rust is not an advantage in anything startup related Go is the exact opposite of above points! Note: I didn't talk about performance, feature or whatever else ... both languages are very very close to each other!

toasted-subs 3y ago
I’d hire a Python developer any day of the week over either Go/Rust. Need some data science work done, easy. Need a web server done, easy. Need things to be fast and relatively performant done, easy.
- smolder 3y ago
  > Python > fast This is only true if you are relying mainly on compiled extensions to do the performance-critical work. Unassisted raw python is super slow compared to Go or Rust.
  - memefrog 3y ago
    So what? That's how things are structured in Python. It's one of the advantages of the language. Sure it'd be nice to be like Common Lisp, where you can write dynamic/slow and optimised/fast code in the same language, depending on (declare). But Python is the next best thing. If you want to write slow, dynamic, hacky code in Rust you have to write 'unwrap' and 'clone' all over the place, obscuring the logic.
    - 3y ago

kaba0 3y ago

Rust and Go have almost no relation to each other - one is a low-level language, like C, C++, the other is a high-level one like Java, C#, Haskell. These articles and this general notion that the two has some relevance to each other is just plain wrong and harmful.

impulser_ 3y ago
There are definitely relations between them. They are often used in the same domains. Servers, DevOps, CLI, tooling ect. Just because one has manual memory management and other is GC doesn't mean they aren't relatable.
- kaba0 3y ago
  Python is also used in those niches, let’s add that also to the list.
- orwin 3y ago
  The only 'natural' niche for Rust in your list is CLI. Which, by the way, I wouldn't really use go for unless it's a CLI for a daemon/remote program. I guess Rust can be used for the rest but imho you won't use rust's advantages. One of my favorites being memory manipulation. Rust truly shine for low-level programming imho, but more power to you if you're using it as your generalist language.
  - ssokolow 3y ago
    I think they're all natural niches, because Rust's performance and ability to tightly control memory allocation are over-promoted and the strength of the type system as a means of ensuring correctness at compile time is underpromoted. Especially web use is one of the biggest places you want to be able to rely on the compiler, aided by patterns like the newtype pattern and the typestate patterns, to catch as many potential DoS or security bugs as possible. I use Rust as "Haskell, but without having to put up with writing Haskell". (Or, more commonly, I say that Rust is the sweet spot where you've taken pretty much everything functional programming has to offer before you start falling off a return-on-investment cliff.)

kif 3y ago

What is the recommended resource that helps one become proficient at Rust nowadays?

speedgoose 3y ago
I would recommend ChatGPT. It’s pretty good at pretending to understand your struggles with rust. You can explain your issues and swear a lot and you will get a nice explanation in return.
- jedisct1 3y ago
  Joke apart, yes. ChatGPT can sometimes be more useful than rustc error messages. However, the code you need it to explain have to be small and self-contained. When it's part of an actual project, preparing a proper prompt requires a bit of work.
- mariusor 3y ago
  > and you will get a nice explanation in return Which might or might not be correct.
  - speedgoose 3y ago
    Like everything your read yes.
    - mariusor 3y ago
      No, not like everything you read at all.
peterfirefly 3y ago
What has worked for me so far: https://doc.rust-lang.org/book/ https://doc.rust-lang.org/book/ (do the exercises!) plus a little bit of: https://doc.rust-lang.org/cargo/ https://doc.rust-lang.org/cargo/ and https://doc.rust-lang.org/std/index.html https://doc.rust-lang.org/std/index.html (There's no need to remember the last URL -- just google "rust xxx" and you will get the right page.) I'm looking forward to reading this: https://nnethercote.github.io/perf-book/introduction.html https://nnethercote.github.io/perf-book/introduction.html Sprinkle some blog posts on top: https://xxchan.me/cs/2023/02/17/optimize-rust-comptime-en.html https://xxchan.me/cs/2023/02/17/optimize-rust-comptime-en.ht... https://matklad.github.io/2021/05/31/how-to-test.html https://matklad.github.io/2021/05/31/how-to-test.html https://matklad.github.io/2021/08/22/large-rust-workspaces.html https://matklad.github.io/2021/08/22/large-rust-workspaces.h... https://fasterthanli.me/articles/a-half-hour-to-learn-rust https://fasterthanli.me/articles/a-half-hour-to-learn-rust https://fasterthanli.me/articles/working-with-strings-in-rust https://fasterthanli.me/articles/working-with-strings-in-rus... ... and the rest is just a matter of applying enough sweat :)

satvikpendem 3y ago

Whenever I see comparisons between Rust and Go, I'm always reminded of fasterthanlime's I want off Mr Golang's wild ride [0] as well as its sequel Lies we tell ourselves to keep using Golang [1]. Having used both, Go hides its complexity behind the veneer of simplicity while being more tedious and error prone as the codebase grows while Rust brings the complexity to you upfront while preventing errors later. Personally, even simply due to language features like algebraic data types in other languages, I really have no reason to use Go anymore. There's an oft-said quip that says that the Go language designers took the last 50 years of programming language theory and simply...threw it away. Plus, to those saying it's easier to hack stuff together in other languages than Rust, I simply clone everywhere and Rust then becomes the same as a garbage collected language. You don't have to deal with lifetimes and excessive cloning from the get go, deal with that after experimenting then optimize, same as you would for any other language. The plethora of language features in Rust make it easier to hack around in, in actuality. [0] https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... [1] https://fasterthanli.me/articles/lies-we-tell-ourselves-to-keep-using-golang https://fasterthanli.me/articles/lies-we-tell-ourselves-to-k...

thumbuddy 3y ago
Infact... Early stages of a project should make heavy use of owned and cloned types while you figure out the bottlenecks and work out how to architect the solution.

pjmlp 3y ago

Most of my complaints against Go are kind of waned, however can we at very least have Pascal like enumerations without iota const dance?

fuzztester 3y ago
I don't like that iota stuff either.

colonwqbang 3y ago

Interesting that he selected "match" as example of a complex Rust feature. To me, "match"/"case" is one of the simplest and cleanest abstractions in programming languages.

glandium 3y ago
Honestly, I've found match more annoying (and I suspect it's more confusing for newcomers), ever since match ergonomics were stabilized. I do see how it helps some simple cases, but it makes things awfully confusing in so many other cases...
- thumbuddy 3y ago
  That's wild. First time I saw a match case, if let, and matches! Invocation I was freaking relieved. No by hand type checking in a dynamic language, having to consider corner cases, etc. LSP even autocompletes the cases with a single hotkey. Escape from boilerplate hell.
ssokolow 3y ago
*nod* Aside from the obvious (compile-time guarantees beyond MyPy's ability to offer), the lack of pattern matching and an accompanying ecosystem that evolved in its presence is my number one discomfort when writing Python for things like my QWidget GUI frontends for Rust backends.

benrutter 3y ago

I think this article is a nice summary of the languages, but the opening set up bugs me: > Which is better, Rust or Go? Go or Rust? Which language should you choose for your next project in 2023, and why? I blame the "rewrite everything in Rust" crowd, but there seems to be a resurgence lately of the idea that there is One True Programming Language you should use for everything. I don't particularly fancy using an OS written in Go, and I don't want to work on web architecture projects in Rust. Similarly, I don't want to work with someone who is going to write shell scripts or basic utility tasks in Rust because the performance is faster.

ssokolow 3y ago
Odd. I wish Rust had Django's ecosystem so I could do more Rust web stuff, and I do use Rust for "shell scripts" and basic utility tasks, not for the performance, but for the compile-time guarantees. I'd much rather pay a little extra up-front in resolving compiler errors, so I can know I'm not going to wake up to something like a six-hour batch job that failed 5% through or slam face-first into needing to debug an exception when I'm already in a rush and stressed over it. Likewise, I find Rust's syntax much more pleasant than Go's... probably because I can see that Rust's syntactic complexity means things that have value to me, while Go's is just repetitive boilerplate to make my time a sacrifice on the altar of dogmatic language simplicity.

revskill 3y ago

The fact that, in the official Rust Book, the author even don't know how to write Higher order function in Chapter 1 said something about Rust. Just write down how to do good functional programming with currying, HOC right in chapter 1 and all is good. Don't treat reader as "zero-knowledge beginner".

peterfirefly 3y ago
Why would you want currying? It is one of least useful/most dumb features of old-skool applicative languages. It is often combined with a really dumb "no parentheses" attitude to arguments. If you really need something akin to currying (which you rarely do), why not use a closure as a wrapper? // x and y are captured from the environment | a | func_that_takes_3_args(x, y, a)

truth_seeker 3y ago

The difference/tradeoff shown in the blog fades away in developers psychology as they write more code and ship apps, so I would not held them high. In my experience, compared to Golang, the only (mild) downside of Rust is not so big STD lib, compilation time and initial learning curve. Frankly speaking its neither a blocker nor a big deal. Once learning phase of Rust is passed, you have one language which you can use anywhere and can trust to produce efficient code both from readability and performance point of view.

msie 3y ago

After reading many comments here the one that appeals to me is the readability of go code. There was this moment of ruby vs python where I was delighted by the readability of python code and how I could easily read the code of python libs as well. I feel this is the same with go. I can imagine the rust wizards easily making hard to read code.

luuio 3y ago

At least two reasons I'm not choosing Go: - Go (the language) is missing the ability to declare something immutable. I don't mean making fields in a struct private then exposing getters. I mean the equivalent of an immutable reference in Rust or `const ref` in C++. - Go mod and go workspace still can't get a cohesive story together [1]: - - If my module wants to depend on another module in a workspace, `go mod tidy` would freak out. - - If I use replace in my go mod file to point to the other modules in the same workspace, `go mod vendor` will copy these workspace modules to the vendor folder as well. [1] https://github.com/golang/go/issues/50750 https://github.com/golang/go/issues/50750

leighmcculloch 3y ago

The article doesn't discuss one of the most significant differences between building in Go and Rust: tooling.