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

Golang generics proposal has been accepted

github.com

Post reply on HN
Print view View original

91–100 of 176 posts

Re: Golang generics proposal has been accepted

#91

Post by Zababa »

dcolkitt wrote: post #66

IMO the biggest factors for the success of Go are 1) super-fast compile times, 2) easy to interpret compiler errors, and 3) dead simple shipment of high performance, native static binaries. I think Go has succeeded, despite, not because of the language itself. One very big limitation being the lack of generics or any sort of ability to leverage higher-order types. Sometimes making a small modification to a large code…

> Although higher-typed languages have no trouble achieving good runtime performance, it seems like there's a fundamental tradeoff at compile time. Scala, Haskell, even Typescript have painful compile times.

OCaml has always been known for having really fast compile times, and could be described as a "higher-typed language" I think.

> And as for the topic of clear error messages, the higher-typed languages are all atrocious at this.

Elm and Rust have made good progress here and have some of the most readable and useful errors out here, especially for beginners.

Re: Golang generics proposal has been accepted

#93

Post by shric »

coder543 wrote: post #70
cies wrote: post #61

Earlier quoted context omitted.

When i read Go code it is riddled with null guards. Any of those null guards may be removed, code compiles without additional warnings but now may blow up at runtime. Sorry, but to me that's a clear symptom of implicit nullability. Edit: clarification, to me it does not show in the type signature that something may return a null, also I do not have to unpack a possible null value (like with Maybe or Option).

You can't check for nil on something that isn't nilable -- it's a compile error to do so in Go. Your definition of "implicit nullability" is suspect here. Go doesn't even implicitly de-reference things, which is what I think you're intending to say that it does. (EDIT: field access does cause a dereference, as was pointed out in a response to this comment. I still think of this as an explicit action when you're speci…

> Go doesn't even implicitly de-reference things

Except when accessing a field via a pointer to struct.

https://tour.golang.org/moretypes/4

Re: Golang generics proposal has been accepted

#94

Post by blandflakes »

hnlmorg wrote: post #39
kyrra wrote: post #26

Earlier quoted context omitted.

It actually causes ambiguous syntax that isn't easy to solve. See: https://go.googlesource.com/proposal/+/refs/heads/master/des... a, b = w (z) Is this code doing 2 boolean compares, or is it calling a function with "w" with types x and y?

I know it’s not a popular opinion, but one thing I love about Perl and wished more languages adopted was the way how variables and functions could be prefixed by a special character (‘$’ for scalars, ‘%’ for hashes, ‘@‘ for arrays and ‘&’ for functions, though the latter was optional). Perl had a lot of properties that made it look a lot like executable line noise but those prefixes did help with readability in a way…

The parens look like "helping ambiguous syntax" rather than "should read like this" here - if z is an argument to w, there was already a set of parens signifying the function call.

Re: Golang generics proposal has been accepted

#95

Post by cactus2093 »

zzbzq wrote: post #68
cies wrote: post #14

Earlier quoted context omitted.

Of course I'm joking, but I think implicit nullability is the worst part of Go. A language designed in a era when this was widely known as the billion dollar mistake (prolly even more expensive). But this is not easily reversed. Not as easy as tagging generics onto the language. And the parallels with Java's maturing are just lovely. Also, we have seen what Kotlin is now doing for Java: a new language was needed to t…

Now that I've worked professionally in a whole bunch of languages that attempt to delete implicit nullability out of existence, I long for it's return. Option monads are a two billion dollar mistake. The fact is when you're working with any data coming from any other system, the data is or will become null, somehow, some way, and your program code which treats this as impossible is just literally wrong in a way that…

> copy things into different structs all over the place

Sanitizing input is a very common pattern and I don't see why this option is such a deal breaker. And it would normally just be needed at the system boundary, rather than "all over the place".

Or, you share types between different services using something like grpc or thrift, and then you really can trust that the values coming in are not going to be null.

I definitely don't agree that settling for implicit null is the best option.

Re: Golang generics proposal has been accepted

#96

Post by cies »

sdfsfsf3kjdf wrote: post #82
cies wrote: post #54

Earlier quoted context omitted.

Yes. But null-safety is absolute on the top (as it is soooo hard, maybe even impossible, to add later). Generics... Well, I just come from a Elm gig (knowing Haskell/C++/Java/Kotlin/Ruby) and I must say I was not too bothered with the lack of generics there.

> Well, I just come from a Elm gig and I must say I was not too bothered with the lack of generics there. Elm has generics.

Really? Why then there's List.map, Maybe.map, Array.map, and I have to select one of them? Is that not what generics would fix?

Re: Golang generics proposal has been accepted

#99

Post by [deleted] »

shric wrote: post #93
coder543 wrote: post #70

Earlier quoted context omitted.

You can't check for nil on something that isn't nilable -- it's a compile error to do so in Go. Your definition of "implicit nullability" is suspect here. Go doesn't even implicitly de-reference things, which is what I think you're intending to say that it does. (EDIT: field access does cause a dereference, as was pointed out in a response to this comment. I still think of this as an explicit action when you're speci…

> Go doesn't even implicitly de-reference things Except when accessing a field via a pointer to struct. https://tour.golang.org/moretypes/4

[deleted]

Re: Golang generics proposal has been accepted

#100

Post by acoard »

zzbzq wrote: post #68
cies wrote: post #14

Earlier quoted context omitted.

Of course I'm joking, but I think implicit nullability is the worst part of Go. A language designed in a era when this was widely known as the billion dollar mistake (prolly even more expensive). But this is not easily reversed. Not as easy as tagging generics onto the language. And the parallels with Java's maturing are just lovely. Also, we have seen what Kotlin is now doing for Java: a new language was needed to t…

Now that I've worked professionally in a whole bunch of languages that attempt to delete implicit nullability out of existence, I long for it's return. Option monads are a two billion dollar mistake. The fact is when you're working with any data coming from any other system, the data is or will become null, somehow, some way, and your program code which treats this as impossible is just literally wrong in a way that…

>Actually, javascript is the only language that has it right. Not only can anything be null, anything can be undefined, (which isn't even remotely similar and anyone who doesn't understand why doesn't belong in the conversation,) AND values you don't know about can exist.

If you mean `unknown`, that's a TypeScript thing.[0]

And personally I love working on a code-base and with coders that differentiate between null and unknown. But there's no denying it's a footgun and many get no value besides bugs from these two. It's kind of similar to how JS gets boolean comparisons weird, which is worked-around by convention

[0] https://www.typescriptlang.org/docs/handbook/release-notes/t...

Post reply on HN