1. 23
  1.  

  2. 12

    Nice, but I think it needs to include some mention of interfaces. Maybe 7 minutes of Go?

    1. 1

      I’ll see if I can work that in later tonight (AEST) after work.

    2. 7

      Honestly, Go is one of the few languages I feel like most people who already know a language could pick up in ~5-10 minutes. Minus goroutines, channels, and maybe interfaces it’s so damn simple.

      1. 6

        And with goroutines, channels, and interfaces it really only takes a couple days of solid use to get comfortable.

        1. 3

          There are gotchas with capturing variables in a loop before passing them in to goroutines, and that for x := range []int{3,4,5} loops over the indices, not the elements. And fetching a rune from a string can not be done with s[1], but with []rune(s)[1]. Tiny things like these take additional time to learn.

      2. 6

        with two of these kinds of posts making the rounds recently, I feel the need to mention one of my favorite versions – here’s the Go version: https://learnxinyminutes.com/docs/go/

        1. 2

          I will link this :)

        2. 5

          This is awesome but I noticed an error https://gist.github.com/prologic/5f6afe9c1b98016ca278f4d507e65510#structs here.

          As far as I know, you can’t use : in structs https://golang.org/ref/spec#Struct_types

          1. 6

            Also typo in: func (a *Account) Dsposit.


            The “Arrays and slices” section mixes up the two a bit; this is fine for colloquial usage (I do it all the time), but probably not a good idea for an introduction to Go. For example:

            Arrays are created with [T]like this:
            
            var xs []int = []int{1, 2, 3, 4}
            

            This creates a slice, rather than an array. Okay, it also creates an array, but you don’t have access to that: just the slice. To create an array you’d use xs := [...]int{1, 2, 3, 4} or [4]int{1, 2, 3, 4}. Those []int and var are pretty superfluous by the way: xs := []int{1, 2, 3, 4} does the same.

            It mentions that “Arrays can also be created and appended to”, but this isn’t the case: arrays are always fixed-length. You can append to slices, but this doesn’t really “grow” anything: it just increases the slice’s len and sets that value. If the array underlying a slice runs out of space (cap) then Go will allocate a new array (rather than resize the array).

            There are a bunch of articles on the ‘net that go in to more details on this. It’s also interesting to look at the source for append(), which is pretty easy to follow.

            Personally I’d probably just omit arrays entirely and mention just slices for such a short “learn in 5 minutes” introduction. There are some use cases for using arrays directly, but in the overwhelming majority of cases you’re dealing with slices.


            Another thing I noticed is that there’s quite a lot of superfluous use of var; most of the time := and = should be fine, and var is only really needed in some cases (i.e. nil map or slice). I’ve seen a number of people new to Go (especially those used to JavaScript) use stuff like var x int = 1 because they read about var and think it’s needed like in JS. It’s another thing I would personally omit, or mention only as a footnote and not use in the rest of the article. The less there is to remember, the better.

            1. 2

              Thank you! These are all really good points! I write a lot of Go myself and very rarely use var, and you are right you almost never create arrays directly, mostly slices. I’m not sure how to rework that section yet, but I will have a think about it and rewrite it tonight (AEST) after work.

              I also fixed up a few errors (things done mostly by hand) where I rushed this a bit (probably a bit too much).

          2. 4

            Go’s learning curve is amazing. I was writing real, useful code in Go in just a few hours and had successfully written a real, “large” application in a few days. It’s great.

            It’s a shame that it seems like all the momentum is with Rust now. It almost feels like there’s no point in learning anything other than Rust given the trajectory of things…(I’m sad because I prefer Go to Rust).

            1. 2

              What momentum? I must be reading all the wrong sources of things, I don’t see Rust as on an upward trajectory myself (maybe I’m just biased), I don’t even see it on the TIOBE index where Go is at #14. :D

              1. 2

                Rust is at 26 right now. It’s jumped into the top 20 within the past year and jumped up and down.

                The momentum I’m talking about is that Rust has been picked up by Microsoft as an acceptable language, Linus has intimated that he might be willing to allow Rust in the kernel, I’ve seen a lot of “why we switched Product X to Rust”, and so on. Go has been “stable” for over a decade now, so it’s got an enormous head start, but I feel like Rust is going to rapidly outpace it.

                Again, they’re both fine languages, I just feel like I’m gonna need to learn Rust for the sake of my future career.

                1. 3

                  Rust will never have the “market adoption” of Go. Not to say it’s not worth learning! Or that it’s not the right tool for many jobs. It’s a great language.

              2. 2

                I think it depends on what you want to write and where you want to write it. A lot of big name companies are doing things in Go these days, it’s hardly fallen out of favor in that sense.

                1. 2

                  It’s a mistake to conflate online “buzz” with real momentum. I’d argue that Go has less buzz precisely because it has lots of momentum. Rust doesn’t have much momentum right now, it has acceleration.

                  1. 1

                    Rust doesn’t have much momentum right now, it has acceleration.

                    That’s a really elegant way to put it.

                    I do feel like every job posting/offer I come across has C/C++/Python/Rust listed, and not Go. I realize that there’s very likely selection bias at play given the kind of jobs I look at.

                    EDIT: Okay, so yeah, perception vs reality. I went to Stack Overflow and did a job search. 109 for Golang, 18 for Rust (and I’m sure there’s overlap there).

                  2. 1

                    Go learning curve is smooth but it feel really like … work even if I only worked with it during a few months two years ago, that was the lasting impression Go made on me. It feel like a tool to get stuff done. The connotation is not negative but I don’t see myself use it for doing fun stuff on the side. Since that time, I want to take the time to learn more Go but for now I am waiting that Go2 drops because my knowledge is dated (never been exposed to go module at that time for example). It feels like a nice tool to have but I will not have fun creating with it.

                    On the momentum side, Go still have a lot and Rust has gained a fair share of it but it really different field and for different reasons imho and for teams/companies with different needs and approaches. Nothing to be sad about, your hammer don’t have to fit every nail.

                  3. 2

                    Thank you all for the kind words! I reworked the “Arrays and Slices” section a bit (still not 100% happy with it, as I really didn’t want to go into the fact Go has fixed-sized arrays and slices, but oh well…) and fixed a few mistakes others pointed out, thank you! 🙇‍♂️ I wrote this really quickly last night (perhaps a little too quickly),appreciatee the quick feedback!

                    Go is amazing! 🚀

                    1. 2

                      It took me 6 minutes, Am I worthy?

                      1. 3

                        It took my colleague at work today ~9mins! Don’t worry I should have called it “Learn Go in ~10mins” sigh oh well 😄

                        1. 2

                          At this Rate, I would learn all of computer science in a week

                      2. 1

                        this document includes information on how to import third party code, but no information on polymorphism. That’s a very curious framework of priorities.