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.
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.
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.
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.
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.
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.
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.
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.
Windows path length limits are infuriating, and also really exciting because what the limits actually are varies depending on what API calls the program is using to access the filesystem. What fun!
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.
In Java, the file names directly reflect the package and class structure. If you have a class "org.example.long.package.name.SimpleInterfaceBeanFactoryFactory" with an inner class "Inner" that has an inner class "InnerInner" that has an anonymous inner class, the source code for it normally resides at "src/main/java/org/example/long/package/name/SimpleInterfaceBeanFactoryFactory.java", and the bytecode for that anonymous inner class, after being compiled through maven, resides at "target/classes/org/example/long/package/name/SimpleInterfaceBeanFactoryFactory$Inner$InnerInner$1.class". That's already over a hundred characters long, and it's not unusual to have even longer names; a quick look at a project I have around here shows bytecode files with path names approaching 170 characters starting from the maven root. Add to that around 30 characters for a "projects/project-group/project-name" hierarchy, plus 30 more for the path to the user directory, and it's already uncomfortably close to the Windows 260-character limit. It's not hard to imagine that a project with a deeper package hierarchy could hit that limit, and it only takes one file to break the whole build.
Based on my own experience with C/C++ projects are built with the assumption that you are on Linux. You have to do quite a bit of fangling to get it working with Windows, that it isn't worth the time. I don't want to setup mingw or cygwin to get things working for one weird library that's included.
I don't have a requirement to build for Windows, so I will always just avoid it. I think Microsoft is making strides in developer experience, but I think it also sees the signs that Linux/Containerization is the way forward thus why they built WSL. Azure itself is over 50% Linux now too.
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.
Comments
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?
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-...
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.
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.
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.
Please file bugs for linux/arm! ARM themselves are in the middle of getting it promoted to Tier 1.
That is a consequence of a thin standard library, no guaranteed support on all platforms that the compiler targets.
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.
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.
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.
Windows path length limits are infuriating, and also really exciting because what the limits actually are varies depending on what API calls the program is using to access the filesystem. What fun!
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.
In Java, the file names directly reflect the package and class structure. If you have a class "org.example.long.package.name.SimpleInterfaceBeanFactoryFactory" with an inner class "Inner" that has an inner class "InnerInner" that has an anonymous inner class, the source code for it normally resides at "src/main/java/org/example/long/package/name/SimpleInterfaceBeanFactoryFactory.java", and the bytecode for that anonymous inner class, after being compiled through maven, resides at "target/classes/org/example/long/package/name/SimpleInterfaceBeanFactoryFactory$Inner$InnerInner$1.class". That's already over a hundred characters long, and it's not unusual to have even longer names; a quick look at a project I have around here shows bytecode files with path names approaching 170 characters starting from the maven root. Add to that around 30 characters for a "projects/project-group/project-name" hierarchy, plus 30 more for the path to the user directory, and it's already uncomfortably close to the Windows 260-character limit. It's not hard to imagine that a project with a deeper package hierarchy could hit that limit, and it only takes one file to break the whole build.
That limit just isn't a thing anymore....
https://duckduckgo.com/?t=ffab&q=Enable+Win32+Long+paths&ia=...
Ah, I should have clarified: for Rust development. I can't (well, I guess I mean "won't") fix bugs in Maven :)
Based on my own experience with C/C++ projects are built with the assumption that you are on Linux. You have to do quite a bit of fangling to get it working with Windows, that it isn't worth the time. I don't want to setup mingw or cygwin to get things working for one weird library that's included.
I don't have a requirement to build for Windows, so I will always just avoid it. I think Microsoft is making strides in developer experience, but I think it also sees the signs that Linux/Containerization is the way forward thus why they built WSL. Azure itself is over 50% Linux now too.
Source: https://build5nines.com/linux-is-most-used-os-in-microsoft-a...
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.