Hacker News Reader

Comment by nemo1618 | Hacker News Reader

One of the most important qualities of Go is that it is actually possible to fully understand the language -- in the sense that you never see a snippet of Go code and think "wtf, you can do that?" or "hang on, why does that work?"

Getting to that point takes many years, to be sure. But the language is simple enough, and changes slowly enough, that it is not an unrealistic goal -- the way it would be in C++, or Rust, or just about any other mainstream language.

View on HN

Why is that important?

Let's say one language has me find a weird rabbit hole every 50 hours of use, and I spend half an hour learning about it.

Let's say another language has no rabbit holes, but I'm 5% slower at coding in it.

Why would I not prefer the first language?

(And 5% is supposed to be an intentional lowball. I'm confident I can find language pairs where my productivity differs by significantly more.)

That's an odd assumption. That you either have to choose between rabbit holes or development speed. Usually languages with lots of rabbit holes tend to require a lot more work.

Take C++ vs Go for instance. C++ is an endless series of deep, complex rabbit holes where you get enough rope to hang not only yourself but your entire team. Serious C++ projects tend to require a style guide for either the company (most companies don't have that kind of discipline) or at least some consensus of what subset of the language to use and how to structure problems for a particular project. Look at the guides Google use or the Joint Strike Fighter. They're massive. C++ is not a particularly fast language to develop quality code in unless you have a small team and/or you are supremely well aligned and disciplined. And even when you work on a disciplined team, it takes time.

Go has fewer rabbit holes. It gives you an easier path to concurrency. It has managed memory. It is sufficiently performant for a very wide range of projects. It has a very capable and practically oriented standard library that even includes HTTP, cryptography, support for some common formats and a decent networking abstraction that actually allows you design flexibility. And importantly: it comes with a shared code style which is tooling enforced, so you don't have to waste time on mediating between various opinionated hothead programmers on your project.

Because not all code is yours. In a team, the time spent on “rabbit holes” adds up, increasing the risk of bugs. A `slower` but predictable language can lead to more consistent, maintainable code, which is often more valuable in the long run or last but not least, running in production.

> In a team, the time spent on “rabbit holes” adds up, increasing the risk of bugs.

It adds up with the number of people on the team? Or the number of people on the team squared? Cubed? nlogn? Because a lot of those options would still favor the former language.

And if it's happening particularly often, that means the rate will fall off drastically as mastery is achieved.

I see a risk when code does something different from expectations. I don't see any risk when code has some kind of novel syntax that requires looking it up. Or when you learn about a feature from the documentation or a blog post.

Being predictable is quite valuable, but predictability is different from memorizing every feature.

This is similar to the experience that I had with Erlang. After having spent time with it, I was hardly every surprised looking at any code and my brain could deal with the actual problems at hand without having to figure out how to apply what I knew about the language.

Personally my biggest issue with reading go code has come from the //go: magic comments that I never seem to fully understand.

For example, what the heck is a //go:cgo_import_dynamic? As far as I can tell this is only documented on GitHub issues and mailing list comments.

It's in the cgo docs: https://go.dev/src/cmd/cgo/doc.go#L880

Hmm, where's the rendered html doc for this?

I don't see it on https://pkg.go.dev/cmd/cgo

I've been doing Go for a long time now and I still occasionally come across snippets of code that I don't understand or understand the purpose of. So I think "never" is too strong a word. I'd say "rarely" rather than "never".

> in the sense that you never see a snippet of Go code and think "wtf, you can do that?" or "hang on, why does that work?"

I am extremely doubtful that this is true and would like evidence.

kind of hard for someone to prove a negative - feel free to find some Go code that meets that definition.

I feel this way... very often.

* Init functions

* Top-level variables being shared between all files in a package

* For-loop sharing (fixed in 1.22 [0])

* ldflags (this is more of build behavior, but it took me a while to figure out how some variables were being set [1]. Note: Go does embed some data by default, but an app I was working on introduced more metadata)

* Go build directives prevent IDEs/linters from analyzing a file at all. E.g. if you edit a linux-only file on macOS, you get _zero_ help.

I dunno, there are a lot of other weird, confusing things that Go does. It is less than most other languages, though.

[0] https://go.dev/wiki/LoopvarExperiment

[1] https://www.digitalocean.com/community/tutorials/using-ldfla...

Needing to cast nil to a type was weird. C/C++/Java/Python don't do that.

They also take on the weird Java-ish culture that everything is better if it's written in Go.

They also had this weird take on the C++ vtable, so they eschewed anything class like to keep everything statically linked for speed.

It also took them a long time to figure out their loop variable syntax was broken. So ... hrm.

C++ and Java do make you cast null/nullptr, if you need to resolve an ambiguous overload based on pointer type.

First three are clearly documented in language reference, which could be read in several hours (at least before generics were introduced).

You're misunderstanding what I'm saying. How the language works is relatively simple. Understanding what's going on when problems arise isn't.

* "how is my Cobra command being registered when I'm not calling any code?" -> "oh, there's an init function that registers the command when imported"

* "why is this variable not working?" -> "oh, it's that for loop thing again"

* "why does the result of my unit tests depend on the order of test execution?" -> "oh, we have 150 Cobra commands in one package with variables shared between _all_ of those commands"

* "how is this variable being set?" -> "oh, we have to call go build with a monstrous ldflags argument

* "why is CI not passing for this oneliner when this looked fine locally?" -> "oh, it's a linux-only file so the IDE isn't even showing me simple syntax errors"

I like to read language references (not just Go's, for example I have also fully read the ECMAScript standard as a part of my research in the past) and yet I will never say I can remember everything from those references. "Documented" isn't same as "easy to remember or recall".

I looked around for something like CppQuiz or its Rust analogue, where you're presented puzzling "Why would anybody do that?" fragments and asked what happens -- something that's often extremely difficult. If I had found one of those for Golang I could maybe see whether there are people who just ace the quiz first time.

But what I found were the sort of softball "Is Go Awesome, Brilliant, Cool or all of the above?" type questions, or maybe some easy syntax that you'd see in day 1. So I have no evidence whether in fact many, some or even a few Go programmers have this deep comprehensive understanding.

It's known for being a small and simple language.

Just like Brainfuck.

Reply on news.ycombinator.com