6 ms·

Go is in a sweet spot where it is often used to compete with both groups: [Rust, C/C++] and [Node, Python, Ruby, etc]. The reason GP said it is probably because

by throw14082020 4y ago

Go is in a sweet spot where it is often used to compete with both groups: [Rust, C/C++] and [Node, Python, Ruby, etc]. The reason GP said it is probably because of Garbage collection. I've done a bit of Rust in my job, and there are some basic things that Rust doesn't have going for it: - steep learning curve (this means for the first 6 months, you or your colleagues are unproductive, write bad Rust which your company then builds upon over time). - bad error messages (even though that was a focus for the rust team!) - frustratingly complex for setting up test coverage - Slow analyzer speed (*super laggy* on Clion, though this might be a jetbrains issue) - Slow compilation times (I heard somewhere that "Go just goes". I've also written some Go in my free time, and compilation is fast. Well IMHO, "rust will rust" - it's very slow. Generics can make compilation event slower.) - Verbose. I've seen a just few lines of JS get replaced with hundreds and thousands of Rust.

alfalfasprout 4y ago
Unfortunately, I'm inclined to agree. Rust lives in this interesting spot where, on paper, it should be superior to anything... but in practice, it's not a good choice in most cases. It's very easy to ramp up someone in Go that's had a standard CS education and written C/C++ before. It's also simple enough syntax-wise for someone who knows python well enough to understand references, etc. Its stylistic restrictions and not being OOP-first also mean that codebases are generally readable. Compilation is also extremely straight forward. With Rust, I've found even very experienced C++ folks have a long ramp-up period, the development toolchain is slow, and the ecosystem is limited. Sure, for example there are projects to enable Rust usage with CUDA. But few are inclined to actually bother implementing a new BLAS and GPU accelerated tensor library with Rust. I do think 10 years from now Rust will start getting more adoption as the ecosystem and tooling improve. But it's hard to argue with Go where you'll typically get results that are faster or at worst comparable to Java without the OOP design pattern gobbledygook, simple concurrency model, and simple build process. It's "good enough" for 99% of use cases.
- zozbot234 4y ago
  Go has bad interop with C/C++ and languages that use the C/C++ ABI (including Rust). You can use cgo as a workaround but it's clunky. So that makes an interesting case for other high level, novice-friendly languages like Nim, Crystal or Val/Vale/Vala.
- ModernMech 4y ago
  > With Rust, I've found even very experienced C++ folks have a long ramp-up period I've found C++ folks especially have the hardest time with Rust, because they approach it using C++ idioms and habits, then get frustrated when they can't do things the way they're used to. I've had better success teaching Java people Rust. They find it much easier to learn than C++, and I can get them writing idiomatic Rust code quickly, while C++ devs are still trying to get their coding habits past the borrow checker.
  - worik 4y ago
    I think everybody has a hard time starting with Rust. Even when you get confident it is still a longer process writing code than C/C++. It makes you think very hard about what you do carelessly in C. But having spent the last few years debugging a lot of Swift code, and a bit of Rust code, that time is worth it I say. Where Rust shines is in the debug cycle. Less of it. Once you learn to surrender to the compiler, you will find true bliss,....
estebank 4y ago
> - bad error messages (even though that was a focus for the rust team!) I would love to hear more! (If you have the time.)
- pdimitar 4y ago
  Not the fault of Rust compiler per se but in my case the errors that mismatching trait impls from async libraries yield can be downright suicide-inducing. I recognize this is not entirely on rustc though.
  - estebank 4y ago
    Having examples of these is useful to see what we could get rustc to do. The general case might be impossible to deal with in a generic way, but we can target specific patterns libraries use and emit custom errors for them. The problem with these is we have to be reactive: if we don't see a problematic patter ourselves (or it isn't reported to us), we can't do anything about them.
    - pdimitar 4y ago
      Unfortunately last I tried these code snippets was months ago, was rushing like mad because it was a startup and I couldn't afford to just stop and write everything down and... yeah, priceless info was lost. Just recently I am making a comeback to rewriting a tokio 0.1 library to the latest version so I'll likely have a few examples that I can post... where? In GitHub issues?
      - estebank 4y ago
        GitHub works great for it, for diagnostic tickets in particular you can file them at https://github.com/rust-lang/rust/issues/new?assignees=&labels=A-diagnostics%2CT-compiler&template=diagnostics.yaml https://github.com/rust-lang/rust/issues/new?assignees=&labe... Even if it is an "it hurts when I do this" without more context it can be useful to bring the problem to our attention (but the more context you provide the higher the change we'll fix the problem).
