Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.18

go.dev

Post reply on HN
Print view View original

91–100 of 614 posts

Re: Go 1.18

#91

Post by mftb »

pkulak wrote: post #71
_0w8t wrote: post #67

For me the most puzzling aspect of Go is channels. Ada tried CSP (Concurrent Sequential Processes that Go channels are based on) in eighties and people quickly realized that it lead to bad performance and was unsuitable for a lot of useful cases. So Ada got standard mutexes and signals. So why CSP which does not allow to implement priority delivery or multicasting and makes cancelling much harder compared with normal…

I can never seem to understand why a GCed language has pointers, and makes you memorize when to use stack vs heap.

It's pretty straightforward, knowing when to use the stack vs heap can improve your performance. Having both paradigms available in the language means you can start out relying on the GC for everything. Later when you're ready, you can look to make more intelligent use of the stack.

Re: Go 1.18

#92

Post by cube2222 »

Great to see this!

Generics will drastically improve datastructure libraries.

That said, for people worrying about overcomplication, fortunately methods can't have type parameters. That means ergonomic monads are not possible to implement, and we'll most probably not see the whole functional story play out in Go.

Re: Go 1.18

#93

Post by tptacek »

anthropodie wrote: post #72
mseepgood wrote: post #61

Why post this useless Github link instead of the release notes or the blog post?

yes @dang please re-link this post to https://go.dev/doc/go1.18

He's probably not going to see this quickly; the thing to do here is to mail hn@ycombinator.com.

Re: Go 1.18

#94

Post by tptacek »

hi41 wrote: post #79
anthropodie wrote: post #72

Earlier quoted context omitted.

yes @dang please re-link this post to https://go.dev/doc/go1.18

That’s a cool feature you used there. I didn’t know you could use the at-the-rate symbol to reference a hn user and call his attention! Very nice!

It's not a feature, and it's not a good idea to refer to people with @nicks, because Twitter's @name convention is much stronger and the two don't overlap perfectly (I am not, for instance, @tptacek on Twitter). I use 'nick to refer to people here, in keeping with our lispy ethos, but really anything other than @nick is fine.

Re: Go 1.18

#95

Post by jchw »

throwaway894345 wrote: post #12
philosopher1234 wrote: post #3

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…

> Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I'm a big Go proponent, and I'm pretty "meh" on generics. They'll make some code easier to read and write, but they'll make a lot of code a lot harder to read (because contrary to popular beli…

Sum types and pattern matching would be great, and I think they would be much more useful than generics. Unfortunately, Go lacking generics has become a legitimate meme. An article evangelizing .NET recently popped up here and annoyingly used Go’s slowness to get generics as a legitimate point.

I don’t think generics will greatly damage what Go has going for it, but I hope it also doesn’t block the way for better error handling, sum types, and other things that could potentially improve code robustness.

Re: Go 1.18

#96

Post by mseepgood »

jhgb wrote: post #90
mseepgood wrote: post #77

Earlier quoted context omitted.

> Go is really s souped up version of C. But with generics, methods and interfaces, proper strings, maps etc., first-class functions, built-in concurrency, a module system, automatic memory management, a well-rounded standard library and so so so much more.

Not even that -- it's a souped-up version of Oberon with these features. (Although of course, out of those, Oberon had already had a module system and automatic memory management.)

That's a good thing.

Re: Go 1.18

#97

Post by jrockway »

throwaway894345 wrote: post #12
philosopher1234 wrote: post #3

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…

> Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I'm a big Go proponent, and I'm pretty "meh" on generics. They'll make some code easier to read and write, but they'll make a lot of code a lot harder to read (because contrary to popular beli…

I think people are going to go off the rails with functions that abstract over for loops. I see it all the time in Javascript code, where people iterate over an Array multiple times because that's what the API makes easy.

For example, say you want to separate a slice into two slices, one that contains matches and one that contains everything else. Right now, you'd just write:

   var matches, mismatches []whatever
   for _, x := range xs {
       if x == condition {
           matches = append(matches, x)
       } else {
           mismatches = append(mismatches, x)
       }
   }
But soon, people will be golfing that down to:

   matches    := slices.Search(xs, func(x whatever) bool { return x == condition })
   mismatches := slices.Search(xs, func(x whatever) bool { return x != condition })
This is twice as slow, but it's less lines so I have a feeling that people will have an uncontrollable desire to use it as often as possible. I hope that my feeling is wrong.

(Do note that slices.Search is not a real function yet.)

Re: Go 1.18

#98

Post by _0w8t »

zozbot234 wrote: post #76
_0w8t wrote: post #67

For me the most puzzling aspect of Go is channels. Ada tried CSP (Concurrent Sequential Processes that Go channels are based on) in eighties and people quickly realized that it lead to bad performance and was unsuitable for a lot of useful cases. So Ada got standard mutexes and signals. So why CSP which does not allow to implement priority delivery or multicasting and makes cancelling much harder compared with normal…

Go has shared memory and mutexes, but using them means giving up on memory safety because the whole rigmarole that Rust does to preserve safety in concurrent code is totally missing in Go. So that's a meaningful reason to stick to CSP - sure, it might create easy deadlocks but at least it won't totally crash your app with a potentially exploitable fault.

Go could have provided message queues with priorities Erlang style or something closer native solutions in Linux/Max/Windows that are known to work. They are safe, allows to avoid deadlocks just as channels and much more flexible.

And with mutex one can build those as necessary, even if interaction with channels is ugly.

Re: Go 1.18

#99

Post by rob74 »

didibus wrote: post #69
philosopher1234 wrote: post #3

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…

> So, for those of you who are willing to explore the part of this that goes beyond a simple rational analysis and criticism of language design, whats bugging you? I think the reason Go gets a lot of criticism is that at a language level it misses a lot of constructs and features. So for everything it doesn't have, you'll find someone who is really used to leverage those constructs or features when they program and w…

What people don't realize is that the simplicity of the language also contributes to the compilation speed, so adding features to the language at the same rate as other projects (that I don't want to mention here) would jeopardize one of Go's major advantages.

Re: Go 1.18

#100

Post by ModernMech »

gerbilly wrote: post #20
philosopher1234 wrote: post #3

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…

> I would like to understand a bit more about where a lot of the Go criticism comes from. Go is really s souped up version of C. It's a design rooted in the 70s with some fixes to make it a good language for writing small networked apps. Insofar as that goes¹, the language is fine. However the creators of Go responded to critiques of the language in a patronizing manner and talked down to their own programming commun…

> Basically the Go community got the exchange off on the wrong foot.

Indeed. Then there was that whole controversy over the naming collision with the Go! language. Basically there's an unspoken etiquette in the PL community that there should be zero name conflicts between languages, as there are enough good names out there, it really shouldn't be an issue. The Go! language had been around for a long time, and I realize it was an obscure, little known language, but that's true for 99% of languages out there. So the idea that Google can just invent a language out of the blue with the same name as yours, after you've been using the name for a decade, and then just use their size and clout to essentially destroy your language is.... well that's unsettling to people in the PL community. The way they handled the situation didn't exactly win over hearts:

  The naming similarity is unfortunate. However, there are many computing products and services named Go. In the 11 months since our release, there has been minimal confusion of the two languages, so we are closing this issue. Status changed to Unfortunate.
https://github.com/golang/go/issues/9#issuecomment-66047478

Basically a sad trombone. The image of Go has never recovered in my eye.

Post reply on HN