3 ms·

To me, in the old Go vs Rust debate, there are two things that are abundantly clear in making a compelling case for Go. First, I don't think even the most devo

To me, in the old Go vs Rust debate, there are two things that are abundantly clear in making a compelling case for Go. First, I don't think even the most devoted rustacean can deny that Rust has a hell of a learning curve. But perhaps most importantly is that Go has a strong and extensive standard library that covers many 21st century applications (e.g. talking to REST APIs). The problem to me with the Rust "no stdlib" model is it leaves you with two equally unattractive options: 1) Write the library yourself (and leave yourself with the associated technical debt of maintaining it) 2) Figure out which of the often dozens of third-party Rust crates you want to use (and rinse and repeat the selection process for every library, and then expose yourself to third-party maintenance debt).

usrusr 4y ago
The most interesting thing about the go vs rust debate is that it happened. In hindsight it seems abundantly clear that they aim for entirely different fields with negligible overlap, almost as if you'd lump together tennis and golf because they are both ball games with a somewhat upperclass bias ("how different can they be? And I hear polo is the same but with horses!"). But back then? Yeah, I was kind of expecting one of them to "win".
- kjksf 4y ago
  Rust and Go are both general purpose languages. They overlap way more than they don't i.e. there is way more software that you can write in both languages than software that you can write in only one of them. The "best language for the job" is mostly a myth. The choice of language is mostly dictated by what you cannot do, rather than what you can do. Can I use Go or Java to program a micro-controller with 128 kB of RAM? Not really (at least no using the official, non-crippled implementation) because even "hello world" in those languages exceeds that 128 kB limit. If I'm writing a cmd-line app that I want to ship as a single binary for Windows and Mac and Linux, I'm not using Python. Technically it's possible but very few are doing it while Go gives me out of the box multi-platform compilation. The reality is that the majority of software written today falls into one of those categories: * web frontend, running in the browser, by necessity written in JavaScript or something that transpiles to JavaScript. Both Go and Rust are out of this game * web backend and similar server software: both Rust and Go compete for that * command line apps : both Rust and Go compete for that * games : AAA games are pretty much C++, Go and Rust are out (although Rust could, in principle, work) So in most cases both Rust and Go are unsuitable for the task or they compete for the task.
  - devrimbaris 4y ago
    There you have TinyGO for embedded and wasm stuff, but it is not the same as using the same language and tooling everywhere like Rust. I like Go and a fan of Rust but for Rust,some standard libraries lagging like async and having alternatives to choose from makes me uneasy about Rust in general (tokia vs async libs e.g).i am just a beginner in Rust so i might be wrong. The game engines in Rust are way cool btw.
  - jfim 4y ago
    > Can I use Go or Java to program a micro-controller with 128 kB of RAM? Not really (at least no using the official, non-crippled implementation) because even "hello world" in those languages exceeds that 128 kB limit. You'd be surprised actually. Java Card is actually designed for memory constrained environments. It's not as featured as Java itself but it uses the same language syntax and class file format.
dividedbyzero 4y ago
This hasn't been a big issue for me with Rust. You do have to spend a bit of time looking around initially, but there are lots of good-quality libraries that aren't going away anytime soon, you make your pick and move on and after doing that a few times you pretty much have a standard library of sorts. For me personally, that wouldn't be a reason to pick Go over Rust. What's moving the scales in favor of Go, for me, is Rust's borrow checker. I'm aware that it has a bunch of advantages over a garbage collector, but those are paid for with a pretty noticable productivity hit that doesn't seem to go entirely away with experience either; experienced Rustaceans I've consulted with less-common patterns still spent a lot of energy finding a way to make them work with the borrow checker and still sufficiently efficient, and most of that could have been saved for more productive work in a language more open to existing design patterns. Usually I'm neither out for the maximum safety at all costs nor resource-constrained, so I'd rather take Go-ish levels of safety and Go-ish performance and get work done faster. If there was a Rust with a first-class garbage collector, but keeping all the neat functional elements, the neat semantics, the great libraries and ecosystem, strong types, single binary etc. pp., I'd pick that right away. Go is "easy" at the cost of expressiveness to a degree that makes for reams upon reams of repetitive code or code generation, and Rust-ish functional patterns could greatly condense that and make much more readable, at the expense of having a somewhat higher learning curve. That's a trade-off that I'd much prefer, reading and reviewing Go codebases can be very tedious.
jen20 4y ago
Unfortunately the lack of investment in the standard library for important things like structured logging have meant that there is still a bifurcated ecosystem around things like “what logger does this use?” (rather than “what async runtime is this for?” in Rust). Unfortunately major projects pull on tens of random libraries from the internet which represent real supply chain risk.
pcwalton 4y ago
There are curated lists of Rust crates to help with the second issue: https://github.com/rust-unofficial/awesome-rust https://github.com/rust-unofficial/awesome-rust And those two options don't strike me as equally unattractive. Writing everything that isn't in the standard library from scratch is completely impractical for modern apps. Nobody does that in Rust. Integrating crates from the ecosystem into your workflow is just part of developing in the language.
- pclmulqdq 4y ago
  So put them in the standard library or have an organization that guarantees support for the next 10 years. The Rust community doesn't really understand why languages with a standard library have one. It isn't about performance or ease of use, it's about making guarantees about technical debt.
