* Static binaries by default

* Single, straightforward build system (no DSLs)

* Single, ubiquitous code formatter

* Minimal learning curve

* Zero-work package publishing

* Zero-work documentation generation and publication

* Testing framework out of the box

* Production-grade HTTP server out of the box

* Low latency GC out of the box

More generally, C# and Java have always seemed to have a philosophy of "make everything as abstract and configurable as possible, and make the user understand every configuration option in order to do anything (overwhelm the user with configuration)". Granted, I haven't used C# or Java seriously since Go was open sourced, so it's possible that these are among the things that improved in C# and Java following Go's release.

For me, Go being combination of being well-thought-out, opinionated and batteries included took away the futile fanboi flamewars/bike-shedding: JBoss or WebSphere? Tabs or spaces? Struts or Spring?

For these reasons and more, Go is offers a more pleasant experience when working in a team. When reading code other's wrote,I encounter fewer surprises in the logic and project structure. Go codebases are easier to grok, IMO.

Which is also the hardest part of convincing people to use Go for me: "Why can't I just .map()/.filter()/.find()?" followed closely by "Why do I always have to check for errors?"

What is odd to me is that while yes, my Go code is more verbose than my node services - I always end up writing less Go for the same thing.

One of the things Go taught me is that I was not being as careful about my errors as I should be. It can be argued that exception-based handling provides you a nice baseline default, but it makes it way to easy when doing network or system-type programming to thoughtlessly default to that, when you need to be thoughtfully defaulting to that.

With sufficient care, exception-based programming and errors-as-values converge in the end anyhow in "code that treats errors correctly". But my exception-based code is a lot more informed by the errors-as-values approach now; a lot more try statements with catch statements that actually do something.

Even Haskell's very nice Either monadic handling can make it too easy to be in the heat of the moment and not thinking about what the errors actually mean and what I can do about them.

I don't think it's appropriate for every domain, which is why I qualified the code I tend to work on. But in those domains I'm thinking a lot more about how every single line of code can go wrong rather than leaning on default exception-based handling and expecting it all to work out.

I identify with this so much. Especially when dealing with external things (file system, database, network) things can go wrong at nearly every step. And yeah, that means you have to check errors at every step, but it forces you to think about how you want to handle them, and what message you want to propagate when they happen. As a result, my Go code has very few unexpected errors in production.

Handling errors everywhere means problems are already solved before they happen. No 1 am pagerduty alerts because we didn't consider what would happen if a DNS server hung until we timed out and thought just wrapping in a try/catch and crashing was a good idea.

To get into a situation where you'd need to handle n! cases, you'd need to keep running the statements after a failure, and then collate and return all the errors at the end.

Not sure why you'd want to do that. You'd definitely need to go out of your way to do something like this, and probably start asking yourself why you're doing this pretty early on. Plus it would flat out refuse to compile in some cases where there are dependencies between the statements.

  {n + 1 \choose n - 1}

There is no hard technical line between "unit test" and "integration tests", it's a semantic question of how you define your units. Even if do you take a tiny, restrictive definition of your units, you could still use a fake or stub instead of a mock.

https://martinfowler.com/articles/mocksArentStubs.html

To get very specific for Go, we use testify suites, tend to set up fully functional stubs in `SetUp`, and then test cases either use them to verify happy paths, or `s.BreakStep1()` in one test, `s.BreakStep2()` in the next, etc. So in this case we would write a total of five extra lines for the five possible ways to break.

let _ = openFile()

Error ignored, it does compile, it will probably ends badly.

As for network error: https://pkg.go.dev/net#OpError

The whole point of a programming language is to make the programmers life easier.

By now decades of exposure to programming languages have made try/catch the standard way of working with errors. Forcing the programmer to guess issues, when the compiler/runtime could be doing it- IMO is just plain waste of human labor. And for even medium to large applications is a pointless exercise.

    a, err := foo() // oops, unhandled error
    err = bar()
    if err != nil { ... }

    fmt.Println("...") // oops, unhandled error

    err1 := foo()
    if err1 != nil { ... }
    err2 := bar()
    if err2 != nil { return err1 } // oops

They do, they throw exceptions.

> In the first and the last case, it seems obvious to me where the error is

