1. 33
  1.  

  2. 23

    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/

    1. 3

      Go doesn’t have a package manager

      Oookaay, this is just wrong. It might help to read up on Go Modules.

      When did this happen? It is news to me (but then again I only try Go every now and then :-)

      1. 2

        Go 1.11. Since it wasn’t proposed until 2018, a lot of people who tried the language years ago aren’t aware of its existence.

        1. 5

          I think the author is mostly just confused about the GOPATH/Module situation. Modules are not really a “package manger” in the same sense that npm or whatnot are (it’s better!) and there’s a lot of “legacy” advice and documentation across the internet. Never mind that the tooling is rather weird as well, where things behaving in different modes depending on how/where you invoke them.

          It’s all pretty confusing especially for newcomers; I’ve seen quite a few people get confused by it. I started writing a comment about this last night, but ended up just sending it as an email to the article’s author.

    2. 10

      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.

      1. 15

        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.
        1. 4

          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.

          1. 10

            I don’t understand all the hate. The OP states he wants to write about his experience learning two new languages. This should be read as a post-mortem of impressions and lessons learned along the way, not as a olympic-level competition of which language is better. Yes, the author missed go modules, used async functions instead of threads, but those are normal mistakes of those who are just picking something from the first time. This post is a diary of their journey more akin to a travelogue with some recommendations in it. I think that experts coming here to just point a finger at it and shout “YOU’RE DOING IT WRONG!” are approaching this kind of post wrongly.

            1. 3

              When writing a comparison about languages, does it not make sense to get input from people who know the language really well?

              I think it’s fine to write about one’s experiences on a personal blog. It’s a good mechanism for getting thoughts and feedback from others — either the specialists you mention, or just your friends and local community. I don’t think there needs to be an expectation that you hunt down experts in each language and get feedback before publishing on your own website.

              This is the first post on a new blog, by someone who describes themselves as a self-taught developer. I doubt this is intended to be the the definitive comparison article between Go and Rust. ;-) It’s simply a post about one developer’s experience implementing the same project in two languages.

            2. 6

              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.

              1. 1

                I feel the same way with toolchains. I want them in the scope of my user, not polluting for all users. That’s because I sleep easier knowing that I can diagnose issues by shifting into a different user instead of having to mount a different /. It probably comes from years of someone installing brew or pip as root and having a random hodge-podge of crap all over your system that makes each project non-replicable.

              2. 2

                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

                1. 1

                  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.

                  1. 2

                    Go and Rust make very different design choices in some areas, but there are a lot of areas where they overlap. I thought the author did a good job with the “how did I end up using Go and Rust?” section. It explained the motivation.

                    Here’s another good head-to-head comparison – writing a performance oriented bundler which has to parse and analyze JavaScript very quickly:

                    https://lobste.rs/s/kzd5pk/rust_dropping_heavy_things_another#c_f2mij8