Learn Go in five minutes

1. git init

2. git remote add %something%

3. go mod init %name_of_your_module% (where in most common case name is your repo address without the https part)

4. https://github.com/golang-standards/project-layout - this repo has the default project structure. Each subfolder has README that describes the purpose of the folder

5. go get -u github.com/gin-gonic/gin to add gin (web lib) for your project. Same for any other package. The will be added to your go.mod and go.sum files

5.1 import "github.com/gin-gonic/gin" in your code to use gin

5.2 package may have more than one major version (tag). If you want to use package at latest tag 2 - you add '/v2' when you 'go get' the package (i.e. go get -u github.com/gin-gonic/gin/v2)

6. git commit && git push to publish

7. Not sure what to you mean by 'fork&clone&submit&pr including 3rd party submodules'. You may use vendoring but in most cases you don't need it as you have your dependencies in your go.mod && go.sum files. You may want to read more about vendoring and gomodproxy though.

8. Testing is pretty easy but I guess you want and article about best practices? I won't post any link as I find the topic as too controversial regardless of the language\stack

9. CI - not sure that does this have to do with the language

10. haven't done much profiling or debugging to fill you in.

LoL

Here in India every kid de-facto refers to few content farm websites and while they are not outright wrong, there will always be subtle errors, as the content is contributed by other students only. And books - the textbooks are so unpopular and not even available on libgen.

Day by day, academia seems more like a drug cartel.

I feel like there's something a bit off about charging money teaching a skill that I haven't personally used extensively in a professional context. I guess others feel differently

There is then a discussion about monotonic time. The author immediately knows they want monotonic time, but there is no method that specifically returns that. Instead, go embeds the wall clock and monotonic time into a time.Time when you create one with time.Now. It uses the wall clock time for display, and monotonic time to compute the difference between two timestamps. This is not what the author expected, but it ultimately allows them to do what they want. (There is then a complaint about how when you boot a Raspberry Pi without giving userspace any time to start up, the time is set incorrectly, and Go doesn't help. Well... yeah. You can add a hardware RTC if you want the time to be correct as soon as the i2c subsystem comes up, or you can wait for NTP, or you can live with the wrong time. Not sure how any of this involves Go -- it does expect the OS to do OS things for it.)

If you were going to write a damning critique of why to never use Go, it would probably be something like "this dumb library uses channels, sync.Mutex, and atomic.AddInt64 all in the same code and it deadlocks and runs out of memory" or "I installed the most popular ORM on Github and it prints colored text to the console when there is a database error rather than returning an error from the function". I think the linked article totally misses the mark on what problems people are likely to encounter with Go. Let's be honest -- 99% of programmers have no idea that their OS has a monotonic clock, and are quite surprised (and have no idea how to fix it) when start := time.Now(); time.Sleep(time.Second); fmt.Println(time.Since(start)) prints a negative number. But... with Go they don't have that problem. Pretty interesting.

Go isn't for everyone, and that's okay, but it seems kind of silly to make a judgement based off of a negative review hinging on a pretty poor understanding of a language.

When the author is talking about how great Rust's error handling is (by forcing you to decompose the Result type), they also forget to mention things like "the go linter that everyone uses will let you know that you are ignoring the error." It's not a "Rust is always safer" scenario like is implied, it's a deliberate tradeoff for a less-fussy compiler, because sometimes you're prototyping and want to ignore the fact that you're not handling everything perfectly. Yes, Rust has better typing, and Result types are a great pattern, but the article makes it sound like the Go situation is uniquely bad.

Similarly, with the complaint: "Rust Paths, however, are... arbitrary byte sequences. [...] See, there's no "path" type in Go. Just "string". And Go strings are just byte slices, with no guarantees what's inside." If you program in Go for a week, you know that strings are "just byte slices." If you want to see if it's got utf-8 contents, just run `utf8.Valid(mystr)` - it's in the standard library, easy to find, and the obvious solution. Imagine telling a new programmer "ah, you see, the FilePath doesn't implement the `Display` Trait, so you have to write `println!("(dir) {:?}", path)`, and this is much better than in Go, where you write `fmt.Printf("(dir) %q", path)`". But the author doesn't show the Go solution, because that would reveal that they're essentially quibbling about syntactical choices made in the built-in string formatting library.

Nearly every single complaint is like this. For example, the author seems to be unfamiliar with basic Go naming conventions: "(Can I just point out how hilarious that "Extension" was deemed long enough to abbreviate to "Ext", but "IsPathSeparator" wasn't?)" - yes, because Ext is a much more common thing for calling-code to use, and IsPathSeparator is rare to need. "Familiarity admits brevity" is the saying in the Go community - and as a corollary, the more you use it, the shorter the name can be.

And once you get past the nitpicking of the file stdlib, the author's main complaint is "there's too many dependencies downloaded for some packages", as if they don't believe that the go compiler can do basic dead-code elimination like every other real compiler?

Monotime itself has 0 dependencies, which, again, the author knows, because they pasted the entire source into their article verbatim. If you are stuck on dial-up or something and hate downloading bytes just to throw them away - just copy these two files (12 lines of code) into your project! One of the Go proverbs is literally "A little copying is better than a little dependency."

This isn't a piece with real criticisms, this is a "rant" (self-described by the author) because they're honeymooning with a new, prettier language now (Rust). I find it impossible to believe that the author literally does not know these things after working with Go for "thousands of hours." I'm by no means a Go expert - I haven't written a line of Go for about 2 years, and the biggest project I ever worked on in Go was 499 lines - but the only thing I had to research for this comment was running `cloc` to get those 499 lines.

And indeed, the author started another article about Rust 6 months later, "Learning Rust is... an experience. An emotional journey. I've rarely been more frustrated than in my first few months of trying to learn Rust." When trying to explain how to write a function to add two numbers (the hello-world of functions), they write "We're getting dangerously close to flirting with academic papers at this point, so let's go for an example immediately."

Go isn't Rust. Go is made for building things that the kid 30 days out of coding bootcamp can jump right into and start fixing bugs. If you like Rust, more power to you. But it's not built to be what Go is built to be.

    [Ancient Aliens Guy Picture Here]

               FUNCTIONS

Go feels like it's aimed at creating applications that run at a level above where C traditionally runs while keeping the pared down feature set of C, and it just doesn't work well imo.

I loved playing with Go, but eventually it feels like you're conditioning yourself to be ok with a lot of "bad" code. Tons of repetition, tons of boilerplate by other names.

It's like the simplicity gets in the way of itself.

-

My take is, use Go for a bit, take the "less is more" mentality with you to a language more suited for real work.

ps: I'm not saying you can't use Go for real work before someone flies at me. I'm just saying that Go's strength is the mentality people have when using it, as a language it's not particularly enabling, and that's by design if anything...

Realize a Go []int ("slice of int") is just a C struct like this, passed by value:

  struct intSlice {
      int* addr;
      int len;
      int cap;
  };

This can be confusing if you're used to C++'s std::vector (which owns the memory) or Python's slices. Go's slices are a shallow pointer/length system exactly like is used in C all the time. For example:

  void sort(int* addr, int len);

  func sort(a []int)

It is probably reasonable to say that Zig is closer to C's current philosophy in practice, which encompasses many additional developments over the decades to deal with various aspects of C and programming real machines that have arisen as both have changes, and Go closer to C's original philosophy of simplicity and relative ease of use. (In modern times, C is not one of the easier languages to use any more, due to significant advancements in the field of making easy-to-use languages. But it was originally intended to be an advancement there itself.)

By similar logic, I can say with a straight face that all of Go, C++, Zig, Rust, and Swift (and more) are "evolutions in general-purpose programming languages like C", despite their wild differences, because the world has gotten larger, and there is room for a lot of variations like that, each addressing different aspects of the newer, larger world.

I’ve only read through the rust book without using it for anything (yet) and have done no work on golang, so I’m legitimately curious to hear your input, not challenging you on semantics :p

Edit: Rust does not use # for comments. Sorry I just had that mixed up in my head, but thanks for the answers!

Personally I'm glad Go has stayed out of exceptions (panics don't count), at scale it's so much easier to reason about flow.

