Go: Ten years and climbing

Docker and InfluxDB are investor funded organizations that contribute to open source. I'd argue that their success has more to do with the monetary input than anything to do with the language itself.

Go was simply the first language to successfully target the niche of imperative, natively compiled, GCed languages. It wasn't the first language of this kind, but the first to have a reasonable amount of adoption/backing. Whatever other flaws it has or had were trumped by the lack of serious competition in this area.

With Go, you're getting a lot of high-level language features like anonymous functions, while also gaining the control that you're not able to get in higher level languages like Python or Ruby or Java.

I think this works out great for cloud computing, where performance is a major requirement, but the technology is expanding rapidly enough that a step up from C or C++ is very necessary.

A lot of the complaints I hear are related to abstractions, too, and I understand those to an extent. I also think that if you're complaining about the lack of generics, maybe you're not thinking about interfaces correctly. A perfect example is the beautiful simplicity that is the [`io.Reader`](https://medium.com/@matryer/golang-advent-calendar-day-seven...).

So, whenever someone says something like the OP:

> As a simple language to wire pieces together, Golang is fine, but it really doesn't give you the tools (imo) to be productive for anything more complex than simple apps.

I take that as meaning, "I've never seriously used Go beyond writing a hello world app. It doesn't have the features I rely on to be productive, therefore I don't think it's a capable language for larger projects."

I will say though, dependency management in Go is hell. I wish Go had something like Cargo.

You can see the idiot friendly language eclipse in popularity in other domains too even though "better" alternatives exist:

- elegant general purpose: python over ruby

- web: php over python/rails

- SQL databases: MySQL over Postgres

- NoSQL: MongoDB over CouchDB/Postgres

Go's just the first mass appeal language in the concurrency performance domain and it just opened the door to a lot of developers who before wouldn't dare play in the space.

I'd also suggest that an army of experienced devs is more effective than an army of non-experienced "toddlers". Programming languages and CS fundamentals aren't elite, impenetrable cliques; they can be learned.

Depends on what you mean by toddler.

Golang devs imo are not toddlers. The point seemed to be that golang devs could just learn to write C, which is valid. So could Rust developers. But if that was the goal, you'd think both groups would only be using C.

When I think of "toddler" developers, I think of interns being hired into a company to write code with no experience working under mid-level developers that also lack experience, and 5 years later you have what is called f-ing hell. I've worked at a company like that before, and know someone that worked in a company that was mostly VB developers. Same concept but without interns.

The criticism of Go being presented is that it's intentionally underpowered so as to make it possible for poor developers to verbosely muddle their way through to developing working real applications without actually becoming better.

This is a thing that's commonly repeated, but it's not that, well, simple. Having a simple syntax doesn't matter that much for tools once you have a reusable parser library.

More important for tools is having a simple semantics. Do all builtins behave the same way? Is nil handled consistently (e.g. does indexing a nil map do the same thing as indexing a nil slice)? Are the coercion rules simple? Is importing a package free of side effects? (The answer to all of these for Go, unfortunately, is no.)

The most important thing, however, for tooling is whether the language provides static guarantees. For instance, if the language controls access to shared mutable state, you can do a lot to detect races statically. As another example, if panics were part of the type system, then you could statically know whether functions panic and, if so, what types of panics can happen. Here, Go provides very few static guarantees: it's very difficult to soundly prove anything interesting about Go programs.

Unfortunately, you can't really have it both ways: you can have a more dynamic type system that doesn't put many constraints on on programs, or you can have interesting static tooling. Go chose the former in nearly every instance.

The end goal is that the overall software stack should become safer, regardless of what layers one is actually busy with.

The "Go's design and users are dumb" meme needs to die. It's not even a constructive criticism. It's dishonest, insulting, and it's too bad grown adults and professionals can't see beyond it.

I have a lot of respect for Clojure, though I don't have much of a use case for it.

At the time I tried it, I was annoyed its semantics for '() and nil - they're sort of a hybrid between how Common Lisp does it and how Java does it. Which makes sense - the Common Lisp approach would be a nightmare to implement on top of the JVM while maintaining interoperability, but as someone whose primary language before that was Lisp, it was a bit weird to try and get used to.

I love functional programming - before Go, Lisp did pay a number of my bills, after all! - but to me it feels more like art than work. It's fun to figure out the most elegant, Lisp-like way to approach a problem. It's fun to convert an arbitrary task into a language-recognition problem and then write the compiler to recognize that language as the implementation to the solution. I get the same feeling from it that I do when I finish a drawing and stand back to look at it. I don't want to touch it, lest I smudge it - I just want to sit back and appreciate the finished result.

But it's a completely different kind of satisfaction that I get from writing Go - there, the fun is in how quickly I can solve a problem, and how confident I am in the reliability, robustness, and long-term maintainability of my initial effort. That's where Go really shines for me, and it's not like the joy of having created an beautiful work of art. It's more like the satisfaction of having built a solid American Colonial house for yourself to live in.

I like them both, but for my professional work, I'll choose Go every time.

We've had autoformatters before, but they were always customisable things, sparsely used. Go shipping a formatter with the core distribution? Go projects routinely adopting it as a requirement for contributors? One standard format defined from the start?

Knockdown stuff. All those pointless arguments about coding style, gone. All that worrying about how to lay things out, gone. Just run go fmt and move on.

I have now become entirely reliant on rustfmt when I'm writing Rust, and I love it. I just write a total horrible mess, press save and it magically becomes neat and lovely.

I wish I had something that powerful operating in my C# environment at work.

Admittedly, at the moment I also wish my C# environment at work wasn't laden with iron-clad layout rules that the tooling isn't capable of fixing for me. All private members must be after the public ones, but static private ones need to be before the instance ones, and all properties go first regardless of accessibility (although remember the private properties have to go after the public properties). And usings must go inside the namespace definition, in alphabetical order except System.whatever, which all come first (in alphabetical order). And you can't split a function argument across multiple lines unless it's a lambda. Microsoft's C# style guide? What's that and why would we care and no it's not prescriptive enough anyway.

It's enough to make your head spin. Good thing I'm only there for six more days.

Give every language a formatter, as standard, and let's just be done with it.

Nothing from outside the repo can effect that build. Likewise anything inside the repo can’t effect the outside.

Compartmentalizing each project makes builds more reproducible and more obvious. If anyone else clones the same repo and runs the same commands, they should get the same result.

By this metric, the best programming languages are Perl and Fortran.