4 ms·

I'm puzzled by one of the conclusions: Go is better "if you target exceptionally/mostly Linux". But Rust is better "If the project targets many operating system

by SiVal 6y ago

I'm puzzled by one of the conclusions: Go is better "if you target exceptionally/mostly Linux". But Rust is better "If the project targets many operating systems and I want a truly multiplatform codebase". I have no idea what this is referring to. The first time the article mentions this (whatever this is) seems to be in the conclusions. Find the word "platform" in the article, and there is one match: in the conclusion. I write Go on Mac or Win, deploy on Mac, Win, or Linux. One code base, one command-line option to tell the compiler which platform to target. A 2-second compile for local platform, test, it works, another 2-sec compile of same code with a different command-line option and I have a native executable for some other target platform. I don't know what more Go would need for the "truly multiplatform codebase" that Rust purportedly allows, but I haven't used Rust. If I had to guess (again, the article doesn't seem to say), I'd guess that maybe if I were targeting something tiny, like a chip in a microwave oven or maybe WASM, Rust would be better, because you can customize the memory handling. I would certainly (learn and) use Rust over Go for such specialized cases, but then those are "specialized" cases, not general multiplatform cases. I wouldn't deploy the same code to a microwave oven and Windows. So, I don't know. Any ideas?

carlosperate 6y ago
I had exactly the same question, although I haven't tried either language yet. It'd be great if somebody could shed some light on this, as I would find it really interesting.
TheNorthman 6y ago
He does link to an article [0] that mostly talks about multi-platform Go and uses Rust as a language that doesn't have these problems, to the same degree at least. The gist of the article is that, while Go might very well compile easily on multiple platforms, it does so not by solving the complexities inherent with this problem but rather by merely hiding them from the user. There are plenty of examples in the article so I won't elaborate on that part but his examples mostly revolve around $(platform)-specific features being poorly poly-filled on non-$(platform) platforms. [0]: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...
- est31 6y ago
  I skimmed over that article and most of the criticism is about OS API wrappers. The thing that enables Go's single command cross compilation is thanks to other components of the pipeline being implemented in Go, like the linker, or not needing Windows import libraries (there is a merged RFC for Rust called raw dylibs to solve this, but implementation has stagnated... go has this feature already). In the long term, Rust may end up in a better place than Go regarding portability but of course as long as GCC can target more than clang and there is no Rust gcc backend while there is a Go backend, Rust can't be better than Go in all portability aspects.
  - deleted 6y ago
    [deleted]
- SiVal 6y ago
  I just read that article, and I'll bet you're right that it represents the (unstated) thinking behind that conclusion. But if so, my conclusion would be different from the author's. The big picture is that Go programming is intended to be more automated while Rust programming is intended to be more customized (relative to each other). When the automation does what you need, it's more convenient, so it's more useful. When it doesn't, because of some issue or other, Rust's ability to customize is more useful. Go can be customized, too, but it's usually the case that something intended to be automated is harder to customize than something intended to be customized like Rust. So my conclusion (for just this 2-language comparison) would be, Use Go when its built-in features do what you need. It's easier to build with in that case. Use Rust when you need more optimization of something than you can get out of the box from Go. It's easier to optimize.
jedisct1 6y ago
My experience is completely the opposite. Go is excellent for cross-compilation. The same compiler can compile to a lot of platforms out of the box, and making portable applications requires very little to no platform-specific code. Go's standard library exposes a consistent API across all platforms, and external dependencies also do a really good job at this. Rust, on the other hand, requires installation of subsystems, and only few of them are properly supported ("Tier 1"). Even a common target such as linux/arm is constantly broken. Dependencies, including popular ones such as libc, are incomplete and not really tested on systems that are not linux/windows/macos. Even on these 3 platforms, writing portable code requires a platform-specific code.
- steveklabnik 6y ago
  Please file bugs for linux/arm! ARM themselves are in the middle of getting it promoted to Tier 1.
- pjmlp 6y ago
  > Dependencies, including popular ones such as libc, are incomplete and not really tested on systems that are not linux/windows/macos. That is a consequence of a thin standard library, no guaranteed support on all platforms that the compiler targets.
k4ch0w 6y ago
Yeah this one seems weird. I would think it's actually the inverse. I used to code a lot in Go two years ago, so I can't speak to it much today. Lately, I'm all Rust. If you're on Linux, it's so easy going to get it all working right. Windows is a pain, so much so you end up installing WSL2 and just moving on with your day. A good follow up to this post would be OpenSSL compilation on Golang vs. Rust on each platform. It's a fair test as it's widely used library with both programming languages and all the operating systems.
- steveklabnik 6y ago
  I am interested in what pain you had beside OpenSSL; I've been exclusively a Windows user for the past few years, and other than it and Postgres, I've had no desire to install WSL.
  - saturn_vk 6y ago
    Three years ago I began working in a new company and was initially on Windows, and was extremely open minded about it. Though, perhaps because I structured my "workspace" as I would under linux, where I put the code in some directory under my home one, things began to break rather quickly. The most common and annoying error was maven builds breaking because the path of the files being compiled was too long. After a bit of struggling I decided to go back to linux, it just wasn't worth the hassle.
    - steveklabnik 6y ago
      Ah, I should have clarified: for Rust development. I can't (well, I guess I mean "won't") fix bugs in Maven :)
    - vips7L 6y ago
      I've never experienced this with maven and I've been using it for close to 10 years on windows. This is also putting all of my code under my home directory.
      - 6y ago