For me, the gold standard in error handling is Rust, where the type system simply does not allow you to ignore errors. This means that the existence of error handling is checked at compile time. Of course, this doesn't mean your error handling is _good_, but I think that's beyond any language design to enforce.

But the Rust system is entirely built around a generic Result type, where both the non-error result (an int, string, struct, etc.) _and_ the error type itself are both generic.

Go straddles an interesting space. Currently I work on a back-end data crunching software, distributed (running on hundreds or sometimes thousands of nodes), each node running 64 or 128 cores with 128 or 256GB RAM. The problem we solve is both IO, CPU, and memory bound. Anyway to look at it, it's a hard problem.

The old version of this program was written in C. Then it was rewritten in Go.

The people who decided to switch to Go was looking for the following features: - Be able to manually lay out memory for performance. So not Java. - Mmap binding to file system, for performance. - More abstractions than C, for adding software features. - Cross platform. The program sometimes runs on Android and IOs. - Easy to learn for beginners. It's not possible to only hire PhDs or C++ gurus. - Easy to dig down into assembly, for performance. - GC doesn't get in the way, for performance as well as adding features.

Maybe these days, C# might work? May Rust? But 6-8 years ago, Go fit the bill and it worked out very well. And the language doesn't feel "limited" in any way. Yeah, I miss generics sometimes. Maybe error handling could be better? Sometimes I need to work around the GC. But day-to-day, I think I focus more on solving actual problems (performance bottlenecks, adding features), instead of pondering if I need to create another AbstractFactory, or tuning GC knobs, or figuring out which pointer type to use.

To me, Go feels very balanced. I can write python or Java like code and get decent performance. If I need more performance, I can dig down pretty deep make CPU work faster. The abstractions are light enough that a new person can figure out what's going on and add features, fix bugs, or improve performance.

I like Go.