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

201–210 of 291 posts

Re: Eight years of Go

#201

Post by dansouzaio »

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…

> And as there is no way to immediately see where some interface is declared and if/which interface is implemented

you can use go-oracle (https://camo.githubusercontent.com/3fb1d62bbc7b1306da783f395... that!

Re: Eight years of Go

#202

Post by nine_k »

pjmlp wrote: post #147
nine_k wrote: post #28

Earlier quoted context omitted.

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.

Would you rather have them use C++? In this regard, Go is a lesser evil.

Re: Eight years of Go

#203

Post by dansouzaio »

sanderjd wrote: post #167
misframer wrote: post #24

Earlier quoted context omitted.

I've been using Go at work and for my personal projects for over 4.5 years. I rarely have to sort. It's not a big deal for me.

It's not about sorting, it's about every single abstract operation on a collection or other type of container. You either have to use primitives, or reimplement everything yourself on each new type. Most people just use primitives. This proliferation of primitives is what I actually dislike about reading and writing code in Go, but it's caused by not having a way to define abstract data types that work well.

There are a few good templating (gengen, genny, etc) solutions for generics in Go, but yeah, it would be nice if it was baked into the language.

Re: Eight years of Go

#204

Post by dansouzaio »

nine_k wrote: post #202
pjmlp wrote: post #147

Earlier quoted context omitted.

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

Would you rather have them use C++? In this regard, Go is a lesser evil.

Or Rust, if you really really want to avoid C++.

Re: Eight years of Go

#205

Post by freyir »

coldtea wrote: post #153
freyir wrote: post #72

Earlier quoted context omitted.

It's the biggest issue, but that doesn't mean the majority of Go developers support it. 1734 people reacted to the generics issue, most in favor, but there are many more Go developers than that. But the people who read the proposal and reacted to it may be the vocal minority who are concerned about generics. The majority may not spend their time reading or reacting to proposals they don't care about.

> 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. And many more want Generics without having responded to the issue. Issues are representative as a sampling, not absolute numbers.

I'm not sure who you're quoting or why.

> Issues are representative as a sampling, not absolute numbers.

My point was that issues are not a reliable sample of the Go community as a whole. They're a self-selected population of Go developers who cared enough about generics to click on a Github proposal on the subject and react to it. I'll say it again:

>> The majority may not spend their time reading or reacting to proposals they don't care about.

Maybe the majority do want generics, but the Github issue is poor evidence. A random sample of Go developers would be much better, and then we wouldn't have to make up things like "And many more want Generics without having responded to the issue."

Re: Eight years of Go

#206

Post by giovannibajo1 »

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…

> - 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. > - Similarly, Go doesnt bother to hide the differences of different OSes.

I disagree with these. Go runtime/stdlib is architected to work around many many POSIX headaches and design bugs, hiding them completely from programmers, and to be fully portable. For instance:

* Concurrency is completely redesigned (goroutines). * Signal handling is redesigned and doesn't cause bugs when interacting with concurrency. * Forking/Exec'ing is redesigned not to cause fd leaks in subprocesses (all file descriptors are marked as O_CLOEXEC, in a race-free way), nor have races while interacting with concurrency * Sockets are exposed through a higher-level API (Dialer/Listener). * epoll is not exposed but transparently used by a single thread to handle all supported file descriptors without wasting OS threads, to improve performance

In fact, I think the only thing that is pretty much low-level is os.File and filesystem access in general, which tends to expose lower-level details.

Re: Eight years of Go

#207

Post by brian-armstrong »

giovannibajo1 wrote: post #206
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…

> - 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. > - Similarly, Go doesnt bother to hide the differences of different OSes. I disagree with these. Go runtime/stdlib is architected to work around many many POSIX headaches and design bugs, hiding them completely from programmers, and to be fully portable. For instance: * Co…

Having experienced a situation where I had to call select() directly, I have to completely disagree. If you run into situations like this, you need the syscall escape hatch. It's really painful to get this working, and it interacts poorly with goroutines.

Sockets are actually another good example. If you need to tweak then at all, you get to use the same old horrendous POSIX names for everything. No name aliases?

Re: Eight years of Go

#208

Post by coldtea »

freyir wrote: post #205
coldtea wrote: post #153

Earlier quoted context omitted.

> 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. And many more want Generics without having responded to the issue. Issues are representative as a sampling, not absolute numbers.

I'm not sure who you're quoting or why. > Issues are representative as a sampling, not absolute numbers. My point was that issues are not a reliable sample of the Go community as a whole. They're a self-selected population of Go developers who cared enough about generics to click on a Github proposal on the subject and react to it. I'll say it again: >> The majority may not spend their time reading or reacting to pro…

>I'm not sure who you're quoting or why.

I accidentally re-pasted the same quote from nine_k I've answered to higher up the thread.

Meant to quote this from you: "1734 people reacted to the generics issue, most in favor, but there are many more Go developers than that".

>* My point was that issues are not a reliable sample of the Go community as a whole. They're a self-selected population of Go developers who cared enough about generics to click on a Github proposal on the subject and react to it.*

And my point is that I don't think this is the case. I don't know either way, but there's no reason to assume people caring to vote in the issue are necessarily not representative -- like I don't think that for any other project/issue combo on github.

In any case, even if they aren't representative of existing heavy Golang users, who cares about them? The language is still niche. There are tons more programmers to come to the language than those that already are using already.

So I would very much pay attention to what those not yet using it but caring enough to vote have to say about it.

Re: Eight years of Go

#209

Post by coldtea »

kjksf wrote: post #159
terminalcommand wrote: post #114

Earlier quoted context omitted.

I've run into concurrency problems using maps while writing an irc client. It was really frustrating for me, because it did not happen everytime I ran the program, but rather rarely. I had chosen Go for it's memory-safety and easy concurrency. But I felt like I could not vouch for my program's safety any more. I did not know about sync/map at the time, had I known, I would probably have used it. I think Golang has a…

For concurrency issues, -race flag is your friend. Don't blame the language for your buggy code. Unless otherwise stated, Go's data structures are not thread-safe. Maps are not thread safe. In that respect Go isn't different from any other mainstream language with pre-emptive threading (C++, Java, C#).

>Don't blame the language for your buggy code.

No, DO blame the language if its the one that enables and allows for said buggy code when it could as well prevent it.

Case in point: http://lambda-the-ultimate.org/node/3186

Re: Eight years of Go

#210

Post by coldtea »

wbl wrote: post #182
kjksf wrote: post #159

Earlier quoted context omitted.

For concurrency issues, -race flag is your friend. Don't blame the language for your buggy code. Unless otherwise stated, Go's data structures are not thread-safe. Maps are not thread safe. In that respect Go isn't different from any other mainstream language with pre-emptive threading (C++, Java, C#).

But I can't implement a drop in compatible concurrency safe map.

Don't blame the language for that: jump through BS hoops to create one such map /s
Post reply on HN