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

141–150 of 176 posts

Re: Golang generics proposal has been accepted

#141

Post by beoh »

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…

This is not an issue with Option at all. When you receive data from an external system, you should always parse it before making assumptions. By parsing I don't mean read property x as string, but make it a CustomerId for example, considering your constraints before accepting the value.

Re: Golang generics proposal has been accepted

#142

Post by slammin »

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…

> 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 is complete jibberish.

i don't really understand this part. you can't treat it as impossible, because `Optional[T]` is a different type than `T`. anywhere you try to use an `Optional[T]` as a `T` is a type error.

i think you're saying "there are some cases where `T` can also be null that are now unaccounted for," which i don't think is really relevant. that's more a matter of API design; a hypothetical function that receives data from a server should return an `Optional[T]`. one that treats the operation as infallible would throw an exception just like in an implicitly null language, right?

Re: Golang generics proposal has been accepted

#143

Post by lillecarl »

rurban wrote: post #111
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…

> high performance I would not call 2x slower than C high performance. Decent performance, yes. But certainly not high. It has easy to use concurrency, so it waits less than typical C code. This might lead to some high perf claims. But it is not

If you put Python and Ruby in the same graph Go and C will look more the same. Though let's be honest, how much does language speed really matter for most things? It's crap code that kills performance more than anything from my limited experience, and with a higher level language you might have easier access to libraries implementing efficient algorithms for.

When good performance is needed we don't even "write code" anymore, we use ASICs. BTC mining, network switching/routing and encryption comes to mind.

Re: Golang generics proposal has been accepted

#144

Post by kaba0 »

zwieback wrote: post #127
SloopJon wrote: post #79

Earlier quoted context omitted.

> Even templates in C++ are notorious for puking near impossible to decipher errors. "Even"? I actually miss the macro-like power of templates when I'm using generics in Java and C#, but generating the longest possible error message using templates is practically an Olympic sport. I presume that SFINAE is partially to blame, because a lot of the output enumerates all the candidates that didn't match.

I love-hate C++ templates because deep down they are just macros and you don't have to obsess about constraints like in Java and C#. To me it's pretty interesting how the three big static OO languages have implemented generics: super flexible permissive macros in C++ (with murderous error messages), type erasure in Java (gross) and actual generics in the runtime (C#). For everyday usage it doesn't matter much but I a…

This is my usual nitpick, but pretty much every language does type erasure and there is nothing bad with it, blahblah.

Haskell is arguably great with types, and it does type erasure as well.

Re: Golang generics proposal has been accepted

#145

Post by kaba0 »

SeanLuke wrote: post #16
maurys wrote: post #2

I wonder if over time, Golang will pick up more type features like Java and other languages have. The general consensus seems to be that powerful type systems are very effective. Personally, the low footprint runtime and concurrency primitives are enough for me and I wouldn't mind the language becoming "less simple" if it helps the ecosystem. Once generics are implemented, I can imagine people requesting for the next…

> I wonder if over time, Golang will pick up more type features like Java and other languages have. I hope it doesn't pick them up like Java did. When Java was considering generics, there were two major proposals out there. Sun decided on easily the worst one: type erasure. Now we're stuck with it. When Java was considering closures, there were two major proposals out there that I recall [one being to get rid of Java…

Any objective reason for thinking either feature is bad?

Re: Golang generics proposal has been accepted

#146

Post by shakow »

cies wrote: post #96
sdfsfsf3kjdf wrote: post #82

Earlier quoted context omitted.

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

No, it fixes that you don't have to chose between ListOfInts, ListOfStrings and ListOfListOfArrayOfInt.

BTW, one doesn't have to chose between them in Go either, but only because there are under-the-hood generics for the native types, that are only accessible to the language designers.

Re: Golang generics proposal has been accepted

#147

Post by eyelidlessness »

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…

> Scala, Haskell, even Typescript have painful compile times.

Can’t speak to the first two, but in some places TS has pathological compile times when you’re trying to give more information to the compiler. A recent example is trying to appease type inference on a set of generics where a wrapped function couldn’t narrow types from its wrapper even though they were totally valid but mostly inferred. I wrote a type guard which passed the same values with explicitly narrowed types and... it just never completes. Pegs all my CPU cores in VSCode. Used throughout my project and effectively kills type checking.

I know enough about the underlying function I’m calling that I just cast to any, but now I have a mine waiting to be triggered.

To be fair, this is in frontend land where it’s not TS’s fault that the types they support are so bonkers to begin with. But holy hell it’s not always obvious what’s gonna cause compile times to skyrocket.

Re: Golang generics proposal has been accepted

#148

Post by alisonatwork »

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…

I kind of agree, when working on a large team.

Adding optional arguments everywhere is a bit like declaring checked exceptions everywhere. It's true that optionals make the code more explicit, and they force developers to handle every situation, but in the end you still need developers who actually care about writing readable and maintainable code for it to be a net gain.

Something I have come across a fair bit is code where too many values are declared as optional, so the developers try to build an elegant solution by mapping functions over these optional values, returning a default at the end. If there is a value, then the expected code path gets called, else it just silently skips the rest of the code and returns back up to the top layer. This causes a similar issue to what can happen with promises - you lose the context of where the first "error" happened. This could be avoided by eagerly throwing an exception in the first absent case, but that takes us back to where we started with null.

I think the "best practice" way of using optional values is to get buy-in from all the developers on the project that basically nothing should be optional, ever. The goal, then, is to explicitly throw an exception (or return an error) at the very top level and ensure that only actual values enter into the main part of the project's code. But enforcing that is more of a management problem than a technical problem.

Re: Golang generics proposal has been accepted

#149

Post by teleforce »

bcrosby95 wrote: post #122
SloopJon wrote: post #79

Earlier quoted context omitted.

> Even templates in C++ are notorious for puking near impossible to decipher errors. "Even"? I actually miss the macro-like power of templates when I'm using generics in Java and C#, but generating the longest possible error message using templates is practically an Olympic sport. I presume that SFINAE is partially to blame, because a lot of the output enumerates all the candidates that didn't match.

This is why I've always hated C++. Taking something like templates, and abusing the turing-completeness of it. If I wanted macros I would use a language that actually supports them so I wouldn't have to resort to byzantine hacks. Stuff like this is why lots of people would rather use C over C++.

D language is probably the Goldilocks of programming languages for the rest of us in terms of compilation speed (comparable to Go), program execution (comparable to C/C++) and ease of programming and debugging (comparable to Python). The author of the D language despises macro more than you, and has designed a solution for modern and sane approaches to template programming [1][2]. If you want to program like C in D modern eco system there is a safer betterC. Heck now there is even borrow checking capability if you want safety guarantees similar to Rust.

[1]https://mobile.twitter.com/WalterBright/status/1343128003178...

[2]https://dlang.org/blog/2018/03/29/std-variant-is-everything-...

Post reply on HN