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

201–210 of 614 posts

Re: Go 1.18

#201

Post by jchw »

throwaway894345 wrote: post #157
jchw wrote: post #95

Earlier quoted context omitted.

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

I guess I disagree about the legitimacy of the meme or any point that could be made from Go's "slowness to get generics". The only people who think that generics will be a slam-dunk net benefit for Go are the folks who can't articulate the costs associated with generics. The actual net benefit is so small and the error margins are so wide that it is entirely reasonable that Go didn't rush generics, instead prioritizi…

I mean legitimate meme as in, it is a point that is widely assumed true at this point, not as in it is actually accurate in its assessment. I never really thought Go needed generics.

Re: Go 1.18

#202

Post by frenchie4111 »

morelisp wrote: post #198
Mawr wrote: post #176

Earlier quoted context omitted.

type Optional[T any] struct { value *T } Don't use a pointer - it's bad for performance. func MakeOptional[T any](value *T) Optional[T] { Use `New` instead - it's the idiomatic name for a constructor in Go. Drop the `Optional` part - the module name suffices - the caller will see: `opt.New`. Personally I just call the module `optional`, I think it's clearer: `optional.New`. func (o* Optional[T]) Unwrap() (T, error) {…

Whether a pointer is bad for performance in this case seems hard to tell a priori. There are also performance advantages if Optional packs nicely.

Agreed on performance being in the air. Tbh, I like the non-pointer option because using a pointer was causing the implementation to feel a bit weird. This cleans up a bit of the handling that was annoying (for example in the old implementation Make(&"something") didn't work because you can't reference a constant without first making a variable.

Re: Go 1.18

#204

Post by shhsshs »

wtfishackernews wrote: post #186
Mawr wrote: post #176

Earlier quoted context omitted.

type Optional[T any] struct { value *T } Don't use a pointer - it's bad for performance. func MakeOptional[T any](value *T) Optional[T] { Use `New` instead - it's the idiomatic name for a constructor in Go. Drop the `Optional` part - the module name suffices - the caller will see: `opt.New`. Personally I just call the module `optional`, I think it's clearer: `optional.New`. func (o* Optional[T]) Unwrap() (T, error) {…

For json marshalling, I would defer to the underlying type's marshalling if it's present, and return `null` otherwise.

I think this is appropriate in some cases but not others. For example how does the JSON value distinguish between `Some(null)` and `None`?

Re: Go 1.18

#205

Post by sneak »

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.

Link to the diff? I always learn better by concrete example than by docs.

Re: Go 1.18

#206

Post by codr7 »

philosopher1234 wrote: post #46
gerbilly wrote: post #20

Earlier quoted context omitted.

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

I’m glad you brought this up because I agree Rob pikes quote about go being simple for average programmers has been very provocative, because it’s been interpreted as “Google devs are too stupid for a good language like Haskell, so if you use go it’s because you’re stupid too”. I’m partial to a different interpretation, that’s more like “go doesn’t require as much thinking as Haskell, so you can use your thinking for…

The real problem is designing tools for people who are not as smart.

Because it's not that simple, and no one likes being judged and talked down to.

Re: Go 1.18

#207

Post by pharmakom »

frenchie4111 wrote: post #139

In celebration of generics release, I was playing around with supporting Optionals via generics. If anyone's interested I am happy to make this a real project https://github.com/frenchie4111/go-generic-optional

Optionals without do notation will be a bad time.

Re: Go 1.18

#208

Post by mountainriver »

frenchie4111 wrote: post #139

In celebration of generics release, I was playing around with supporting Optionals via generics. If anyone's interested I am happy to make this a real project https://github.com/frenchie4111/go-generic-optional

Awesome work! I would love to see something like this make it into the language

Re: Go 1.18

#209

Post by t43562 »

I think about Go with pleasure until I remember importing. The miseries I've experienced with modules - the way imports are satisfied......just so hard to understand. Built-in support for SCM sites like github (yuck!). Just struggling to put code in a place where some other bit of my code can use it. The C/C++ preprocessor is an abortion and go seems to have made something that solves all the problems I had with that but ends up much worse to use.
Post reply on HN