The last case is especially insidious. I've seen it in production several times now. Very easy to miss. Particularly when refactoring/copy pasting code (which you have to do a lot of in golang).

I see a lot of the same issues in Rust code today FWIW. People just keep bubbling up errors and at the toplevel say "fuck it" and dump them, without _actually_ building a reasonable error chain to offer the programmer a story behind how the error happened. The fact is, error handling in any language is tedious. Whether you do it with a sum type, a product type, or Go's error values, either way there's going to be lots of verbosity and boilerplate.

You can successfully build huge chains of code that are just blindly passing errors up without adding any context about where they happened or anything in a way that even Rust can't compete with.

Haskell mitigates this issue by also having one of the more clever ways of dealing with errors, if you start getting into monad transformers or some of the advanced stuff, so it's not all bad. But it definitely can make it so easy to "handle" errors that you just forget about them.

Go would benefit a lot more from some basic slice manipulation tools compared to features like generics that have actually made it into the language.

The error handling I don't find so frustrating - it's great that it explicitly marks at the call site which functions can potentially error. It's like a working version of an inverse noexcept from C++. I do wish they would take a leaf out of swifts book though, with the try keyword. In practice error handling flow in my go programs is identical to using exceptions, it would be nice to have some helpers to make this default less verbose without losing the ability to distinguish at the call site which calls are error-y.

if err != nil { return err }

    if res, err := actually_important_bits(...); err != nil {
        return nil, err
    }

For an industry that is just starting to understand that code is read hundreds of times more often than it's written, golang fails at the few things we actually know for certain about what makes it easier to understand code at a glance.

    res, err := actuallyImportantBits(...)
    if err != nil { 
        return nil, fmt.Errorf("actually important bits: %w", err)
    }

   if err := actuallyImportantBits(...); err != nil {
       return nil, fmt.Errorf("actually important bits: %w", err)
   }

You can certainly handle "res" in an else block, or even write "err == nil" and handle it there, but that is surprsing. I would say it's simply not done, ever, but the Go codebase itself does it (src/go/parser/interface.go.ParseDir was the first example I found; but my search returned many screenfuls of candidates so there are probably more cases lurking in there).

The fact that you have a choice is not ideal, basically.

But, having actually important bits in if err := ...; err != nil {} blocks is not detrimental to readability. You will know how to read that after 5 minutes of reading any Go program.

    res, err := ...
    if err != nil {
        return nil, fmt.Errorf("...: %w", err)
    }

I'm far from a Go expert, but I feel like this line is a bit pointless, especially if you write it a lot. At this point, why not just not handle the error, or panic?

Let's say you've got a function that reads from a file. If the file doesn't exist, what do you do? That entirely depends on the context the function is called in. If it's in a web server, you might return a 404. If it's a background task polling for some data, you might sleep for a while until the file is uploaded. Or you might want to create the file yourself.

At high scale, you want to perhaps try your query a few more times, backing off exponentially, maybe even round-robining (or more complicated load balancing) among different targets. Throwing up your hands and 5xx-ing a request that easily is not something you can afford at high scales of traffic where small outages happen _all the time_.

so basically you mean that this only applies to like 0.001% of all websites/apps.

thus it's stupid to do it. I mean even than you would have an error that you need to bubble up or circuit break it somwhere but probably not at this layer.

also KISS and MVP, never ever overcomplicate something when you do not know anything yet, so most people don't need to built for scale at day 1 and it also is stupid to do it.

IMO if Go didn’t have its tooling, no one would care about it.

every if err != nil; return err let's me mentally draw a line in the sand and not worry about exception handling for code above that line. It lets me start fresh and restart my mental model with the line of codes below the error handling block.

it doesn't take years of writing Go to understand this, all you need is a open mind to how Go does things.

My code is almost exactly:

err := doThing()

