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

461–470 of 614 posts

Re: Go 1.18

#461

Post by randomswede »

_0w8t wrote: post #425
coder543 wrote: post #159

Earlier quoted context omitted.

> Still without proper sum types polymorphic and type-safe message queues are not possible. This isn't really true. You can define a channel where the message type is an interface, and then you can use a type switch on the receiving side to downcast that interface to various concrete message types. What you can't do without sum types is ensure that you don't need a "catch-all" branch for if/when a value is sent down…

By type-safety I indeed also implied inability to send messages that the receiver would not process. This is essential to allow safe refactoring.

What I have done in the past when I've needed to pass various different types across a channel is to look at what the receiver of these messages actually need to do, factor that out into an interface, make a "chan myInterface", then make sure that every data type I need to pass across actually implements that interface.

The main thing I am working on (slowly, because time and stuffs) is a client library for an saync-protocol messaging/forum platform, where each request will (eventually) receive a response, so I send the request, then construct a request-specific data type to pass across to the listener, together with the ID of the request, so that when the response returns, it can dispatch to the proper decoder for the response.

That actually seems easier to describe in code, than in words, but this margin is too short for that.

Re: Go 1.18

#462

Post by uryga »

kevinmgranger wrote: post #374
uryga wrote: post #326

Earlier quoted context omitted.

> But I also don't know any languages where errors _aren't_ values (look, i know you understand how exceptions work, please bear with me) yes, Exception objects are technically values, but you don't return them to the caller; you throw them to the, uh, catcher. basically, you get a special, second way of returning something that bypasses the normal one! but in the EaV approach, errors just are returned like every oth…

Right, so the concept in Go is misnamed. It's not Errors are Values, it's Errors Have Normal Control Flow. Returning errors makes many things more manageable, definitely. But where they really shine, like in the mapping example, isn't possible in Go. Unless I'm mistaken with how go generics work. (By the way, I'm a huge fan of how error handling works in Rust and other related functional languages. Definitely not adv…

> But where they really shine, like in the mapping example, isn't possible in Go.

oh yeah, definitely! Go's version of EaV with multiple returns is pretty lackluster compared to a proper Result type. afaict it's kind of "the worst of both worlds" -- all of the boilerplate of plumbing errors manually w/ none of the benefits.

Re: Go 1.18

#463

Post by erik_seaberg »

pjmlp wrote: post #422
jshen wrote: post #327

Earlier quoted context omitted.

Yes, it’s a trade-off. In an organization with thousands of developers the right trade-off is likely different than an org with 20. What I don’t understand is why people insist on making Go like every other language that already does what that are looking for. You want a language with generics, purely functional blah blah blah, great there are tons of choices, use one of them. Why insist on reducing the diversity in…

Because in many shops IT decides what languages people use, given the platforms, not devs. Also quitting the job isn't always an option. That is why some of us have to put up with languages that we rather not.

This. I joined a Java- and Scala-centric team, yet Go is continually harder to avoid for no fault of our own, so I’m glad we’ll at least have a less obstinately broken dialect.

Re: Go 1.18

#464

Post by chombier »

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

Maybe the addition of generics could enable Concurrent ML-style composable channels?

This wouldn't solve the performance issue, but at least it would provide a nice abstraction for protocols.

Re: Go 1.18

#465

Post by uryga »

int_19h wrote: post #380
uryga wrote: post #326

Earlier quoted context omitted.

> But I also don't know any languages where errors _aren't_ values (look, i know you understand how exceptions work, please bear with me) yes, Exception objects are technically values, but you don't return them to the caller; you throw them to the, uh, catcher. basically, you get a special, second way of returning something that bypasses the normal one! but in the EaV approach, errors just are returned like every oth…

Exceptions can still be treated as syntactic sugar for EaV; it just means that every expression has an implicit unwrap-and-propagate.

are there any languages that do this? Rust's `?` is similar but the propagation is explicit

Re: Go 1.18

#466

Post by fulafel »

munificent wrote: post #290
dimgl wrote: post #284

Earlier quoted context omitted.

Disclaimer: I'm extremely happy that generics are coming to Go. > I wish I understood how people can say 'this will result in so much more weird boilerplate garbage code' It's pretty simple: there's a lot of developers that misuse/shouldn't use generics. Here's an article I found just casually browsing on Google that shows why this can turn out to be such a huge problem. https://itnext.io/golang-1-18-generics-the-goo…

There's a lot of developers that misuse/shouldn't use any powerful feature. If the solution is to give them a nerfed language, then you also nerf it for the users that would use the feature well in productive, useful ways.

Languages are very powerful in shaping expression of programmers, new and experienced. Limiting expressivity is how we eg got from assembly programming to structured programming. Same memory safety, garbage collection, etc..

Re: Go 1.18

#467

Post by gonzo41 »

akmittal wrote: post #140

Hopefully generics will help make better libraries for Graphql. Existing libraries resorted to code generation a lot.

You don't think graphql is kind of antithetical to the simplicity that go initially was going for?

Re: Go 1.18

#468

Post by throwaway000811 »

pjmlp wrote: post #422
jshen wrote: post #327

Earlier quoted context omitted.

Yes, it’s a trade-off. In an organization with thousands of developers the right trade-off is likely different than an org with 20. What I don’t understand is why people insist on making Go like every other language that already does what that are looking for. You want a language with generics, purely functional blah blah blah, great there are tons of choices, use one of them. Why insist on reducing the diversity in…

Because in many shops IT decides what languages people use, given the platforms, not devs. Also quitting the job isn't always an option. That is why some of us have to put up with languages that we rather not.

We change the language; people who formerly enjoyed the language now have to put up with a language they rather not. Their only option is to quit programming since there are no programming languages they enjoy left.

Re: Go 1.18

#469

Post by Cthulhu_ »

justinsaccount wrote: post #48

Generics is the big news, but the fuzzing support is amazing too. I added a fuzz test to an app I have in about 5 minutes. It was no harder than adding a normal test. I expect to see a huge boon in users of fuzzing techniques which will benefit projects across the board.

I might use fuzz testing to test some validation logic I will add later on, things like strings having to match a certain pattern. Regex is Klatchian to me, but the previous guy left behind a big set of expressions that are currently used in validation; using fuzz testing I should be able (if I understand it correctly) to find gaps in those expressions.

Re: Go 1.18

#470

Post by lenkite »

alex_sf wrote: post #406
alophawen wrote: post #371

Earlier quoted context omitted.

I spent 4 months in '21 rewriting a golang backend to properly use channels for concurrency. The previous developers did misuse it and left a steaming pile for me to find. However contracting pays well, so I don't care. You might want to reflect on your reasons for jumping ship because your tooling gained a new feature. Sound's rather irrational to me.

It's less that it gained a new feature, and more (the fear at least) that it made a change for the worse. Avoiding updating to a new version of OSX that stabs you in the face is a reasonable thing to do, despite it being a new feature.

Go already had generic structures anyways. Go maps supported generics. Or did you always use map[interface{}]interface{} everywhere for the purity of your anti-generics position ?
Post reply on HN