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

Notes on the Go2 Generics Draft

jmoiron.net

Post reply on HN
Print view View original

71–80 of 116 posts

Re: Notes on the Go2 Generics Draft

#71

Post by mort96 »

nemo1618 wrote: post #24

I'm glad I'm not the only one sad to see generics invading a perfectly good language. Programmers love generics because they enable higher-order abstractions, and programmers love abstractions -- code that isn't DRY is like an itch we need to scratch. Programmers also hate special cases, because they feel restrictive and inconsistent: I recall quite a few people protesting that Go's 'range' keyword shouldn't be restr…

I'm curious, what's a better solution for generics if you want some kind of container which doesn't need to care what type it contains? Is the better solution to just use the current C-style void* s everywhere and manually cast your objects to and from void* (or in Go's case, interface{}), leaving type safety to the programmer? Or is the argument that people shouldn't need to write containers, and all necessary container types should be a part of the standard library and impossible to re-implement using regular Go code? Or is code generation a good enough solution? Or are there other, nicer solutions to enable generic container types which can't be abused like Java-style generics can be?

I don't particularly care which direction Go goes in, and don't write a lot of it myself, but I'm very curious what the alternative is.

Re: Notes on the Go2 Generics Draft

#72

Post by int_19h »

annywhey wrote: post #62
cdoxsey wrote: post #59

Earlier quoted context omitted.

Ironically generics don't necessarily solve this. C# requires multiple implementations of numeric methods because int/float/etc don't sit in a type hierarchy. It also doesn't really work in Java either because you have to use the Object types. Even in rust this looks pretty complicated: https://travisf.net/rust-generic-numbers Maybe it's easy in c++? I've seem a similar comment made on almost every discussion of this…

In agreement. IMHO generics basically have one place where they work well: abstract containers. Your queues, linked lists, what-have-you can benefit. But most other data structures? Nope. Too much of the algorithm depends on the primitive type. And that makes generics a nice boon for computer scientists and certain library authors, but of middling benefit for day-to-day coding. If the container works, you can copy-pa…

Having coded C# for many years now, generics are used for a lot more than just containers. There's a great many things that can be generalized. Just look at any large C# project on GitHub.

Re: Notes on the Go2 Generics Draft

#73

Post by int_19h »

nemo1618 wrote: post #24

I'm glad I'm not the only one sad to see generics invading a perfectly good language. Programmers love generics because they enable higher-order abstractions, and programmers love abstractions -- code that isn't DRY is like an itch we need to scratch. Programmers also hate special cases, because they feel restrictive and inconsistent: I recall quite a few people protesting that Go's 'range' keyword shouldn't be restr…

I don't get this idea why generics are perceived as some kind of a fad that's opposite to pragmatic coding practices. I mean, they were in the original (1983) Ada - hardly a language known for its cowboy attitude, general laxity, or "clever code".

Re: Notes on the Go2 Generics Draft

#74

Post by euyyn »

cyphar wrote: post #21
laumars wrote: post #5

Earlier quoted context omitted.

I keep hearing people say things like "the Go team are changing their position" but I think what a lot of people missed is that the Go team were never against implementing generics in version 2. Quite the opposite in fact as they actually often said it was a consideration for Go v2. What they repeatedly opposed was rushing generics into a v1.x build as that could break things. The real issue is that many of the "hate…

> hate using that term but it really was largely just individuals who decided that didn't like Go from the outset anyway so weren't exactly day to day Go developers I'm a day-to-day Go developer and maintain some of the most widely used Go projects out there. While I understand their wish to do things "slow and steady" there were several other missteps and double-downs by the language designers that left me with a bi…

Why do you think, from your experience, it is not a systems programming language?

Re: Notes on the Go2 Generics Draft

#75

Post by nicoulaj »

jy3 wrote: post #60
civility wrote: post #57

Earlier quoted context omitted.

Writing the exact same code for float and double (and possibly complex float and/or complex double) sucks. You've created some straw man about dopamine junky programmers because you don't need generics for whatever it is you do. If you wrote numerical algorithms you'd be annoyed at any language which lacks generics.

That means Go is not the right tool for you. Don't use it. It's so sad to see people pushing to radically alter a language that they will probably never use because it will never be suitable for their needs.

So what is the use case for Go exactly ? Programs that don't need to put numbers in containers ?