by SiVal 6y ago

carlosperate 6y ago

I had exactly the same question, although I haven't tried either language yet. It'd be great if somebody could shed some light on this, as I would find it really interesting.

TheNorthman 6y ago

He does link to an article [0] that mostly talks about multi-platform Go and uses Rust as a language that doesn't have these problems, to the same degree at least. The gist of the article is that, while Go might very well compile easily on multiple platforms, it does so not by solving the complexities inherent with this problem but rather by merely hiding them from the user. There are plenty of examples in the article so I won't elaborate on that part but his examples mostly revolve around $(platform)-specific features being poorly poly-filled on non-$(platform) platforms. [0]: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...

est31 6y ago
I skimmed over that article and most of the criticism is about OS API wrappers. The thing that enables Go's single command cross compilation is thanks to other components of the pipeline being implemented in Go, like the linker, or not needing Windows import libraries (there is a merged RFC for Rust called raw dylibs to solve this, but implementation has stagnated... go has this feature already). In the long term, Rust may end up in a better place than Go regarding portability but of course as long as GCC can target more than clang and there is no Rust gcc backend while there is a Go backend, Rust can't be better than Go in all portability aspects.
- deleted 6y ago
  [deleted]
SiVal 6y ago
I just read that article, and I'll bet you're right that it represents the (unstated) thinking behind that conclusion. But if so, my conclusion would be different from the author's. The big picture is that Go programming is intended to be more automated while Rust programming is intended to be more customized (relative to each other). When the automation does what you need, it's more convenient, so it's more useful. When it doesn't, because of some issue or other, Rust's ability to customize is more useful. Go can be customized, too, but it's usually the case that something intended to be automated is harder to customize than something intended to be customized like Rust. So my conclusion (for just this 2-language comparison) would be, Use Go when its built-in features do what you need. It's easier to build with in that case. Use Rust when you need more optimization of something than you can get out of the box from Go. It's easier to optimize.

jedisct1 6y ago

My experience is completely the opposite. Go is excellent for cross-compilation. The same compiler can compile to a lot of platforms out of the box, and making portable applications requires very little to no platform-specific code. Go's standard library exposes a consistent API across all platforms, and external dependencies also do a really good job at this. Rust, on the other hand, requires installation of subsystems, and only few of them are properly supported ("Tier 1"). Even a common target such as linux/arm is constantly broken. Dependencies, including popular ones such as libc, are incomplete and not really tested on systems that are not linux/windows/macos. Even on these 3 platforms, writing portable code requires a platform-specific code.

steveklabnik 6y ago
Please file bugs for linux/arm! ARM themselves are in the middle of getting it promoted to Tier 1.
pjmlp 6y ago
> Dependencies, including popular ones such as libc, are incomplete and not really tested on systems that are not linux/windows/macos. That is a consequence of a thin standard library, no guaranteed support on all platforms that the compiler targets.

k4ch0w 6y ago

Yeah this one seems weird. I would think it's actually the inverse. I used to code a lot in Go two years ago, so I can't speak to it much today. Lately, I'm all Rust. If you're on Linux, it's so easy going to get it all working right. Windows is a pain, so much so you end up installing WSL2 and just moving on with your day. A good follow up to this post would be OpenSSL compilation on Golang vs. Rust on each platform. It's a fair test as it's widely used library with both programming languages and all the operating systems.

steveklabnik 6y ago
I am interested in what pain you had beside OpenSSL; I've been exclusively a Windows user for the past few years, and other than it and Postgres, I've had no desire to install WSL.
- saturn_vk 6y ago
  Three years ago I began working in a new company and was initially on Windows, and was extremely open minded about it. Though, perhaps because I structured my "workspace" as I would under linux, where I put the code in some directory under my home one, things began to break rather quickly. The most common and annoying error was maven builds breaking because the path of the files being compiled was too long. After a bit of struggling I decided to go back to linux, it just wasn't worth the hassle.
  - steveklabnik 6y ago
    Ah, I should have clarified: for Rust development. I can't (well, I guess I mean "won't") fix bugs in Maven :)
  - vips7L 6y ago
    I've never experienced this with maven and I've been using it for close to 10 years on windows. This is also putting all of my code under my home directory.
    - 6y ago