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

91–100 of 291 posts

Re: Eight years of Go

#91

Post by asavinov »

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

> ... while paying much less attention to the vocal minority's complaints (generics, package system, etc).

It is much more difficult not to add a feature than to add it, and the ability to reject even important feature requests is very important for the survival of a system in long term. This observation is formulated in "Getting Real" (https://gettingreal.37signals.com) as "Forget Feature Requests" and "Start With No".

Re: Eight years of Go

#92

Post by shurcooL »

oconnor663 wrote: post #43
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)…

What's the connection between `defer` and goroutines?

Not a strong connection, but both features are managed by the Go runtime.

Re: Eight years of Go

#93

Post by LanceH »

dekhn wrote: post #38
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).

Complaints about generics aren't coming from a minority group. It's a majority now.

The majority may want generics.

I don't know that the majority want generics at the expense of compile times or other possible tradeoffs.

Re: Eight years of Go

#94

Post by freyir »

pmoriarty wrote: post #55
wheaties wrote: post #44

Earlier quoted context omitted.

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

Bold choice.

Re: Eight years of Go

#95

Post by TheOtherHobbes »

nine_k wrote: post #42
krylon wrote: post #30

Earlier quoted context omitted.

You are not wrong. But I think there is more to it. I have used Go (almost) exclusively for private toy programs I write in my free time to relax (sounds weird, I know), so my perspective may be warped. But something about is very compatible with the way my mind works. With some other languages, say C or C#, I find myself constantly browsing through documentation to figure out what a given construct means in that lan…

Go does have brilliant simplicity! It's the simplicity of Pascal I used in middle school, and of Modula-2 I used on my freshman year, with basically the same syntax. I'm glad Go revived a number of good ideas from Pascal / Modula / Oberon. For writing toy programs to relax (can relate), I personally prefer Python, or maybe a Scheme. While also being simple at the core concepts, they have much more expressive power, a…

Go has human-sized simplicity. Programming language complexity is limited by human cognitive limitations, and Go has a small cognitive load.

This makes it feel like a very intuitive language.

That doesn't mean it is an intuitive language - just that it feels like one for a specific class of problems.

Personally I enjoy using it for the same reasons as everyone else. But... I'm also aware it's quite an old-fashioned language, with some bumps under the floorboards where useful things were hammered down to make them go away, instead of being fully solved.

Re: Eight years of Go

#96

Post by krylon »

terminalcommand wrote: post #90
tetraodonpuffer wrote: post #78

Earlier quoted context omitted.

> my intuition what I think a given piece of code should mean is nearly always in line with the language specification. for some things yes, but for others I think that it's more familiarity than intuition, take for example interface slices, you start by learning that you can assign any type to interface{}, so intuitively you'd think that you could assign any type slice to []interface{} but you find out soon enough t…

IMO interfaces are the Achilles' heel of Golang. Another thing that has been bugging me about them is that you cannot specify which interface you're implementing in the code (beside from comments). I think that is so because Go hates circular imports. If you had to import a file to be able to use an interface, you'd soon run into compile errors due to circular dependencies. And as there is no way to immediately see w…

It would be nice to add at least the options to explicitly state that type X should implement interface I, and have the compiler barf / emit an error if X does not implement Y.

Like I said before, this has not been enough of a problem to really bother me, but I would be quite happy if Go fixed this.

Re: Eight years of Go

#97

Post by camus2 »

oconnor663 wrote: post #43
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)…

What's the connection between `defer` and goroutines?

None, the feature that completely depends on defer is recovering from panics.

The order in which defer statements are executed is predictable, unlike goroutines.

Re: Eight years of Go

#98

Post by erik_seaberg »

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.

That's easy. Concurrent access to maps is unsafe. https://golang.org/pkg/sync/#Map should be a drop-in replacement but due to the lack of generics it can't present a compatible or typesafe API.

Re: Eight years of Go

#99

Post by tetraodonpuffer »

krylon wrote: post #96
terminalcommand wrote: post #90

Earlier quoted context omitted.

IMO interfaces are the Achilles' heel of Golang. Another thing that has been bugging me about them is that you cannot specify which interface you're implementing in the code (beside from comments). I think that is so because Go hates circular imports. If you had to import a file to be able to use an interface, you'd soon run into compile errors due to circular dependencies. And as there is no way to immediately see w…

It would be nice to add at least the options to explicitly state that type X should implement interface I, and have the compiler barf / emit an error if X does not implement Y. Like I said before, this has not been enough of a problem to really bother me, but I would be quite happy if Go fixed this.

can't you simply do this (from [1]) somewhere in your code to enforce?

    type T struct{}
    var _ I = T{}       // Verify that T implements I.
    var _ I = (*T)(nil) // Verify that *T implements I.
[1] https://golang.org/doc/faq#guarantee_satisfies_interface

Re: Eight years of Go

#100

Post by gcgggfxsdg »

hood_syntax wrote: post #13
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).

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.

> My original tone was a bit nasty in retrospect

Why are you backpedaling? Are you afraid of getting banned?

Look, if it’s bollocks it’s bollocks, call it like it is.

Post reply on HN