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

161–170 of 176 posts

Re: Golang generics proposal has been accepted

#161

Post by pjungwir »

sdfsfsf3kjdf wrote: post #118
pjungwir wrote: post #87

Earlier quoted context omitted.

I've been experimenting with Rust's Rocket webapp framework, and as much as I like it, I agree it's very annoying how a struct can't permit nulls in one context but not another. I wish there were an easy solution that didn't require near-identical struct definitions and excess copying memory from one place to another.

In Rust you can solve this via derive or a macro. Typescript's conditional types and the associated utility types are a nice solution to this problem as well. You can do a ton with Partial, Required, Pick, Omit, Exclude etc.

Thank you both for these tips. I'll see what I can figure out! :-)

Re: Golang generics proposal has been accepted

#162

Post by andreygrehov »

cies wrote: post #14
cies wrote: post #5

This was to be expected. But I'm glad for Go. In some years a language that interops with Go comes out, where all the Go types have a ?-suffix indicating they are nullable. The language will be mostly null-safe. Also it will sport sumtypes and pattern matching/ destructuring in switch statements. It will be called: Gotlin.

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…

What do you mean by implicit nullability? Go doesn't have it. A pointer can be nil, which is obvious, but a regular string or int, or even a struct type cannot be nil (unless it's a pointer).

Re: Golang generics proposal has been accepted

#163

Post by dragonwriter »

andreygrehov wrote: post #162
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…

What do you mean by implicit nullability? Go doesn't have it. A pointer can be nil, which is obvious, but a regular string or int, or even a struct type cannot be nil (unless it's a pointer).

> A pointer can be nil, which is obvious

It's certainly common, but of the things which would be useful to be able to constrain only to allow explicit and non-default nillability, pointers are pretty high on the list.

Re: Golang generics proposal has been accepted

#164

Post by dragonwriter »

baby wrote: post #41
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…

Golang needed sum types (for options) and match statements (python got it after all...) way before it needed generics. CHANGE MY VIEW.

Python has all of those things, including generics, so whatever order they are needed in, “Python got it” doesn't argue for one over the others.

Re: Golang generics proposal has been accepted

#165

Post by dragonwriter »

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…

> Additionally, programmers don't want to pass huge lists of parameters to every function, but instead bundle things into structs to be easily passed around, however this model makes it impossible to treat a value as Optional at an early part of the callstack and Non-optional later in the callstack after it's been checked and verified.

No, it doesn't; there's a couple easy, obvious ways to do that depending on how you get the data components and how far it is useful to pass them as a group without ensuring none are null. It's not even mildly challenging, much less impossible.

Re: Golang generics proposal has been accepted

#166

Post by andreygrehov »

pjmlp wrote: post #151
zxcvbn4038 wrote: post #64

Nobody will have anything to complain about once go has generics, we'll never hear about Golang on Hacker News again! It'll just be the Rust people complaining. ;)

Error handling, lack of enums, modules, too big executatbles, lack of optimizing backend, middle class GC implementation.

Error handling - I'm a huge fan of explicit error handling. You know exactly what's going to happen.

Lack of enums - not big of a deal. Never had any issues with defining an enum-like type, which is a common idiom in Go.

Modules - it has been fixed. Are there any issues left?

Too big executatbles - I mean, ok, so what? Why is it a concern?

Lack of optimizing backend - could you elaborate on that?

Middle class GC implementation - are you referring to lack of manual tuning?

Re: Golang generics proposal has been accepted

#167

Post by andreygrehov »

dragonwriter wrote: post #163
andreygrehov wrote: post #162

Earlier quoted context omitted.

What do you mean by implicit nullability? Go doesn't have it. A pointer can be nil, which is obvious, but a regular string or int, or even a struct type cannot be nil (unless it's a pointer).

> A pointer can be nil, which is obvious It's certainly common , but of the things which would be useful to be able to constrain only to allow explicit and non-default nillability, pointers are pretty high on the list.

What would be a better design?

Re: Golang generics proposal has been accepted

#168

Post by [deleted] »

Zababa wrote: post #91
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 at…

[deleted]

Re: Golang generics proposal has been accepted

#170

Post by coldtea »

midrus wrote: post #160
coldtea wrote: post #92

Earlier quoted context omitted.

2 out of 3 right ain't bad. We really don't need ORMs

Yep, I can see at work how fantastic are those hand written sql scripts wrapped in bash to run migrations, and those magnific joins and manual mapping of dates. That's great, until you realize you have an actual product to build.

Well, no ORM != bash.

And no ORM != manual mapping of dates. All kinds of drivers have custom adaptors for data types.

(Also a query builder is not an ORM).

>That's great, until you realize you have an actual product to build.

That's exactly the problem with ORMs. You get worse SQL generated under the scenes, with worse performance, and less control.

It's just hidden under the carpet.

Plus, if you build your product with heavy domain objects in 2000s OO-style you're doing it wrong.

And if you don't, and use, e.g. data classes and record structures, then you don't need an ORM since there's no "O" to map too.

Post reply on HN