>> 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.
> Rust has:
- 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.
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.
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].
[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...
> 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.
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.
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.
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.
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
Author writes that this started as an interview project.
If someone showed you this article in a go or rust job interview, would you consider him for hiring? Why/why not?
I love this font
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'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?