if err != nil {

  return err

err = doAnotherThing()

if err != nil {

  return err

etc.

There's no need for me to "start fresh". Each line of actual stuff doing might return an error which needs to be returned. That's it. It's a complete waste of space and inhibits readability to absolutely no benefit. And this is extremely common across our code base.

It isn't the only difference between the two, but I think it would have consumed enough of the oxygen of the niche Go is currently in that Go might never have been born.

In practice, I find Go to be just slightly harder than working with dynamically typed languages, rather than a huge step, and the benefits I get in return make me prefer it for almost any task above 200-ish lines. I definitely can not say the same about Java, because of this difference and the second-order effects it has on the entire ecosystem.

It is still completely practical to create a production-level Go project by just cracking open a text editor and typing "package main" into your editor and typing away. I get the impression most people would not consider that a practical way to start a production-level Java project.

As for your last paragraph, I feel like we often mean something different between a production-level go and java project. Non-IDE java development is entirely possible, but I think a prod project usually means something much larger than it does in case of go.

I struggle to think of one that has risen to the heights Go has risen.

I'm a computer language polyglot and a bit of a language tourist, though not as much as some people. There's a huge churn of features out there in some language somewhere, that has never manifested in any top-level language like C++ or Java. (For instance, array-based programming has been experimented with quite a bit, but has never been in a top-grade language. The closest that I know of is NumPy.) Whether Go is a top-level language or not at this point is a matter of legitimate debate (depends a lot on your exact definition), but it's certainly knocking on it.

The closest I can name are things like Python, but there is a fundamental difference between run-time duck typing and compile-time interface conformance, although they're certainly related.

A lot of people make a lot of fuss over how fast the programming world moves, but I'm a bit of a contrarian on that. There's a huge amount of churn at the very small scale, but when you get to that top-level set of languages, we're actually very conservative. For pete's sake, C is still a top-level language in 2021! It's finally on its way down, but it's got a long way to go to fall out of that criterion, unfortunately.

This is why I didn't even necessarily label Go as a "top-level" language. It's only 12 years old, after. It's a whippersnapper of a top-level langauge. 25 years old makes for a young top-level language!

How do you evaluate that?

I'm a little lost by what you mean here? In my mind the only difference between a Go interface and a Java interface is Java lets you declare them in the class signature.

That means you can't just take an image class from some JPEG library and declare an interface around its already-existing methods. That means the JPEG library has to know all the interfaces that may be useful, and declare them all first. If some of those interfaces are from other libraries, it must depend on those libraries to do it. This pressures image libraries to get together and have to declare "image processing" frameworks, which creates pressures to create all-singing, all-dancing image frameworks because these new interfaces being declared have to work for everything up front. If you get the interfaces wrong, the end-user of these libraries can't just fix them up on the fly. The framework then is pressured to undergo significant churn as it keys in on the correct all-singing, all-dancing set of interfaces to provide, either breaking backwards compatibility or having to drag along every bad decision it made for extended periods of time.

Granted, if a set of libraries does successfully run this gauntlet, the end result can be quite impressive, but it's a hell of a gauntlet to run!

This is also why it's at least a modestly acceptable Java practice to pre-emptively declare an interface for anything you think you might need an interface for later, because if you don't do it now, you'll have a harder time coming back and doing it later. I have a Java code base where darned near every class is basically duplicated, as both an interface and an implementation. I understand not everyone thinks this is good practice, but the language still pushes you in that direction even so. In Go, it simply neither good practice, nor something the language pushes you towards.

In Go, if I need to parse PNGs, I get a PNG parsing library. It just parses PNGs. The author of the library can make the best PNG library they care to, and the author of the library has no obligations to pre-declare any interfaces. If someone wants to weave this into a metalibrary, they can, and they don't have to fork the PNG library to do it, they can easily declare interfaces as they like, wrap things if they like, whatever. It's all more flexible. You're less likely to end up with that best-of-breed, all-singing, all-dancing awesome framework that is integrated and does everything in the end... but in the meantime you also get to use all the code that would have failed to finish the Java gauntlet.

In Java, because interface declarations must temporally precede all implementations, there's this huge pressure constantly pulling things into huge, all-encompassing frameworks, because all requirements are constantly being pushed up into the interfaces... the same interfaces that also have to exist first, before they can use them.

On paper, this is such a small little difference. It even sounds good... "why, of course we should have to declare conformance to interfaces? What if we accidentally implemented an interface and all hell broke loose? [1]" In reality... it's been a huge mistake.

[1]: My answer to that, BTW: http://www.jerf.org/iri/post/2954

This is of course not to mention the dangers of unintentionally implementing and interface and having bad things happen (this happened in the golang stdlib out of all places as I recall).

Languages like Scala with HKTs or Kotlin with delegates (if I'm not mistaken) solve the issue of delegating to interfaces without much boilerplate. It's just that golang authors have not been exposed to other languages since the 70s.

Not to mention it has sum types and pattern matching, something not available in golang. golang doesn't even have proper enums, quite astounding really.

If Russ Cox ever proposes to rename Go to JavaScript, I guess no one would complain. ;)

Also, Go most definitely has a runtime, what runs the GC otherwise?

That's an awfully restricted definition of "runtime": https://golang.org/src/runtime/

IMHO Go certainly chose wisely when it left out many OOP features of questionable value. And perhaps in doing so, it avoided the whole OOP culture, which has produced a lot of over-complicated software and tools. The culture of simplicity in Go is a really good thing and worth defending. However, we should be open to the idea that one or more additional language features might help to further this goal.

This happened to me too, without using Go. I think I just got older.

Interestingly, what made me go through similar evolution was the very language in which I was trying to do all those things, namely Scala. After a few years of trying to be "smart", I realized that the problem was usually bigger than the language.

So perhaps, it wasn't Go, nor Scala, who helped us in our realization, but life and experience?

Until your users realize that if there was a security vulnerability which was fixed, a system upgrade is not enough. They will have to either hope that you haven't moved on, or build things themselves. But then, thats not a problem with Go specifically, thats a general issue with "static link all things".

Exactly. Which is why I don't get the "static linking is the best solution for deploying applications". You need to be able to do both. For example when building a C/C++ application you can decide if you want shared libs or static builds.

As far as binaries, I think Rust beats it out here too. Take path separators for example. It’s completely possible to have a binary in Go that uses the entirely wrong path separators for the OS. Rust forces you to handle this.

These aren’t true. There is true versioning and no assumption of GitHub. Shouldn’t this be a complaint about the assumption of crates.io?

> No installation-time execution either.

This is also not true. There is no installation-time execution.

No, I _like_ crates.io because Rust is very explicit that that is where the packages come from. We can get into the benefits and risks and whatever about centralized vs decentralized package managers, but that’s not what I’m talking about. I just want to know how Go does what it does so that I can code confidently in it. A lot of Go packages are specified like so:

go get -u github.com/username/repo/version

But this is not enforced (you don’t have to specify a version) and this is also not a valid Git repo path and where exactly is this dependency stored and I can go on and on. When you import this package it’s usually

import “github.com/user/repo/version/module”

But then there is not always a <module> directory in the repo and… you get the idea. This sort of stuff hurts my head and I get it that Go is maybe trying to appear simple but this black box handwavey stuff can and will burn you (this very reason is why the Go community is generally against frameworks) so I just want to have a simple, clear answer and it seems no one else in the Go world has any of these questions. This turns me off.

I’m confused by your last bit. Neither Rust nor Go have installation time execution and this is good. I was referring to how you can’t just say “Oh Node has it and this is bad but Go doesn’t and this is good” because Rust doesn’t have it either.

Re: git, there is no assumption of git. Go also natively supports svn, hg, bzr and fossil. You also have the option to vendor things.

It’s fine to favor crates because it’s closer to what you’re used to, but I think you’re just complaining about ergonomics. They both have semver and implement satisfiability in similar ways (AFAIK).

It seems like the source control mixin is what’s causing the most frustration, and I get it — that’s where you have ergonomics you’re not used to — however, this is also where Go shines since it essentially gives you supply chain integrity without the need to trust any users uploading code (module owners) or third party vendors (crates).

What is the question for which you are looking for a simple, clear answer? Honestly, the documentation is quite excellent [1], but I’m happy to do my best to point to the best place for answers.

[1] https://golang.org/ref/mod

As it should be.

You name any Go package based on a URL you control (and you can refer to any underlying source control by returning appropriate metadata from that URL). Package names that are URL-based is an arbitrary decision, but it seems like it at least solves that problem. Personally I’m much more a fan of that, since otherwise you need to put far too much faith in a single provider (crates), and enable a whole class of attacks and ownership squabbles. Better to just punt this to the already-solved DNS and web ecosystem. I just can’t agree that a single centralized repository is “as it should be”.

Does this hold true? Don’t you need to switch to musl or something, to build a static binary?

So yes, your comment is probably right, but I get the impression the grandparent was a tiny bit tongue in cheek anyway