Go vs. Rust: Writing a CLI Tool
cuchi.me
cuchi.me
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?
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-...
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.
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.
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.
That is a consequence of a thin standard library, no guaranteed support on all platforms that the compiler targets.
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.
https://duckduckgo.com/?t=ffab&q=Enable+Win32+Long+paths&ia=...
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 feel this is said in a demeaning way plus it is not true IMO plus if I had a penny for every time I read that I'd probably be much richer by now.
Go is not a simple language to learn correctly. It is only simple if what you're trying to do is simple which goes for almost any production language that is not designed to drive you nuts. And it should be simple at that. A language is a tool. It should be easy to use in order to solve easy(ish) problems and feel progressively more difficult as the problem domain gets more complex. Having a language that gets in the way right from the beginning makes you focus on the language rather than at the problem at hand which makes for bad overall solutions.
Example: If you still feel that Go is simple to learn try to read some kubernetes code.
Having said that, I accept that Rust is way harder to get to grips with. My question is why should I though? I understand the appeal of Rust up to a point but I think much of it as a bad form of machismo - something quite common in the industry and also quite destructive. To me Rust is a better alternative maybe to C and C++ but that's about that. If you program systems and you absolutely do not want a garbage collector doing its thing then by all means go for it. For everyone else though I don't get why you should try to climb your project mountain in flip-flops. Not saying that it can't be done. Not saying that you won't get extra wow points for doing it. Just saying that you don't need to.
The Go code in K8s is simple, the system of Kubernetes is complex
Rust isn’t about machismo, it’s about high performance computing. Try writing graphics or machine learning code in Go, it’s not about being tough it’s about having a tool that can actually do the job.
Yes. That's what I said. So, advocating for Rust in a non-high-perf requirement project makes for extra effort/optimization where it is not needed. Speed of dev, correctness, ease of maintenance are needed though. Optimizing for the sexy rather than the needed is a textbook machismo attitude. Good for CV-builders and for ego maybe but it usually hurts the company and the maintainers down the road.
And zero runtime cost abstractions. And having a non-profit to shepherd the project (and thereby having a good chance that you may influence the project). And strong typesafety. And design by committee (see how async-await was "agreed" upon).
Also Rust is called a multi-paradigm prog lang in the article: I dont think so. Scala is. Rust is not. It brings as much FP features into the language without sacrificing its core paradigm: an imperative systems language.
Can you link me to a doc which explains the runtime scheme type system of Kubernetes? Could never wrap my head around how that even works. And why they had to even do this in the first place?
Because they wanted stuff like Watcher<T>, but Go does not have generics.
Runtime scheme and the k8s machinery can be pretty awkward. Scheme is just a way of registering the available datatypes by group/version/kind so the client can look at any given object and figure out if it knows how to decode it.
A lot of the excuses I see for slow (or just bad/sloppy) code is that it would cost more to the business to improve it than to leave it alone. This is a fine argument but I don't believe the cost analysis is ever correct.
I do agree that thinking Go is simple to learn is bad in learning Go (I mean it is not good to learn Go seriously). On the other hand, I also think Go is a quite readable language.
I mean, can't that be said for any language? I've worked with a lot of languages over the decades, and find Go extremely refreshing in it's simplicity.
Kubernetes is an extremely complex system, and Go isn't the reason that k8s is hard to understand. (I could say the same thing about C and the Linux kernel.)
One could go and compare Javascript to COBOL code solving some random problem, and perhaps even that can be helpful in some way, but the result of that comparison should not imply that one of these is, in general, better than other.
I guess Rust and Go are compared so frequently because they are both becoming very popular and people are tring to figure out which one of them is worth investing time to learn.
A lot of these comparisons remind me of java vs c++ discussions 2 decades ago.
I’ll agree that I personally am a little confused by the HTTP web server frameworks I see written in Rust, it feels like overkill there. But Rust definitely has a place. If you don’t see it that’s absolutely fine, it just means you’re not in a space that would benefit from it!
- monadic constructs (Option & Result) - the error propagation operator - the From trait, to automatically convert errors on propagation
> The combination of the three features above makes up the best error handling solution I saw in a language, being simple, sound, and maintainable at the same time.
I absolutely agree with this. The error handling in Rust is fantastic to work with.
Once I learned about bullet three, error handling became less of a chore and more of non-issue while staying confident that any errors would be handled correctly.
Success of our projects is ultimately shaped by the development process, the matureness and reliablity of the ecosystem (standard lib of Go) and ease of use of the tools, so you can focus on the problem to solve.
Besides of that: I haven't written much Rust, so I can only comment on the Go side:
I never heard of GVM (local env for Go) - probably because it's not needed. Just use Go modules. Really, no need to worry about GOPATH etc.
Regarding the conclusion:
Rust is ultimately faster and uses less resources, no dispute here. However, there're no benchmarks in the article. For the given CLI application, the result would very likely be: There's no performance difference.
However, Rust is not generally safer than Go. Rust is safer compared to other language with manual memory management (C/C++). Rust has a stronger typesystem, but that doesn't mean Rust programs can't panic too.
- it warns you if you ignore an error. - it forces variables and fields to be initialized. - it has sum types and generics instead of interface{}. - it prevents some race conditions at compile time. - it pushes programmers towards immutability.
Rust offers statically checked deterministic destruction, which makes handling non-memory resources much safer from leaks. Failing to dispose non-memory resources properly (e.g in databases) may be considered a correctness problem. Rust helps in this area, Go doesn't.
Personally I think it'll be interesting to include D as well for more complete comparison due to it also fits the bill and it's no slouch either. A very fast TSV CLI tools written in D by eBay is covered in HN last year [2].
It'll also be very cool and useful if someone could write CLI tools in any of these compiled languages for supporting Arrow, Parquet and TileDB data formats [3].
[1] https://pragprog.com/titles/rggo/
[2] https://news.ycombinator.com/item?id=20848581
[3] https://www.i-programmer.info/news/197-data-mining/13263-new...
I own that book, and I have two considerations:
1. I've found Golang simple enough not to need particular education on building simple tools; the book itself is well-written though, for people who like to be accompanied or motivated in learning a subject.
2. they've labelled "beta 2" (!!) a book where 40% of the content hasn't been written; in the software world, this would be (rightfully) ridiculed.
Really?!
There is no magic. Create a directory anywhere and run go mod init. There is NO need for go virtual environments.
This is all well explained in the documentation. The first section of https://golang.org/doc/code.html
Really unfortunate the author missed this because the go tooling is really excellent and in 2020 you don’t need to know anything about GOPATH.
Now, I use go-to-definition not because I want to find out where something is located, but what it looks like. The location is just exposed as a side-effect.
That said there may still be projects out there that are unmaintained or the author didn't bother to convert to go.mod, so you might occasionally still encounter GOPATH.
Dedicate 30m to read https://blog.golang.org/using-go-modules and try it out with a small demo project,e.g. write a small tool that emits a uuid; keep the toy project very small so you don't encounter other problems that might distract you from learning the basics of dependency management.
Search for dependencies using pkg.go.dev.
To be fair, this was this was absolutely an issue until very recent if you look at how long Go has been around, and there's still a ton of now outdated information out-there. I like Go, but that was one of the things I struggled with from the start years ago, and the GOPATH/GOROOT always felt like a dirty unnecessary hack.
D is a valid competitor of Rust, that just happens to smash Go in the process. All the ergonomics of a high level language like c#, decent (toggleable) garbage collector, the ability to write all your scripts in it... the list goes on.
It lacks options in the editor and tooling department (although VS Code support is great), but that comes with community size.
Other things it has over go:
Generics, inline assembly, kernel threads, and great interopt with C/C++.
Here's an old thread:
https://forum.dlang.org/thread/hpsps2$2lqp$1@digitalmars.com...
golang compilation is about the same speed, if not slower than Java or C#. Especially for larger projects.
- Compilation Time - IDE experience: I have yet to find a good IDE that works like Goland does for Golang, this anyways is due to the compile time :( - Non-static binaries by default - Too verbose (compared to Go) - CLIs are not that easy to write compared to Golang, but this might be due to the fact that I have yet to find a similar library to alexflint's go-args for Rust - Lifetimes: I'm too stupid to understand them properly, and I get frustrated when I think I understood them and then I spend half of my development time to fix an ownership issue
Again, I _love_ Rust language, but I very much hate its compiler, and thus my general development experience. If RLS and the Rust compiler were as fast as Go's one, I guess that the whole experience would be much better for me. Additionally there isn't really an IDE for Rust that works like Goland for Go :(
I have to admit that I'm much faster at writing Go CLIs (and I wrote a lot of CLIs in the past couple of months), but I might be biased for the reasons explained above that didn't let me enjoy that much programming in Rust.
For a private project of my own, composed of three libraries, I spent most of my time fighting with the borrowing system and the verbosity of the language itself (like `pub field` rather than Go's `Field`) or the whole `json:"fieldName"` annotations that Golang uses.
Last, but not least, I can cross compile Go projects from my Linux computer targeting Windows without any cross compiler toolchain, and the resulting binaries are static. This is a feature I love!
I would very much like to have somebody providing me with tips on how to improve my Rust experience
structopt will give you a go-arg-like experience. clap 3 is going to adopt it, in my understanding, so that reduces the number of packages.
The combination that works better is Clion + Rust plugin, but just because you can easily debug w/ gdb.
I still have to try Rust-Analyzer, first time hearing it - hooefully this will improve my developer experience: heck RLS is slow as hell even with vim :(
Thanks for the tips Steve!
rust-analyzer is way way faster.
Thank you for elaborating!
If someone showed you this article in a go or rust job interview, would you consider him for hiring? Why/why not?
The methodology is there.
I don't even care if he doesn't know the language we are using, I care about how he thinks because that is the skill used to solve problems.
For a junior role in either language - yes. The author shows a clear interest and the ability to pick up new technologies.
I don't entirely agree with the statement that Go seems to not work on Windows ("if build mostly for linux"). Go works fine on Windows, although I do agree some tooling just works better on *nix, but that goes for many langs :-)
It's good to see such a comparison form the perspective of a novice with the languages, but it'd also be interesting to get such a view from someone more experienced with both.
The source code is not bad though! Although the project structure could use some work :-)