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

141–150 of 291 posts

Re: Eight years of Go

#141

Post by [deleted] »

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.

[deleted]

Re: Eight years of Go

#142

Post by [deleted] »

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.

[deleted]

Re: Eight years of Go

#143

Post by masklinn »

cannam wrote: post #121
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…

> - No supervision tree. Erlang existed far before Go but they didn't learn from this key feature. But it would greatly enhance Go to have it This is the one thing in your list that I don't recognise. What is a supervision tree? Can you (or another Erlang programmer) point to your favourite reference?

A supervision tree would be a tree of goroutines where a "master" (supervisor) gets notified when children die (normally and more importantly abnormally).

In Go, if a goroutine panics for some reason it just dies on its own and the world does not know unless you have some sort of ping service or you specifically send a notification from a defer.

In Erlang, if a process faults and it has a supervisor, the supervisor gets a message that one of its children died with some additional metadata, it can then log the issue, restart a child, … This also led to an interesting "let it crash" philosophy (since Erlang processes have isolated private heaps a process dying also cleans up any potential data corruption in the process's private state, this is often considered a feature, but at its core it mostly avoids processes dying unnoticed.

Incidentally, supervision is actually the result of two individual features: linking and trapping. Linking means that when one process dies with an abnormal status (any reason other than regular process exit), all process linked to it will also die (the EXIT signal gets propagated through the link), which is repeated until all linked processes are killed, trapping lets a process handle the incoming exit signal in code rather than automatically suicide

Finally, because supervisors and supervision trees are so common the Erlang standard library provides generic behaviours which let developers declaratively set up which strategies they want in their supervisor, the maximum restart frequency (beyond which the supervisor consider the system's broken and shuts down), ...

Re: Eight years of Go

#144

Post by erik_seaberg »

jopsen wrote: post #101
Silfen wrote: post #35

Earlier quoted context omitted.

My concern is less about writing a bunch of separate functions, but rather the way this hampers the abstractions that are available to you everywhere in the language. You don't have map or fold! And that's only the very tip of the iceberg.

Yeah, I wish go had more functional stuff, like .map(), .filter(), etc. On the other hand I enjoy that when I pickup a package someone wrote there is not a bunch of different meta-programming using templates. Generics sometimes lead people (including myself) to over-engineer solutions... usually because we want as much compile safety as possible. But at what cost in complexity.

I'd rather read x.filter().map() than read the loops someone had to expand them into by hand.

Re: Eight years of Go

#145

Post by pjmlp »

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…

> I'm glad Go revived a number of good ideas from Pascal / Modula / Oberon.

Sadly it feels more like Oberon-07 than Modula-2, feature wise.

Re: Eight years of Go

#146

Post by _seemethere »

majewsky wrote: post #115
shkkmo wrote: post #62

Go's biggest issues still seems to be the lack of a standard mature dependency management system.

I don't know why people are so upset about this. Go standardizes enough things about imports and package structure that you can completely solve dependency management in literally a shell script: https://github.com/holocm/golangvend (I'm using this productively for the Go apps that I develop at work).

the issue becomes that there are so many solutions out there that going from project to project becomes a pain.

Large projects use a litany of different tools like glide, dep, godeps, vndr, govendor, etc. that managing all of them is a pain.

What makes it worse is that Golang's official solution seems half-baked when compared with other solutions out there.

Re: Eight years of Go

#147

Post by pjmlp »

nine_k wrote: post #28
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.

Apparently, the project leaders see it as a lower-priority (though not unimportant) issue. Looking at the adoption figures, they seem to be right. I personally stay away from Go due to lack of generics and other expressiveness issues. People who have to work with it write code generators on top of the compiler, because the compiler team won't include it into the language. (I can see how it's not an easy thing to do;…

> Looking at the adoption figures, they seem to be right.

Not really, for me Go is a bit like JavaScript.

I have to deal with Go thanks to Docker and K8s, doesn't mean I would use it when given the option.

Re: Eight years of Go

#148

Post by pjmlp »

chmln wrote: post #137
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.

If only we could avoid Docker and K8S in the process.

Re: Eight years of Go

#149

Post by donatj »

tetraodonpuffer wrote: post #78
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…

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

> intuitively you'd think that you could assign any type slice to []interface{} but you find out soon enough that doesn't work

I've been writing Go for upwards of six years, professionally for three, and I have never tried that. I can't think of the last time I used interface{}...

I generally consider anything using interface{} crap code someone who doesn't know the language wrote, probably coming from a loosely typed language.

Re: Eight years of Go

#150

Post by ori_b »

pcwalton wrote: post #117
ori_b wrote: post #103

Earlier quoted context omitted.

But this is something you often need to do for any non-trivial type, even with generics. There's a reason that C++ std::sort takes a comparator, or why Rust requires you to implement the 'Ord' interface. Again, it's a little clunkier in Go, but not unusably so.

You need to define how to order things in other languages (though not in languages where you can automatically derive implementations like Haskell or languages with built-in polymorphic comparison like OCaml) but you don't need to define how to swap elements over and over.

Yes, I'm aware. That's the clunky part that I was referring to (although, you can still avoid it for slices, and simply pass a single compare function.)

Go is far from my favorite language, but the sheer amount of bad criticism by people that clearly don't use the language annoys me.

Post reply on HN