- 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.
Wanna know a quick way to reduce your compile time by several seconds? Skip proc macros that you can impl manually. The Error trait is one such case where the boilerplate impl is worth it.
Absolutely the same about bullet three! My first few Rust attempts had “map_err” all over the place and while it still felt semi-graceful it seemed like a ton of boilerplate. Learning about From was a revelation.
> The first problem I found using Go, was when I was figuring out how the module resolution worked along with the GOPATH, it became quite frustrating to set up a project structure with a functional local development environment.
Really?!
There is no magic. Create a directory anywhere and run go mod init. There is NO need for go virtual environments.
IMO I think that section in the docs is missing quite a bit of things when it comes to module resolution. I had the same issue when learning Go. It was quite confusing trying to figure out the node_modules(JavaScript) or _deps(Elixir) Go equivalent.
Sure, but that’s a terrible experience. Especially for a language marketing itself as simple. And just because you can “go-to-definition” to see where the dep is stored, it doesn’t answer questions like does every project dependency get stored there? What happens when another project somewhere locally has the same dep but a different version? Can you have deps locally stored in your project folder? All these can questions can be googled of course :)
That kind of question need only be answered once though, in the documentation of the dependency system. In this case, all dependencies for go modules are stored in $GOPATH/pkg/mod/MODULE/PATH@version, but that's a minor detail that you don't really need to know, since the documentation also makes clear that all dependencies are downloaded in that directory, so you never have multiple copies of a single dependency with a single version. The documentation also specifies that you can download all your dependencies (or some), in a top-level (in respect to your module) vendor directory. All of these questions and more can be answered by `go help modules`.
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.
Personally, as someone who doesn't write Go but occasionally tries to compile Go projects, GOPATH/GOROOT caused me problems all of the last 3 or 4 times that I tried to compile a Go project, and I struggled to find clear explanations of what they should be set to. I felt like I was being stupid, and I'm sure I should have read the documentation better, but nevertheless, there's my data point.
Indeed that was a problem for many people and a key motivating factor to deploy the new go modules approach (which is enabled by default for a while now). Most of the projects out there now contain a go.mod file.
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.
That's aggravating the problem. No only the original way was painful, but now there are multiple ways and to the newcomer that just needs to contribute to a project - it's all one big mess.
Agreed! I pick up Go a few times a year (which doesn't help, admittedly) and even consulting the official documentation, it's hard for me to figure out what the current, correct way of doing things is.
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.
I can understand GOPATH, but why would GOROOT cause you any problems. I think you needed to set it way back in the go 1.3 days or something, but it's been a more or less hidden thing for a long time now.
> 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.
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.
Most importantly, like many articles and discussions regarding Rust, this article misses the point. It's not about high end language features. In 99% of the projects it's also not about computational performance (but latencies - memory, network, disc and scalability).
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.
The warning comes if you try to call a function for its side effects and ignore the return value. In most cases it’s fine, but ignoring a Result or a Future will issue a warning.
They also try to have aggressive defaults on integer wrapping and so on. I work with a junior who is writing a Go program who would have benefited from the early detection ;)
Rust can statically prove there are no data races, Go cannot.
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.
GVM is really handy if you need to switch between go versions fast. I use it often at work and it's great for that. If you never do that, you don't need GVM.
For a naive code solution, I found the default naive golang code to be better performing than Rust, when processing multiple files together (I/O-bound). I'd be careful assuming Rust is faster by default, as Go has some pretty sane defaults out of the box. The developer experience is faster, simpler and stabler(?) too, but really depend what you want to make. I find Rust interesting but haven't found the time/project to learn it properly on. Point being to avoid costs and risks of premature optimizations.
You may want to consider looking into go modules. It works much the same way that cargo does for rust and you won’t need to worry about GOPATH for most cases.
Apparently there is a new book (beta stage) dedicated on Go for CLI tools and applications [1].
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].
> Apparently there is a new book (beta stage) dedicated on Go for CLI tools and applications [1].
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.
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.
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.
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 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.
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.
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.
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.
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!
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.
The conclusion missed the fact that Go is also multi-paradigm. It just misses the syntactic sugar, but that's not to say you can't use Go to program in multiple paradigms.
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 :-)
>> I want a very simple language for my teammates to learn
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.
> If you still feel that Go is simple to learn try to read some kubernetes code
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.
Yea agree, if your looking at it to just understand what writing a CLI in Rust is like, there are a lot of use cases in which a CLI can benefit from performance, but this isn't one of them and he doesn't call that out.
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.
> The Go code in K8s is simple, the system of Kubernetes is complex
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?
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.
This doesn't explain it at all, specially the ecosystem surrounding schemes - informers, cache clients and various other code generators for typed as well dynamic API clients
I think there are plenty of tools out there that wouldn't be classified as "systems programming" but frankly should be written in an extremely performant way.
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.
Most code in the k8s project is easy to read and understand.
There are really some parts in it which are not so easy to grasp. One reason is k8s was written in Java and there are several over-abstractions in the code design. The other reason is there are too much generated code.
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.)
As I see it, Go could be a nice alternative to Java or C# for most problems, and Rust looks like a nice alternative to C++ for most problems.
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.
Not having garbage collection isn’t a personal preference, it’s something that enables high performance, low footprint programming.
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!
Great comparison, but I’m sad that D lost out in the popularity wars. Talk about a versatile workhorse that is appropriate for 90% of (non-GUI) tasks.
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.
How is the compilation speed - instant (close to Go), seconds (like C# or Java), something longer (like C++, Rust)? Sorry, I have not used D extensively.
I've not looked into D yet, but not having a GCC or LLVM backend is imho not necessarily an advantage, and in many cases even a disadvantage. The simple toolchain is one of the reasons I quite like Go...
I love Rust, but a few drawbacks made me choose Golang over it:
- 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
Have you tried IntelliJ-Rust? I am curious how it differs from Goland (I've never used it.) I personally use VS: Code with rust-analyzer, which is the successor of the RLS, and much better.
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.
IntelliJ Rust is good, but has still the same problem as any other IDE for Rust (that is, RLS performance). You have to wait 5-10 seconds to get a feedback from the compiler :(
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 :(
91 comments
[ 2.9 ms ] story [ 149 ms ] thread- 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.
https://typeof.net/Iosevka/
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.
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.
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 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 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 :-)
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!
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!