slaymaker1907 4y ago
The API case for Go is absurd IMO because what libraries are there in Go that are simultaneously not widely available in other languages and also difficult to implement on your own? People complain about Racket's ecosystem, but it has many libraries that would be PhD level effort to implement and are unique in its ecosystem such as Rosette and Redex. If some random REST API doesn't have bindings yet, implementing those myself isn't all that difficult.
- jfim 4y ago
  Both of those libraries look cool, but I'm guessing that most of the users of Go would not need them. I definitely agree that I'd rather have to write API glue code than a constraint based solver for a project that has time constraints though.

usrusr 4y ago

The most interesting thing about the go vs rust debate is that it happened. In hindsight it seems abundantly clear that they aim for entirely different fields with negligible overlap, almost as if you'd lump together tennis and golf because they are both ball games with a somewhat upperclass bias ("how different can they be? And I hear polo is the same but with horses!"). But back then? Yeah, I was kind of expecting one of them to "win".

kjksf 4y ago
Rust and Go are both general purpose languages. They overlap way more than they don't i.e. there is way more software that you can write in both languages than software that you can write in only one of them. The "best language for the job" is mostly a myth. The choice of language is mostly dictated by what you cannot do, rather than what you can do. Can I use Go or Java to program a micro-controller with 128 kB of RAM? Not really (at least no using the official, non-crippled implementation) because even "hello world" in those languages exceeds that 128 kB limit. If I'm writing a cmd-line app that I want to ship as a single binary for Windows and Mac and Linux, I'm not using Python. Technically it's possible but very few are doing it while Go gives me out of the box multi-platform compilation. The reality is that the majority of software written today falls into one of those categories: * web frontend, running in the browser, by necessity written in JavaScript or something that transpiles to JavaScript. Both Go and Rust are out of this game * web backend and similar server software: both Rust and Go compete for that * command line apps : both Rust and Go compete for that * games : AAA games are pretty much C++, Go and Rust are out (although Rust could, in principle, work) So in most cases both Rust and Go are unsuitable for the task or they compete for the task.
- devrimbaris 4y ago
  There you have TinyGO for embedded and wasm stuff, but it is not the same as using the same language and tooling everywhere like Rust. I like Go and a fan of Rust but for Rust,some standard libraries lagging like async and having alternatives to choose from makes me uneasy about Rust in general (tokia vs async libs e.g).i am just a beginner in Rust so i might be wrong. The game engines in Rust are way cool btw.
- jfim 4y ago
  > Can I use Go or Java to program a micro-controller with 128 kB of RAM? Not really (at least no using the official, non-crippled implementation) because even "hello world" in those languages exceeds that 128 kB limit. You'd be surprised actually. Java Card is actually designed for memory constrained environments. It's not as featured as Java itself but it uses the same language syntax and class file format.

dividedbyzero 4y ago

This hasn't been a big issue for me with Rust. You do have to spend a bit of time looking around initially, but there are lots of good-quality libraries that aren't going away anytime soon, you make your pick and move on and after doing that a few times you pretty much have a standard library of sorts. For me personally, that wouldn't be a reason to pick Go over Rust. What's moving the scales in favor of Go, for me, is Rust's borrow checker. I'm aware that it has a bunch of advantages over a garbage collector, but those are paid for with a pretty noticable productivity hit that doesn't seem to go entirely away with experience either; experienced Rustaceans I've consulted with less-common patterns still spent a lot of energy finding a way to make them work with the borrow checker and still sufficiently efficient, and most of that could have been saved for more productive work in a language more open to existing design patterns. Usually I'm neither out for the maximum safety at all costs nor resource-constrained, so I'd rather take Go-ish levels of safety and Go-ish performance and get work done faster. If there was a Rust with a first-class garbage collector, but keeping all the neat functional elements, the neat semantics, the great libraries and ecosystem, strong types, single binary etc. pp., I'd pick that right away. Go is "easy" at the cost of expressiveness to a degree that makes for reams upon reams of repetitive code or code generation, and Rust-ish functional patterns could greatly condense that and make much more readable, at the expense of having a somewhat higher learning curve. That's a trade-off that I'd much prefer, reading and reviewing Go codebases can be very tedious.

jen20 4y ago

Unfortunately the lack of investment in the standard library for important things like structured logging have meant that there is still a bifurcated ecosystem around things like “what logger does this use?” (rather than “what async runtime is this for?” in Rust). Unfortunately major projects pull on tens of random libraries from the internet which represent real supply chain risk.

pcwalton 4y ago

There are curated lists of Rust crates to help with the second issue: https://github.com/rust-unofficial/awesome-rust https://github.com/rust-unofficial/awesome-rust And those two options don't strike me as equally unattractive. Writing everything that isn't in the standard library from scratch is completely impractical for modern apps. Nobody does that in Rust. Integrating crates from the ecosystem into your workflow is just part of developing in the language.

pclmulqdq 4y ago
So put them in the standard library or have an organization that guarantees support for the next 10 years. The Rust community doesn't really understand why languages with a standard library have one. It isn't about performance or ease of use, it's about making guarantees about technical debt.

slaymaker1907 4y ago

The API case for Go is absurd IMO because what libraries are there in Go that are simultaneously not widely available in other languages and also difficult to implement on your own? People complain about Racket's ecosystem, but it has many libraries that would be PhD level effort to implement and are unique in its ecosystem such as Rosette and Redex. If some random REST API doesn't have bindings yet, implementing those myself isn't all that difficult.

jfim 4y ago
Both of those libraries look cool, but I'm guessing that most of the users of Go would not need them. I definitely agree that I'd rather have to write API glue code than a constraint based solver for a project that has time constraints though.