I wonder if in the future it's possible to incorporate GraphQL syntax in Golang 🤔 (or at least import GQL schema)

Interesting overview!

---

While having a garbage collector is kind of standard, the Go one is a bit special.

Most languages with GC, like Java, are focused on reference types. But Go could I think be fairly described as value-oriented, like C.

That is, rather than most variables being pointers to separate objects, they are stored directly inside eachother and on the stack by default.

This apparently had some interesting effects on the design of the garbage collector.

---

Another special thing, and arguably one of the most famous, are the goroutines.

Many languages now use async/await for IO and real threads for parallel computations. There are no multiple stacks, and context switches are explicit (or kinda in Kotlin).

Erlang has a somewhat similar system, also with growable stacks. But they behave more like processes (no data sharing), and they are pre-emptive (they can switch at any time).

Java and Rust abandoned green threads, which would be kind of similar. I'm not sure which other languages have something like it built-in.

So I think Goroutines are kind of special. They only switch at specific points (when blocking waiting for IO or channels, usually) which is like async/await. This is often more efficient than pre-emptive.

But unlike async/await, there are no async or await keywords. If your function can yield execution, the callers won't know about that. Which related to their implementation as actual stacks, instead of just compiler magic. On the one hand, it means less syntax is needed (marking all functions as async), but it also means you don't really know when you're going to be interrupted and your state changes, just like real threads.

---

That said, to my taste Go is too spartan. I get how it follows from their goals, but I think the simplicity is mostly nice in the first half year. After that you'd be happy to have generics and other features that help you write more reusable and reliable code.

Nice post! One thing though: your post is 100% feature oriented. And there’s one «feature» of Go which I don’t find here which is - in my opinion - one of its greatest strength, although it’s a non-functional one: When the design - and keep designing - the language designers were/are very careful to not introduce duplicated functionalities (i.e. they try to only provide one way to do one thing). This is why Go is simple: since there’s only one way to do things, all Go code looks pretty similar (and this is also enforced with other great Golang strengths: the tooling and gofmt)

When you work in a team, having something super consistent makes it much easier to maintain. The cognitive load when you look at the code from someone else is hardly greater than looking at your own code. When you need to develop stuff and make sure it will be developed, maintain and debugged by many developers, this very strong consistency has a huge value!

Nice article! As someone who has done object orientation for a decade now, I really can say, OO is needlessly complex. Go is quite simple, and simple is good.

Interesting post! Have bookmarked it. :-)

Could you tag it with Golang so that more people see this in their feeds? The current tags seem incorrect.

Please choose "Go Language" tag from the above dropdown in the edit page. :)