Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.



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.


> I definitely prefer public private over case defined visibility.

And I think `public` and `private` keywords are a verbose mess that adds nothing to a language.

> You can't use an array for different types.

Yes I can. I even provided an example for exactly that: `[4]any` can hold references to any type.

> Matching _is_ useful

A lot of things are useful, doesn't mean they are used for that useful case most of the time.

> You can have explicit forced AND exhaustive error handling without exceptions

Go has wrapped and typed errors, covering exactly that.


> Yes I can. I even provided an example for exactly that: `[4]any` can hold references to any type.

And now you've lost type checking. `(&'static str, bool, u64, f64)` is not the same as `[4]any`.

> A lot of things are useful, doesn't mean they are used for that useful case most of the time.

I'm sure you have vast insights into what most people do most of the time.

> Go has wrapped and typed errors, covering exactly that.

Sure, "Go has X because it gives you the tools to reimplement it yourself another way" is true of most anything you can think of.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: