Live data from Hacker News

Go 1.27 Interactive Tour

victoriametrics.com

31–40 of 219 posts

Re: Go 1.27 Interactive Tour

#33
post #16

Earlier quoted context omitted.

No. I kind of want to leave it there. But that will probably be looked on disfavorably. I've seen at least a dozen attempts. It's not like it's hard to write it out. There's maybe a couple of variants but they're all just a handful of lines. The problem is, once you have an Option in hand, you end up trading: val, err := whatever(...) if err != nil { // handle error } // use val for val := whatever(...) if err, isErr…

I think my opinion will be even more maligned: I like Java-style checked exceptions. It forces awareness of the error and a clean way to propagate it.

The thing that most annoys me in Java in that area is when a dependency throws an unchecked error that wasn’t even documented.

Thanks so much for that! Now I have no choice but to be reactive when something fails…

Re: Go 1.27 Interactive Tour

#34
post #23

Earlier quoted context omitted.

Unfortunately nothing changed. They wanted generics all along. The Go ecosystem was a delicate, special thing. It was a wholesale rejection of the malignant consultancy takeover of programming that had festered and spread for the previous 15 years. Introducing generics was a grievous error, and they just keep making it worse. It used to be you could look at any Go code from any author and pretty much instantly unders…

I have written Go for the past decade and completely, fundamentally disagree with this take. Go has always had a tendency towards limited exressivity, which created a strong dependence on interface{}, type assertions, and runtime bug’s that should have been compiler errors. When I read these grumbling takes about how Go use to be so simple etc I imagine devs who would revel in all the features they were unable to imp…

[dead]

Re: Go 1.27 Interactive Tour

#35

generics were a slippery slope. give it a decade and Go will be indistinguishable from c++

Generics themselves maybe not. Generic methods probably yes. What people want generic methods for is to do deeply nested call chains that were never typical of Go. And if you have deeply nested calls you'll need some way to deal with errors in deeply nested calls, and then a short function syntax to pass to behavior inside those deeply nested calls. Give it a few years and everyone will be writing the same functional slop in Go that they are writing in every other language.

Re: Go 1.27 Interactive Tour

#36

Those Generics syntax in Golang seems so hard to read.

It is verbose but inference helps a lot to keep it “tidy”. I always find myself increasing my focus a notch when I start dealing with generics. It’s one of the things I use only if I really “need”.

One of the reasons it took so long to implement generics in Go was because there was a lot of stuff you could do that didn't need it. Now that generics are there, a lot of that stuff is still the best way to solve the problem and many of the methods that require generics are in the standard library so it's rare that you absolutely need it.

Re: Go 1.27 Interactive Tour

#37

Am I the only one who’s absolutely shocked that Go finally is embracing generics? Does anyone have a bit of an inside view into what changed in the perspectives of the language maintainers? I’m not buying the “it took us 20 years to understand how to do it correctly” argument, as this is something you explicitly take into consideration when designing the language or not. And it was specifically not a part of language…

and they're still worse than the 1970s state of the art lol

you mean like in Oberon?

Re: Go 1.27 Interactive Tour

#40
post #13

Automatically draining http response bodies is a risky silent behaviour change. I think it will be an improvement for most applications, but it's very subtle if you were relying on the old behaviour

Can you go more into this? I don’t quite follow
Post reply on HN