7 ms·

This sounds like tooling and formatting consistency versus abstraction consistency. Go isn't great for building powerful abstractions, so at a higher level impl

by Felz 8y ago

This sounds like tooling and formatting consistency versus abstraction consistency. Go isn't great for building powerful abstractions, so at a higher level implementations will trend towards inconsistency, however consistent the low level syntax.

gcb0 8y ago
in other words, it's consistent if you only look at it for a few minutes. use it for anything and it become an inconsistent mess.
- kerng 8y ago
  Been trying it out and agree. I like it a lot for simple, stand alone tools. For more complex ones it appears strangely ill-suited and "messy".
jonathanstrange 8y ago
As if powerful abstractions lead to more consistency...
weberc2 8y ago
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.
- zeugmasyllepsis 8y ago
  > 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.
  - weberc2 8y ago
    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.
- bpicolo 8y ago
  > 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.
  - weberc2 8y ago
    Can you elaborate? I can't think of anything in Go that would preclude ORMs. I'm not familiar with gORM, however.
the_clarence 8y ago
You mean 50 layers of abstraction?

by Felz 8y ago

gcb0 8y ago

in other words, it's consistent if you only look at it for a few minutes. use it for anything and it become an inconsistent mess.

kerng 8y ago
Been trying it out and agree. I like it a lot for simple, stand alone tools. For more complex ones it appears strangely ill-suited and "messy".

jonathanstrange 8y ago

As if powerful abstractions lead to more consistency...

weberc2 8y ago

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.

zeugmasyllepsis 8y ago
> 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.
- weberc2 8y ago
  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.
bpicolo 8y ago
> 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.
- weberc2 8y ago
  Can you elaborate? I can't think of anything in Go that would preclude ORMs. I'm not familiar with gORM, however.

the_clarence 8y ago

You mean 50 layers of abstraction?