Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Eight years of Go

blog.golang.org

Post reply on HN
Print view View original

51–60 of 291 posts

Re: Eight years of Go

#51

Post by kmicklas »

theshrike79 wrote: post #47
rdsubhas wrote: post #41

Earlier quoted context omitted.

I'm not sure what you mean by vocal minority's complaints. Golang generics is the second most voted issue on GitHub itself: https://github.com/issues?q=is%3Aopen+is%3Aissue+sort%3Areac... (I'm not sure if GitHub sorting is broken, but the same issue has more +1s than the top +1d issue as per that sort mode as well) Generics has the most experience reports in Go 2 proposal. Maybe this can be categorized and excluded a…

They haven't said "No" to generics. What the developers want is for people to submit _actual_ problems that generics would solve, with examples. Because there are more than a few way to do it and they want to pick the right one.

It's simply astounding that the Google engineers working on Go lack the imagination to understand what problems generics would solve.

Re: Eight years of Go

#52

Post by z0r »

tree_of_item wrote: post #18
kown223 wrote: post #15

Earlier quoted context omitted.

how often do you sort? most of the time you would do a database ORDER BY instead.

I...I can't even believe you just said that. Go really does have a unique core audience.

more like tree_of_interface{}

interfaces are a poor substitute for generics, but that's by design. the minute they add a reasonable implementation of generics Go will begin to metastatize into something unrecognizable as people will no longer be bound by the limitations of the already existing core generic types. the core developers really do not want that to happen.

it's a highly opinionated language and for some reason some people enjoy writing mountains of for loops so that their code can remain "simple" as they produce a maze of twisty funcs all alike. i mostly see a for loop or two per func with a map and some slices repeating the same patterns over and over. that's the way the language designers want it.

i work with a lot of go programmers and they are all fine and good programmers. that makes it even harder to understand why they enjoy all the boilerplate and even defend it.

Re: Eight years of Go

#53

Post by weberc2 »

Gys wrote: post #20
hood_syntax wrote: post #13

Earlier quoted context omitted.

Are the complaints about lack of generics really a minority thing? Writing separate functions to sort different types just strikes me as ridiculous. EDIT: My original tone was a bit nasty in retrospect. Did a little research and while I still am on the generics side, the current situation seems at least workable for a good number of use cases.

Assuming developers are rational in their choices, by far most of the Go developers still prefer to use the language without generics. I think its just a minor problem compared to all benefits.

> by far most of the Go developers still prefer to use the language without generics

I've been writing Go regularly for at least 5 years, and my guess is that at most 60% of Go developers prefer no generics. I also think that number is climbing.

Re: Eight years of Go

#54

Post by kmicklas »

Gys wrote: post #20
hood_syntax wrote: post #13

Earlier quoted context omitted.

Are the complaints about lack of generics really a minority thing? Writing separate functions to sort different types just strikes me as ridiculous. EDIT: My original tone was a bit nasty in retrospect. Did a little research and while I still am on the generics side, the current situation seems at least workable for a good number of use cases.

Assuming developers are rational in their choices, by far most of the Go developers still prefer to use the language without generics. I think its just a minor problem compared to all benefits.

This level of myopia from Go developers is why it gets so much flack.

Re: Eight years of Go

#55

Post by pmoriarty »

wheaties wrote: post #44
noncoml wrote: post #2

Things I love about go: 1. Probably the best ecosystem out there. 2. Go routines 3. (Enabled by (2) actually) `defer` 4. That I can add interfaces implementations to structs I don’t own 5. No exceptions. Actually (5) is one of the few things I don’t like about Haskell. If Go had ADTs and generics it would easily be my favorite language. Edit: and of course the channels. Edit2: yeah, i have no idea why i connected (2)…

The best ecosystem out there? Since when? I'd say that Java and Python have huge, wonderful and full ecosystems. Golang doesn't even come close to that, yet. Furthermore, Golang doesn't even have a community standard (or several standards) dependency manager.

Python's packaging is a nightmare of half-baked, incompatible approaches that puts the lie to the famous "Zen of Python" that "There should be one-- and preferably only one --obvious way to do it."

Re: Eight years of Go

#56

Post by weberc2 »

hellofunk wrote: post #9

I find myself wondering how important the "fun facts" are in this fascinating thread about Go: https://twitter.com/pasiphae_goals/status/923820615022399488

They're not important. The author admitted she was just shitposting. It was an amusing thread, but rife with misinformation. If someone wanted valid criticisms of Go, I would not send them there.

Re: Eight years of Go

#57

Post by dualogy »

noncoml wrote: post #2

