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

171–176 of 176 posts

Re: Golang generics proposal has been accepted

#171

Post by dragonwriter »

andreygrehov wrote: post #167
dragonwriter wrote: post #163

Earlier quoted context omitted.

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

Statically requiring a (the default case) non-nillable pointer to be assigned to a non-nil value (presumably, ultimately as a result of an operation that fails if it can't allocate, or one that either fails or returns a non-nil pointer when passed a nillable pointer) before being used?

The same thing as is done for any other non-nullable value in static type systems.

Re: Golang generics proposal has been accepted

#172

Post by zxcvbn4038 »

andreygrehov wrote: post #166
pjmlp wrote: post #151

Earlier quoted context omitted.

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

https://www.psychologytoday.com/us/blog/women-autism-spectru...

Re: Golang generics proposal has been accepted

#173

Post by baby »

hota_mazi wrote: post #125
baby wrote: post #50

Earlier quoted context omitted.

and less readable, less auditable, less understandable, etc.

These are all subjective aspects which often confuse unfamiliarity with obfuscation. I can read generic code in multiple languages even when I'm not fluent in these languages. Once you get used to generic code, it actually becomes easier to read and understand than code where everything is type cast or Object typed all over the place.

Readability is far from subjective, if 50% of your devs can’t read parts of the codebase then it’s not readable.

Simple generic code is fine, but generics can be abused to over engineer things.

Re: Golang generics proposal has been accepted

#174

Post by baby »

alecbz wrote: post #137
sdfsfsf3kjdf wrote: post #114

Earlier quoted context omitted.

How exactly are you going to implement a type safe option type without generics? You either have to use interface{}, which is obviously not type safe, or write/generate an option type for every type contained within it. Sum types are a lot less useful if you don't have generics.

It could have been built in to the language. Tons of builtin features (slices, maps, channels) are already "generic".

This

Re: Golang generics proposal has been accepted

#175

Post by midrus »

coldtea wrote: post #170
midrus wrote: post #160

Earlier quoted context omitted.

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…

All of this is an immense wheel reinvention, and the SQL I'm seeing is actually far worse than what ActiveRecord or Django's ORM would generate.

Also, talking about such a low level performance issues makes me think we're already talking about very different problems. Maybe you're working for Google or Amazon or a pretty performance heavy application. Then ok, I agree with you.

But my disconfort is with most startups, and most average companies chosing Go and doing all of this reinvention when what they are doing is basic CRUD for a web app that has less than 100 reqs a day.

For the use cases I've seen of Go so far, the bottleneck was caused by using it, and it's ecosystem, because the slowest part of the system is the development time and the need to rebuild from scratch a lot of things you get for free otherwise.

Re: Golang generics proposal has been accepted

#176

Post by oblio »

coldtea wrote: post #170
midrus wrote: post #160

Earlier quoted context omitted.

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…

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

Yes, because that's what you want or need, your database drivers to implement custom adapters for data types.

What do you do when your app supports multiple database types? What do you do when you have to switch driver for whatever reason?

ORM/user friendly query builders are a layer on top of the driver, the driver shouldn't contain them...

Post reply on HN