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

151–160 of 291 posts

Re: Eight years of Go

#151

Post by coldtea »

nine_k wrote: post #58
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…

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…

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

Many large users writing in company and project blogs have mentioned lack of Generics as a pain point, so that distinction doesn't go very far.

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

Go was not created through some official decree to create a Google language, nor was it mandated to be used or to have some timeline to convert other stuff to it, etc.

It's just a project started by some Go people with the idea "let's examine what a language appropriate for Google's programming would be" -- but using their personal ideas of what Google style programming would need, not something requested, researched etc by Google as an organization. In other words it started as a glorified 20% project, and today it's not any more official in Google than C++ or Java is.

Re: Eight years of Go

#152

Post by shabbyrobe »

LanceH wrote: post #93
dekhn wrote: post #38

Earlier quoted context omitted.

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.

This is exactly my feeling. I don't want generics if I have to pay anything for them in build time, or if it limits go/ast or go/types. A lack of generics has been a pain point a couple of times in my current project (beyond what very simple code generators can provide), but crazy fast build times have been a massive benefit.

Imagine how much wailing and gnashing of teeth there will be if Go 2 delivers generics but with triple the build time and +50% binary size... if you thought the minority was vocal now, wait til you see that!

Re: Eight years of Go

#153

Post by coldtea »

freyir wrote: post #72
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…

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.

Re: Eight years of Go

#155

Post by nsm »

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?

http://www.jerf.org/iri/post/2930 is a really nice blog post from an Erlang programmer attempting to bring supervisor trees to Go as https://github.com/thejerf/suture.

Re: Eight years of Go

#156

Post by bpicolo »

shkkmo wrote: post #62

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

Glide is great - it supported the most important feature I cared about, which was aliasing for forks where I had to fix bugs. "Standard" matters less because there's also no centrally-controlled repository of packages, unlike npm/maven/pip

Re: Eight years of Go

#157

Post by jackmott »

weberc2 wrote: post #53
Gys wrote: post #20

Earlier quoted context omitted.

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.

yes, but those of us who would desperately like to use Go because there are vanishingly few GC languages that compile to native exe AOT, won't because of no generics. So it is a bit of a tautology.

How useful they are depends greatly on what you are doing, and programmers do a great many different things. For many kinds of library development, they can save you massive amounts of time and code, and/or lead to much better performance vs the workarounds available.

I wonder how many people who prefer Go without generics are coming from C++ templates, or Java generics, vs C# or F# generics.

Re: Eight years of Go

#158

Post by jackmott »

kown223 wrote: post #15
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.

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

can't tell if joking

Re: Eight years of Go

#159

Post by kjksf »

terminalcommand wrote: post #114
erik_seaberg wrote: post #98

Earlier quoted context omitted.

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.

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

Re: Eight years of Go

#160

Post by slrz »

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…

> 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 that doesn't work

Why do you expect this to be the case? Just because you can assign a char to an int in C, you wouldn't expect to be able to assign a char pointer to an int pointer. Similar for C++ and std::vector vs std::vector.

It's the same and probably even more relevant with void∗/int∗ (assignable) vs. void∗∗/int∗∗ (not assignable). You can assign an int∗∗ to a void∗, though, just as you can assign an []int to an interface{} in Go.

Also, even as an absolute greenfield programmer with no experience in other system languages, if you really think it through, you will come to the conclusion that it mustn't be possible to assign arbitrary slice values to an []interface{} variable, given the way slices work.

Post reply on HN