There are also two environment variables we need to know

Uhhh… Kinda not really. You don’t need to know about GOROOT or GOPATH or virtualgo.

Something like this will work.

$ cd $HOME
$ mkdir hashtrack && cd $_
$ go mod init github.com/cuchi/hashtrack
$ go get github.com/Laisky/graphql

All your code and deps get scoped to the module.

Go doesn’t have a package manager

Oookaay, this is just wrong. It might help to read up on Go Modules. Go’s official package manager is built into the go tool. https://blog.golang.org/using-go-modules

or official registry

Kinda. There is an official central place to search for modules: https://pkg.go.dev/

Using Go, there is the go keyword to spawn a lightweight thread, also called goroutine. In contrast, Rust uses operating system threads by calling a Thread::spawn.

The code example about this is an async Rust function. So I’m not sure this is completely accurate.

How to read “first take” articles like this:

• Remember that the person will make factually wrong statements about the tools / languages they’re assessing.
• If you work on those tools / languages or are active in their communities, think about what you can do to make it more likely that newcomers form the “correct” assessment.
• If you, like the author, are new to or unfamiliar with the tools / languages, take what they say with a grain of salt, but pay attention to how the communities respond, to see if they would be welcoming to you when you misunderstand things or are ignorant.

Whenever these articles come around, there are always comments by people who specialize with the language, or at least know it well enough to point out obvious mistakes. When writing a comparison about languages, does it not make sense to get input from people who know the language really well?

Also, I hate the conclusions. This isn’t saying anything that hasn’t already been said. They read like the front page of the languages respective landing pages. I don’t think “If I build exceptionally/mostly for Linux” is a good reason to pick Go as a language. This entirely misses its strengths. I primarily write Rust on Linux and, even when doing very advanced build configurations, I’ve never run into an issue so big I’d switch to Go.

Decent write-up overall. I did have a couple of niggles though.

The first thing I look when using a new toolset is whether it has an easy way to make it available for my user, without using the distribution package manager to install it system-wide.

I didn’t really understand this part of the article. Both of these languages compile to binaries that don’t require a VM to run (like python). Why is he concerned about installing it “system wide”? Go can be installed locally too by the way. There’s no need for these python-esque virtual environment managers.

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.

I haven’t read about someone complaining about GOPATH in a very long time. That really surprised me.

Reasons I would use Rust
If the project has critical requirements about security
If the project has critical requirements about performance

I sympathize with the difficulty here because languages are extremely difficult to categorize like this, but I feel like he’s suggesting that Go isn’t safe and doesn’t focus on performance. It very much is safe and has a very strong focus on performance.

Thanks for the write up and I really like your choice in both subject matter and criteria on which to to compare the two language ecosystems. Overall I thought it was a good analysis of the two. I can’t speak for Rust, but as someone who has developed in Go, I think your write up would benefit from a more in depth look at Go Modules. Go modules are how dependency management is done in Go these days, and while not a “package manager” per se, they do convey many of the same benefits. They have the added benefit that you’ll probably never have to think of GOPATH again.

Cheers

Constructive criticism: Is there really a reason to be framing this as Go versus Rust? Why not create a title that is neutral and does not immediately set up an opposition? What do you think of something like “Learning Go and Rust by Writing a CLI tool”?

In a “versus” article, I’d expect an expert in two equatable languages to do truly deep, thoughtful comparison where it is most meaningful. Which brings about another point:

Go and Rust are not trying to solve the same goal, and never have been. Go is a multi-purpose systems language that is optimized for writing for “software in the large” (i.e. software engineering on a large scale), and Rust was designed to be a memory-safe language that is fast (and does so by not having a garbage collector.) These are different tools, designed for different reasons, and intended for different uses.

So, no offense, but I’m reading the title more as “Apples vs. Oranges: Writing a CLI tool” There’s nothing wrong exploring languages via projects, and writing up your experience. That’s great, thanks for sharing, and it’d be great if you kept doing that. However, you may experience less backlash in readers’ comments by not trying to set the languages against each other.