Hacker News Reader

Comment by weberc2 | Hacker News Reader

A few thoughts:

1. I don't think powerful abstractions are often that useful. I use Python in my day job, and we mostly don't use many high level abstractions. We never use monads, for example, and while we do use async futures, these are strictly worse than Go's concurrency features.

2. Pretty sure abstraction power drives _less_ consistency, not more. Effectually, it means there are more ways to do the same thing (and more ways to screw it up and make a mess), and consistency depends on organization discipline and less on the rails of the language. I don't mean to say abstraction is bad--only that consistency is one of the costs, not an advantage.

I'm interested to hear your thoughts.

View on HN

> Pretty sure abstraction power drives _less_ consistency, not more.

It depends, I think. Abstractions allow users to specify part of a program's behavior independently from others. This is not intended to start a flamewar or pick on Go, but for better or worse Go does not support user defined generic functions. One consequence is that certain kinds of methods are difficult to write in a generic, performant, and type-safe way. If users want performance and type safety, they need multiple implementations of those methods for each desired type. This leads to multiple copies of very similar code (which can evolve independently, lowering consistency) or the use of on of the community-driven code generators (which all have their own differences, again lowering consistency).

Adding generics could largely make all of this inconsistency go away, but as you point out would enable a whole slew of other programming patterns more ways to make a mess.

I prefer to think of abstraction techniques as shifting consistency. Ideally, they provide an obvious way to factor out one piece of a program's behavior, allowing developers to focus on the rest of the behavior independently.

I largely agree, but I think people generally underestimate the abstractive power of (typesafe) Go and overestimate the cost of its abstractions.

Generally Go's abstractions are based on dynamic dispatch (virtual function calls) which are quite cheap and are the basis for most other languages' abstractions. There are languages like Rust and C++ which offer zero-cost abstractions and generally beat Go in performance and abstraction power, but lose in other ways. If you're comparing Go to Java, C#, Haskell, OCaml, Python, JS, and Ruby, Go performs on par or better.

As far as abstractive power, Go does quite well, although there is still some _boilerplate_ (for loops and closures); however, this is generally not where your bugs come from (certainly not your troublesome bugs) and boilerplate is consistent by definition. I think the biggest reason Go's lack of generics irks people is because they want _terse_ code, because terseness is the most obvious (but least useful) kind of DRYness. The next biggest reason is more legitimate--getting a lot of typesafe abstractive power out of Go requires a different bag of tricks (and a different way of thinking about abstraction) than languages with generics.

> never use monads

I think "powerful abstractions" fall into other categories, e.g. ORMs. While gORM kinda-sorta works in the context of golang limitations, it's missing a lot of stuff that doesn't currently fit into the go model.

Can you elaborate? I can't think of anything in Go that would preclude ORMs. I'm not familiar with gORM, however.

Reply on news.ycombinator.com