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

131–140 of 291 posts

Re: Eight years of Go

#131

Post by cube2222 »

terminalcommand wrote: post #105
tetraodonpuffer wrote: post #99

Earlier quoted context omitted.

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

Yes you could, but then you'd have to have both the declaration and the implementation of the interface in the same package. That would mean that if either of them is in a separate file, you'd have to import it. That in return, could easily call hellish compiler errors due to circular dependencies. In Go any circular dependency is an immediate compile error. Looking at the link, the second advice is that you could re…

Sibling comment shows one way to do it, but in most cases, at least for me, which is when both the struct and interface are in the same package it gets solved by the NewMyInterface method.

As it's return type is MyInterface, but it actually returns myStructure which causes the compiler to check the interface satisfying.

Re: Eight years of Go

#132

Post by simon_o »

mfrw wrote: post #88

Simplicity is the Ultimate form of sophistication -- Leonardo da Vinci The quote fits perfectly for the design of go.

Like nil interfaces not being nil.

Or using characters from the Canadian Aboriginal Syllabics unicode block to emulate generics.

Re: Eight years of Go

#133

Post by terminalcommand »

cube2222 wrote: post #122
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…

I actually experienced the opposite. Interfaces in go work so well, partly because you can create an interface which automatically gets satisfied by existing structures. For example I often use a requestDoer interface which only has the http clients "Do" method. I'm using Goland so I have jump to interface from any structure implementing it. So that's another one that gets solved by tooling. The structurally typed in…

How do you jump to the interface from any structure implementing it? Beside from comments there is no immediate way to which interface/interfaces a structure is implementing.

Maybe Gogland solves this by keeping records on all interfaces, and checking all structures whether they satisfy them. If that's the case, this is definitely solved by tooling.

Re: Eight years of Go

#134

Post by nv-vn »

mfrw wrote: post #88

Simplicity is the Ultimate form of sophistication -- Leonardo da Vinci The quote fits perfectly for the design of go.

I think it fits better for Scheme or Forth. I would not describe Go as simple at all relative to those languages.

Re: Eight years of Go

#135

Post by weberc2 »

rifung wrote: post #75
weberc2 wrote: post #53

Earlier quoted context omitted.

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

I write Go at work but have never heard anyone say this. Can you explain why you would prefer no generics to this dumb junior engineer who wants to be enlightened?

To be clear I prefer generics. The cases for why other Go developers don't want generics seem to mostly fall on "it will change the language / encourage people to write stupidly complex code" to "it's too hard to implement". The first one is valid--Go's constraints give it this nice property that there is (more or less) one obvious way to write most programs, and that will go away with generics; however, I think that cost is worth the gain. The other criticism seems like a cop-out; the Go team has far and away more than enough talent to slap generics onto the language.

Re: Eight years of Go

#136

Post by cube2222 »

brian-armstrong wrote: post #110

Go is woefully missing some really key features, which you encounter when tuning it for high performance. My list of grievances: - Dep handling was never considered. Makes sense given Google's monorepo but thats not how the world works. - Stdlib just loosely wraps posix features with many C flags copied verbatim. These APIs are old and could use a refresh but Go never bothered. - No easy way to construct arenas/pools…

Why would you want a supervision tree?

This would suggest using an actor-like model, which is pretty senseless for single-machine usage. It's totally understandable for Erlang, where the VM spans multiple machines, so everything is unreliable, but in Go, I take it for granted, that my goroutines won't "just crash".

I'm not sure, but I think this also ends up being good for modelling interactions with good performance, as you know where you do network calls, where you have reliability, and where you have instant local calls. Though not to say that Erlang applications aren't blazingly fast too.

Re: Eight years of Go

#137

Post by chmln »

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

Go devs who want generics are obviously a minority.

Those who care about generics enough probably just avoid Go and use another language.

Re: Eight years of Go

#138

Post by jackmott »

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…

the guy is just being a dick.

Re: Eight years of Go

#139

Post by cube2222 »

terminalcommand wrote: post #133
cube2222 wrote: post #122

Earlier quoted context omitted.

I actually experienced the opposite. Interfaces in go work so well, partly because you can create an interface which automatically gets satisfied by existing structures. For example I often use a requestDoer interface which only has the http clients "Do" method. I'm using Goland so I have jump to interface from any structure implementing it. So that's another one that gets solved by tooling. The structurally typed in…

How do you jump to the interface from any structure implementing it? Beside from comments there is no immediate way to which interface/interfaces a structure is implementing. Maybe Gogland solves this by keeping records on all interfaces, and checking all structures whether they satisfy them. If that's the case, this is definitely solved by tooling.

That's exactly what it does as far as I know.

EDIT: I can also search for any interface with a struct selected, and generated stubs for all method. Well, basically what you get for any other language when implementing interfaces.

Re: Eight years of Go

#140

Post by sythe2o0 »

terminalcommand wrote: post #133
cube2222 wrote: post #122

Earlier quoted context omitted.

I actually experienced the opposite. Interfaces in go work so well, partly because you can create an interface which automatically gets satisfied by existing structures. For example I often use a requestDoer interface which only has the http clients "Do" method. I'm using Goland so I have jump to interface from any structure implementing it. So that's another one that gets solved by tooling. The structurally typed in…

How do you jump to the interface from any structure implementing it? Beside from comments there is no immediate way to which interface/interfaces a structure is implementing. Maybe Gogland solves this by keeping records on all interfaces, and checking all structures whether they satisfy them. If that's the case, this is definitely solved by tooling.

If you need this, you can write type assertion lines in a var block of the interfaces that you explicitly want to implement (and this will throw compile time errors if they don't).
Post reply on HN