Things I love about go: 1. Probably the best ecosystem out there. 2. Go routines 3. (Enabled by (2) actually) `defer` 4. That I can add interfaces implementations to structs I don’t own 5. No exceptions. Actually (5) is one of the few things I don’t like about Haskell. If Go had ADTs and generics it would easily be my favorite language. Edit: and of course the channels. Edit2: yeah, i have no idea why i connected (2)…

> If Go had ADTs

In the process of hacking on my PureScript2Golang "transcompiler", I've realized that under the hood ADTs, also known as "tagged unions", will likely more often than not be represented exactly as just that: a "tag flag" and a data pointer. (Of course if all of an ADT's ctors are nullary, an enumish int will do the trick just as well --- I doubt this gains anything over interface{}-boxed 0-size struct type-defs though in reality.)

Now the natural "box"/container for this tag+content pattern in Go is the `interface{}` that can hold as 'content' any of your "constructors" (whether it be a struct or type-alias or prim type), plus your 'tag' pattern-matchings translate to Go's type-assertions. You see this also whenever ADTs are translated to JS or OOP languages, in some manner the "type" tag is carried along to be able to switch-case on.

Anyway, you can do poor-man's ADTs as per above today. The catch is that you get fewer compile-time checks (won't check for pattern exhaustiveness in your switch-cases, or illegal/impossible/invalid (as per your custom "dumb" ADT layouts) type assertions).

But anyone who's done some linked lists or devised parser ASTs in Go has written "ADTs" in this manner --- whether by intention or inadvertently =)

Personally, I don't care about Generics now that I'm aiming to generate low-level Go code for PureScript's parametric polymorphism and higher-kinded types system.. --- expressive beyond the old-school oop/imperative "generics" band-aid ;)

> That I can add interfaces implementations to structs I don’t own

Wait, did I miss out on some new feature only recently introduced? The way I parse your above statement, it sounds like you could define methods for receiver types imported from other packages, is that what you meant? Or did you simply have classical workarounds in mind, such as type-aliasing or set-the-"method"-as-a-struct's-func-typed-field?

Re: Eight years of Go

#58

Post by nine_k »

rdsubhas wrote: post #41
nine_k wrote: post #7

Go is an example of how to be extremely successful by catering to the needs of the project's core audience (well-rounded stdlib, extremely fast GC, short build times, trivial deployment, etc) while paying much less attention to the vocal minority's complaints (generics, package system, etc).

I'm not sure what you mean by vocal minority's complaints. Golang generics is the second most voted issue on GitHub itself: https://github.com/issues?q=is%3Aopen+is%3Aissue+sort%3Areac... (I'm not sure if GitHub sorting is broken, but the same issue has more +1s than the top +1d issue as per that sort mode as well) Generics has the most experience reports in Go 2 proposal. Maybe this can be categorized and excluded a…

I'm afraid not all votes are (and should be) considered equal by the project maintainers. A great number of casual Go users might want feature XYZ. OTOH a couple dozen of large Go projects, with combined millions MLOCs and hundreds of millions of end users, may have a different list of priorities, and these priorities might be catered first.

Also, let's not forget that Go is created at Google, and definitely Google's internal projects, likely large-scale by both line count and users served metrics, must take priority.

Frankly, there is a number of reasonably nice languages that do provide generics, good / great type systems, good / great package management, decent async features, and quite decent performance: Rust, Nim, Crystal, ... all the way down to Haskell. Go is not competing with them at their strongest features. Instead, it's in the sweet spot of simplicity, fast build times, reasonable hygiene, and trivial deployment. It's the "getting job done" mentality which worked so well for PHP and Perl back in the day. There is a considerable demand for that.

Re: Eight years of Go

#59

Post by weberc2 »

stablemap wrote: post #3

A post earlier this year by Rob Pike, celebrating ten years of Go: https://commandcenter.blogspot.com/2017/09/go-ten-years-and-...

This blog post is 8 years since Go was an open source project. Rob's post was probably something like "10 years since we began work on Go".

Re: Eight years of Go

#60

Post by pcwalton »

nine_k wrote: post #14
solox3 wrote: post #4

Earlier quoted context omitted.

Novice here. Why is having no exceptions a good thing, in your opinion?

For exceptional, unforeseen situations you do have exceptions, aka "panic". For signaling error conditions that the caller has to expect and handle, you have the `result, err = func(...)` idiom, and a compiler that would warn you if you forget to use the value of `err`. If Rob Pike's opinion on this is not enough, here's Martin Fowler saying essentially the same thing: https://martinfowler.com/articles/replaceThrowWi…

Go does not warn you if you forget to handle an error. It only does so if the function in question also returned a value that you're using. There exist important functions that don't return non-error values and report errors that you very much would like to avoid dropping on the floor: os.Chdir() for example.
Post reply on HN