Hacker News Reader

Comment by btilly | Hacker News Reader

I would imagine that Go’s GC is worse than the tunable JVM ones, but go isn’t powerful enough that one would ever be tempted to program in an abstraction heavy style.

That is a compliment.

One of the design criteria for Go was to push programmers away from being architecture astronauts whose abstraction heavy style results in having no idea how much work you are hiding in all of the layers. And that design criteria was based on analysis of the actual failure modes of significant software projects.

Therefore the fact that real world Go apps generally manage to avoid that failure more is a testament that they succeeded in this design criteria.

View on HN

Generics are architecture astronomy?

This is parroting anti-intellectual nonsense.

Generics as done in C++ templates lend themselves to that.

Inheritance as done in most OO systems does likewise.

You will note that the core Go team has a desire to add generics. However they also feel that it is a potential Pandora's box.

C++ templates are not the gold standard of generics. In fact, they are a glorified text substitution system, totally broken and flawed.

Generics are still absolutely necessary for ANY serious programming language. They are required by the DRY principle. Algorithms must not need be repeatedly implemented for every new data structure. To say that generics are astronaut is simply unprofessional.

Interestingly though, some of the worst excesses of overdesigned architectures in Java happened before Java even had generics, and heavy use of interfaces was a standout feature.

So Go has absolutely everything a true architecture astronaut needs. In my view, the big difference is cultural and has nothing to do with language features.

Also, the lack of generics often forces you to use reflection to avoid code duplication, which makes for very complex, error prone code.

As an example consider the sort package in Go's standard library. Here's what they had to write in order to generically swap two elements in a []interface{}:

https://golang.org/src/internal/reflectlite/swapper.go

I suspect a problem with Java is it's culture and ecosystem evolved in the early 90's when memory, disk, and processor speeds were doubling every few months.

Go in the late 2000s after Amdahl's law had been bitch slapping everyone for 10 years. Network bandwidth increased but laterncy didn't. Processor transistor counts increased but clock speeds didn't. Memory increased but memory bandwidth didn't keep up.

>One of the design criteria for Go was to push programmers away from being architecture astronauts whose abstraction heavy style results in having no idea how much work you are hiding in all of the layers.

So they chose to create a language where there's no way to get around creating vast amounts of boilerplate. This boilerplate heavy code style results in having no idea of the true logic you are hiding in all of the boilerplate.

Reply on news.ycombinator.com