3 ms·

Well, shoot. I don't like/don't want to like Go, but they keep getting better. My general annoyance is that they keep things ~just different enough to be irkso

Well, shoot. I don't like/don't want to like Go, but they keep getting better. My general annoyance is that they keep things ~just different enough to be irksome, e.g. in this proposal generics is using parens: type List(type T) []T Instead of using <> like every other language (okay, I meant Java and C++) with generics: type List<type T> []T (Another example of being ~just different enough to be annoying was switching from C style `int i` to `i int` but then not using colons like `i: int`. And then using type name case for public/private (wtf), so I read variable decls of `foo foo`, which happens all the time in methods that are private implementation details, and my polygot brain interrupts: ...damn, which one is the type again?) As usual, I'm sure `(type T)` vs `<type T>` will be due to "reasons" (...oh, maybe it's that crazy `<-chan` syntax that I dyslexically can never keep straight and wish it was just real type names like `ReadChan[T]` and `WriteChan[T]`), but really I hop languages all day and this makes a big difference to my eyes going back/forth. They should also go back and fix `map[K]V` to be `Map[K, V]`; iirc one of the touted benefits of `gofmt` was to "make automated source code analysis/fixing easy". Great, take advantage of that and get rid of that inconsistency. Same thing with `Chan[string]` instead of `chan string` (both are public types so should be upper case for consistency). It's a major release, just do it. Anyway, disclaimer yeah I'm nit picking and this is what made Guido quit Python. To their credit, Go has great tooling, the go mod in 1.11 finally looks sane, etc. Their continual improvement is impressive.

munificent 8y ago
> Instead of using <> like every other language (okay, I meant Java and C++) with generics Using angle brackets for generics is really annoying when it comes to the grammar of the language. There are nasty edge cases around things like interpreting `>>` as a shift operator in some places but closing two type argument lists in others. There are occasional ambiguities like: foo ( a < b , c > - d) Is this "foo(a < b, c > -d)" or "foo(a<b,c> - d)"? Angle brackets are (alas) more familiar, but they aren't simple. Go seems to place a premium on the latter over the former.
zemo 8y ago
why would you ever not want to like something? liking something is universally better than disliking something.
- dragonwriter 8y ago
  I dunno, arguably, liking things that are bad for you can be worse than disliking them.
enneff 8y ago
The proposed contracts design is quite different to Java and C++'s generics. Why should they use the same syntax? If you want Java and C++ then they are there for you to use. Go is a different language and its differences are not gratuitous. Use it for a while and you'll find out why "i int" works better than "int i" (compare Go's pointer and function type specs to C's).
- stephen 8y ago
  > Why should they use the same syntax? ... Go is a different language True; I harp on Go primarily due to their IMO idiosyncratic approach: AFAIU they claim to be a "purposefully boring", "good for in-the-large" language. (Which is great, I want/like languages like that.) But then they do cute things like the upper/lower case for private, the "method params can be defined `a, b int` because it saves an `int`", the `:=` assignment vs. a standalone `var`/`val` for "hey this is a new variable", not throwing in a ":" for `i: int`, etc., that are all, IMO, very tangential/distracting from their core mission of being a "boring language". So, if they were purposefully trying to be a wildly different language, sure, that's great, I would care a lot less. But it's that they want to be a boring language, and yet are "off" by just enough, that it admittedly frustrates me more than it should.
  - enneff 8y ago
    Those things aren't being "cute". For example, upper/lower case for exported/unexported is a huge readability benefit. You would be less frustrated if you took the time to understand why these decisions were made, instead of pronouncing them arbitrary. Go's designers were long-time C users (longer than anyone else in the world, in fact); they had every reason to stick with the way things worked in C, but they deliberately chose to make Go different.
    - jzoch 8y ago
      uppercase vs lowercase is not a readability benefit. For someone reading the code an explicit 'pub' or other operator is much more readable, as in "I understand the implications of what I am reading". Many people can skim over it without realizing the difference of the var name case.
notriddle 8y ago
I disagree with a lot of Go's design decisions, but avoiding `<>` for generics seems like a very good idea. They're actually learning from other language's mistakes this time. https://github.com/rust-lang/rust/commit/3d5fef6f3001beeffde80b57658809fe383ea242 https://github.com/rust-lang/rust/commit/3d5fef6f3001beeffde...

munificent 8y ago

> Instead of using <> like every other language (okay, I meant Java and C++) with generics Using angle brackets for generics is really annoying when it comes to the grammar of the language. There are nasty edge cases around things like interpreting `>>` as a shift operator in some places but closing two type argument lists in others. There are occasional ambiguities like: foo ( a < b , c > - d) Is this "foo(a < b, c > -d)" or "foo(a<b,c> - d)"? Angle brackets are (alas) more familiar, but they aren't simple. Go seems to place a premium on the latter over the former.

zemo 8y ago

why would you ever not want to like something? liking something is universally better than disliking something.

dragonwriter 8y ago
I dunno, arguably, liking things that are bad for you can be worse than disliking them.

enneff 8y ago

The proposed contracts design is quite different to Java and C++'s generics. Why should they use the same syntax? If you want Java and C++ then they are there for you to use. Go is a different language and its differences are not gratuitous. Use it for a while and you'll find out why "i int" works better than "int i" (compare Go's pointer and function type specs to C's).

stephen 8y ago
> Why should they use the same syntax? ... Go is a different language True; I harp on Go primarily due to their IMO idiosyncratic approach: AFAIU they claim to be a "purposefully boring", "good for in-the-large" language. (Which is great, I want/like languages like that.) But then they do cute things like the upper/lower case for private, the "method params can be defined `a, b int` because it saves an `int`", the `:=` assignment vs. a standalone `var`/`val` for "hey this is a new variable", not throwing in a ":" for `i: int`, etc., that are all, IMO, very tangential/distracting from their core mission of being a "boring language". So, if they were purposefully trying to be a wildly different language, sure, that's great, I would care a lot less. But it's that they want to be a boring language, and yet are "off" by just enough, that it admittedly frustrates me more than it should.
- enneff 8y ago
  Those things aren't being "cute". For example, upper/lower case for exported/unexported is a huge readability benefit. You would be less frustrated if you took the time to understand why these decisions were made, instead of pronouncing them arbitrary. Go's designers were long-time C users (longer than anyone else in the world, in fact); they had every reason to stick with the way things worked in C, but they deliberately chose to make Go different.
  - jzoch 8y ago
    uppercase vs lowercase is not a readability benefit. For someone reading the code an explicit 'pub' or other operator is much more readable, as in "I understand the implications of what I am reading". Many people can skim over it without realizing the difference of the var name case.

notriddle 8y ago

I disagree with a lot of Go's design decisions, but avoiding `<>` for generics seems like a very good idea. They're actually learning from other language's mistakes this time. https://github.com/rust-lang/rust/commit/3d5fef6f3001beeffde80b57658809fe383ea242 https://github.com/rust-lang/rust/commit/3d5fef6f3001beeffde...