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

111–120 of 291 posts

Re: Eight years of Go

#111

Post by johndubchak »

krylon wrote: post #30
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).

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…

> I write in my free time to relax (sounds weird, I know)

Not weird at all. I do that myself. I believe the relaxation is in pure creativity, the wonder of exploring something novel and the absence of any pressure or stress due to timelines or deadlines. You're also exercising both right and left sides of the brain.

I suspect there are many many more who do the same.

Re: Eight years of Go

#112

Post by majewsky »

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

Defer is not enabled by goroutines. C++ has `defer` as well, although it's called "destructors" there.

Re: Eight years of Go

#113

Post by lossolo »

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 most vocal group is the always the one that is not happy with someone. Doesn't mean this is majority and often it's not.

Re: Eight years of Go

#114

Post by terminalcommand »

erik_seaberg wrote: post #98
theshrike79 wrote: post #47

Earlier quoted context omitted.

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.

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 fondness for magical (to me) special language constructs. For example if you want to use the RPC modules, you have to write your functions a certain way. Or as I've explained in a comment above, if you want to use an interface you just have to implement all it's properties. Or you can't have generics, but we have a special language construct called maps, where you kind of can mimick genericks but it is not safe and may break.

Golang is a great language, but I think it expects all its users to think very rigidly in the same way their designers do. Basically, you have to explore the language's deficiencies yourself, read the designers' explanations, dive into the intrinsics of the language, understand it, make yourself believe and move on. I sometimes half-jokingly feel like Golang follows the principle of most obedience.

Re: Eight years of Go

#115

Post by majewsky »

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

Re: Eight years of Go

#116

Post by noncoml »

wheaties wrote: post #44
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)…

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.

Fair enough. I should have said one of the best. A bit of sensualism there.

Re: Eight years of Go

#117

Post by pcwalton »

ori_b wrote: post #103
pcwalton wrote: post #65

Earlier quoted context omitted.

You're still writing separate functions (implementations of sort.Interface) to sort different types.

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.

Re: Eight years of Go

#118

Post by moocowtruck »

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 would be seen as a project of insanity if not been made by google; and would most likely be in a field of dead language husks

Re: Eight years of Go

#119

Post by Karrot_Kream »

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…

I'm not disagreeing with you (I've previously criticized Go here) but I think it's helpful to think of Go as a more "modern" C. A lot of the warts you see here (Cludgey POSIX interfaces, no smart scheduling around channel error handling, bad reflection semantics, etc.) are the same as you'd find in C.

Re: Eight years of Go

#120

Post by jhjwe888 »

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…

It should be obvious to folks on HN why a Github issue that may go completely unseen by a large swath of the go community, or +1's which can be gamed/trolled, should not be taken as a valid measure.

But it must be explained I guess.

Post reply on HN