[ddoolin]

I've only written a handful of production projects in Go so my experience isn't very deep, but I find the syntax to be the ugliest of any PL. The mixed capitalizing based on function privacy, to me, is awful (among other things, i.e. personally I loathe curly brace initialization/definition). I'm sure you get used to it? It doesn't help that it just feels very hacked together, from the wonky generics, the lack of useful types like tuples and enums, the bolted on module system, to the annoying error handling, to say the least.

That said, compile times are great, the concurrency is dead simple, it's performant, and it's still easy to be really productive in it so it's not like I'd never consider it. Many other languages have many of the same issues, anyway.

[usrbinbash]

> The mixed capitalizing based on function privacy, to me, is awful

Awful compared to ... what? `private` and `public` keywords? Ugly hacks like pythons `_` and `__`?

> it just feels very hacked together

> the wonky generics

What exactly about the generics is "wonky"? "Wonky" is not a term defined in any programming textbook I ever read. And languages are not designed on feelings, especially when the design goal is to be as pragmatic as possible, as is the case in Go.

> the lack of useful types like tuples and enums,

Need a tuple? Use an array and don't change it.

  - [2]string: string 2-tuple
  - [5]int: int 5-tuple
  - [1]any: empty-interface 1-tuple

And btw. 99% of the time tuples are used, it's as a stand-in for multiple-returns. E.g. Python does that. Go simply has...multiple returns.

> and enums,

Outside of language-enthusiasm with matching and whatnot (which more often than not is used because it looks cool rather than being useful), the most common (and again, 99%) use of enums, is to give names to magic values. Go has that covered:

    type Color string
    const (
      RED Color = iota
      GREEN
      BLUE
    )

> the bolted on module system

Pray tell what exactly is "bolted on" about modules? They are simply an extension of the import system, nothing more, nothing less.

> the annoying error handling

The "annoying" thing about it is that it's explicit and forced. Both of which are positives as far as I'm concerned, because I AM FREKKIN DONE with shitty 10-mile stacktraces because some joksters library threw an "exception" 400 layers down in some sub-sub-sub-sub transient dependency lib.

[eddd-ddde]

I definitely prefer public private over case defined visibility.

You can't use an array for different types.

Matching _is_ useful, no one uses matching just because it looks "cool".

You can have explicit forced AND exhaustive error handling without exceptions. Go actually lacks this.