dcow 4y ago
> - Verbose. I've seen a just few lines of JS get replaced with hundreds and thousands of Rust. Please, more detail (=
- afavour 4y ago
  JS: new HTMLDivElement() Rust: struct WebBrowser { ...
  - steveklabnik 4y ago
    Instantiating an object vs defining one? Yeah definition would be longer.
- throw14082020 4y ago
  I should've been clearer, sorry. The verbosity and complexity of `wasm_bindgen`/serialization between JS and Wasm (written in Rust) is primarily the thing I am frustrated at here when I see hundreds and thousands of Rust code. A concrete example: creating a Websocket client in Javascript/Typescript vs in Rust/Wasm. In general though (outside of Wasm), Rust is less readable. And with regards to Rust errors, I've found Rust errors related to Tonic and Diesel to be quite annoying/unreadable. The Diesel docs seem to blame Rust for this (can't find the docs for it right now).
  - justinclift 4y ago
    Isn't this due to wasm having to access browser things mostly through browser JS interfaces? eg Browsers provide JS functions that are intended for JS, which are not directly exposed to Wasm. So when your Wasm wants to access DOM things, access DOM functions, (etc) it needs to go through a JS shim layer instead of being able to call them directly. If the browser dev's (or some W3C type of body?) introduced those same functions, but had them be directly accessible from wasm, then the JS shims wouldn't be needed. The JS dev's for each of the browsers though would probably try and stop it ("security risk!" excuses, etc) though, as that would potentially cut into "their territory" and allow other languages to compete. :(
justinpombrio 4y ago
> - Verbose. I've seen a just few lines of JS get replaced with hundreds and thousands of Rust. I'm curious to see those few lines of JS!

alfalfasprout 4y ago

Unfortunately, I'm inclined to agree. Rust lives in this interesting spot where, on paper, it should be superior to anything... but in practice, it's not a good choice in most cases. It's very easy to ramp up someone in Go that's had a standard CS education and written C/C++ before. It's also simple enough syntax-wise for someone who knows python well enough to understand references, etc. Its stylistic restrictions and not being OOP-first also mean that codebases are generally readable. Compilation is also extremely straight forward. With Rust, I've found even very experienced C++ folks have a long ramp-up period, the development toolchain is slow, and the ecosystem is limited. Sure, for example there are projects to enable Rust usage with CUDA. But few are inclined to actually bother implementing a new BLAS and GPU accelerated tensor library with Rust. I do think 10 years from now Rust will start getting more adoption as the ecosystem and tooling improve. But it's hard to argue with Go where you'll typically get results that are faster or at worst comparable to Java without the OOP design pattern gobbledygook, simple concurrency model, and simple build process. It's "good enough" for 99% of use cases.

zozbot234 4y ago
Go has bad interop with C/C++ and languages that use the C/C++ ABI (including Rust). You can use cgo as a workaround but it's clunky. So that makes an interesting case for other high level, novice-friendly languages like Nim, Crystal or Val/Vale/Vala.
ModernMech 4y ago
> With Rust, I've found even very experienced C++ folks have a long ramp-up period I've found C++ folks especially have the hardest time with Rust, because they approach it using C++ idioms and habits, then get frustrated when they can't do things the way they're used to. I've had better success teaching Java people Rust. They find it much easier to learn than C++, and I can get them writing idiomatic Rust code quickly, while C++ devs are still trying to get their coding habits past the borrow checker.
- worik 4y ago
  I think everybody has a hard time starting with Rust. Even when you get confident it is still a longer process writing code than C/C++. It makes you think very hard about what you do carelessly in C. But having spent the last few years debugging a lot of Swift code, and a bit of Rust code, that time is worth it I say. Where Rust shines is in the debug cycle. Less of it. Once you learn to surrender to the compiler, you will find true bliss,....

estebank 4y ago

> - bad error messages (even though that was a focus for the rust team!) I would love to hear more! (If you have the time.)

pdimitar 4y ago
Not the fault of Rust compiler per se but in my case the errors that mismatching trait impls from async libraries yield can be downright suicide-inducing. I recognize this is not entirely on rustc though.
- estebank 4y ago
  Having examples of these is useful to see what we could get rustc to do. The general case might be impossible to deal with in a generic way, but we can target specific patterns libraries use and emit custom errors for them. The problem with these is we have to be reactive: if we don't see a problematic patter ourselves (or it isn't reported to us), we can't do anything about them.
  - pdimitar 4y ago
    Unfortunately last I tried these code snippets was months ago, was rushing like mad because it was a startup and I couldn't afford to just stop and write everything down and... yeah, priceless info was lost. Just recently I am making a comeback to rewriting a tokio 0.1 library to the latest version so I'll likely have a few examples that I can post... where? In GitHub issues?
    - estebank 4y ago
      GitHub works great for it, for diagnostic tickets in particular you can file them at https://github.com/rust-lang/rust/issues/new?assignees=&labels=A-diagnostics%2CT-compiler&template=diagnostics.yaml https://github.com/rust-lang/rust/issues/new?assignees=&labe... Even if it is an "it hurts when I do this" without more context it can be useful to bring the problem to our attention (but the more context you provide the higher the change we'll fix the problem).

dcow 4y ago

> - Verbose. I've seen a just few lines of JS get replaced with hundreds and thousands of Rust. Please, more detail (=

afavour 4y ago
JS: new HTMLDivElement() Rust: struct WebBrowser { ...
- steveklabnik 4y ago
  Instantiating an object vs defining one? Yeah definition would be longer.
throw14082020 4y ago
I should've been clearer, sorry. The verbosity and complexity of `wasm_bindgen`/serialization between JS and Wasm (written in Rust) is primarily the thing I am frustrated at here when I see hundreds and thousands of Rust code. A concrete example: creating a Websocket client in Javascript/Typescript vs in Rust/Wasm. In general though (outside of Wasm), Rust is less readable. And with regards to Rust errors, I've found Rust errors related to Tonic and Diesel to be quite annoying/unreadable. The Diesel docs seem to blame Rust for this (can't find the docs for it right now).
- justinclift 4y ago
  Isn't this due to wasm having to access browser things mostly through browser JS interfaces? eg Browsers provide JS functions that are intended for JS, which are not directly exposed to Wasm. So when your Wasm wants to access DOM things, access DOM functions, (etc) it needs to go through a JS shim layer instead of being able to call them directly. If the browser dev's (or some W3C type of body?) introduced those same functions, but had them be directly accessible from wasm, then the JS shims wouldn't be needed. The JS dev's for each of the browsers though would probably try and stop it ("security risk!" excuses, etc) though, as that would potentially cut into "their territory" and allow other languages to compete. :(

justinpombrio 4y ago

> - Verbose. I've seen a just few lines of JS get replaced with hundreds and thousands of Rust. I'm curious to see those few lines of JS!