Re: Notes on the Go2 Generics Draft

#76

Post by zoul »

baby wrote: post #68
nemo1618 wrote: post #24

I'm glad I'm not the only one sad to see generics invading a perfectly good language. Programmers love generics because they enable higher-order abstractions, and programmers love abstractions -- code that isn't DRY is like an itch we need to scratch. Programmers also hate special cases, because they feel restrictive and inconsistent: I recall quite a few people protesting that Go's 'range' keyword shouldn't be restr…

Same here, as a security consultant reading Golang is always a pleasure. I'm pretty sure that the strongest codebases I've seen were in Golang just because of how easy it is for everyone to read the code and actually spend time looking for logic bugs instead of trying to understand what is happening. Developers love to be able to write their magical code and their clever abstractions and often forget that their code…

Developers love to be able to write their magical code and their clever abstractions and often forget that their code is paying the price by becoming less clear and less readable.

Are you saying that it has to be that way with generics? Because I would disagree with that. Cautiously applied, generics can make your code more clear, more readable and, most importantly, more type safe – and not just because of containers, see Swift’s key paths for an example.

Re: Notes on the Go2 Generics Draft

#77

Post by giovannibajo1 »

pjmlp wrote: post #53
sethammons wrote: post #39

Earlier quoted context omitted.

> No exceptions Well, apparently Go _is_ an exception. It lacks what you point out and is, undeniably, a successful language.

How much would had it achieved if it didn't had the Google logo to go along it? Lets say developed at SV startup XYZ instead.

There’s precedent that Google’s brand doesn’t make people magically swallow programming languages without thinking: Dart.

I think it’s disingenuous to reduce Go success to some Google marketing operation. I dislike Google as a brand in the way they design products and their weak privacy stance, but I love Go nonetheless.

Re: Notes on the Go2 Generics Draft

#78

Post by mcguire »

pjmlp wrote: post #53
sethammons wrote: post #39

Earlier quoted context omitted.

> No exceptions Well, apparently Go _is_ an exception. It lacks what you point out and is, undeniably, a successful language.

How much would had it achieved if it didn't had the Google logo to go along it? Lets say developed at SV startup XYZ instead.

Or any of the other languages Pike has been involved with?

Re: Notes on the Go2 Generics Draft

#79

Post by bodas »

jy3 wrote: post #61
jahaja wrote: post #51

I'm a bit sad about the lack of acceptance for pluralism in widely used languages. The effort to get Go in line with other languages just seem so disproportional.

Reading HN, it feels like some people just want every language to have the same features and have them implemented the same way. Sad indeed.

Go is a tool, it's not a religion. People are allowed to criticise it, and they don't have to temper their criticism just because the Go team or Go users have a different opinion. Go is made by Google it's not like it's some kid's school project.

Re: Notes on the Go2 Generics Draft

#80

Post by cyphar »

laumars wrote: post #67
cyphar wrote: post #21

Earlier quoted context omitted.

> hate using that term but it really was largely just individuals who decided that didn't like Go from the outset anyway so weren't exactly day to day Go developers I'm a day-to-day Go developer and maintain some of the most widely used Go projects out there. While I understand their wish to do things "slow and steady" there were several other missteps and double-downs by the language designers that left me with a bi…

Yeah I've written some systems type stuff in it as well such as a UNIX shell and FUSE file systems. So Ive played around with syscalls and the sort in Go and frankly I'm inclined to agree with you there. I mean sure you can use Go as a systems language (as we have proven) but that doesn't mean it's the best suited language for that particular type of application. However I don't think that's so much an issue with the…

From a practical standpoint, you're right that the biggest issues are green threads (which had many issues where runtime.LockOSThread didn't actually do what it said on the tin -- making it impossible to use for certain namespace syscalls) and the memory management sometimes having "issues" (I found a bug several years ago where it looked like the memory manager would not free memory but would use MADV_DONTNEED -- which is less efficient than free -- but then wouldn't reuse said memory which meant that the process was killed by the kernel eventually due to memory overcommitment).

The other stuff is mostly icing on the cake in terms of whether the language is painful to use -- and having no generic container types is a perfect example of a day-to-day pain. Every time you have to sort a slice you need to implement sort.Interface (or nowadays you can use sort.Slice -- but that requires casting your slice to the right interface which requires allocating a new slice to get around missing type information).

Post reply on HN