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

Generics enabled by default in Go tip

go-review.googlesource.com

Post reply on HN
Print view View original

171–180 of 378 posts

Re: Generics enabled by default in Go tip

#171

Post by pjmlp »

kbenson wrote: post #160
silisili wrote: post #9

Not to be contrary for its sake, but I'll say this is one change I'm really not happy about. I feel like it's a change to placate many, while driving a lesser amount away. Which is fine, but still feels like the end of something, as I am one of the aforementioned 'lesser.' As for why...I love above most the simplicity and readability of Go. Any change which encroaches that, which this does, is a net negative to me.

Either a language changes to keep interest up and bring in a new audience, or it's left behind by advances to and the status quo (and what's considered a minimum set of features) and stagnates. Just look at Perl. Stuff written 20 years ago is likely to work without change on the newest release more often than not. For certain work contexts, like system utilities and long life core programs, this can be amazingly usef…

For some strange reason many developers lose sight that programming languages are software products just like anything else than one can sell for installing into a computer.

While FOSS might have changed the way to sell those products, they are still products looking for attention, market share, ecosystems, conference talks, consultancy, trainings.....

Re: Generics enabled by default in Go tip

#172

Post by erik_seaberg »

mseepgood wrote: post #159
pkulak wrote: post #150

Earlier quoted context omitted.

Does Go generics have type erasure? If not, OP can expect and even better journey.

No, they don't have type erasure.

Go is getting monomorphization, separate machine code for each type specialization of a generic function. I assume reflection will choose the one for the args you want to pass, or make you do that.

Re: Generics enabled by default in Go tip

#173

Post by pjmlp »

coryrc wrote: post #65
tptacek wrote: post #23

Earlier quoted context omitted.

You wouldn't. Everybody goes into Go thinking that's absurdly confining. Some significant subset of Go programmers learn that they instead find it liberating. Programming is programming; you have an overwhelming number of degrees of freedom no matter what language you work in. It sometimes turns out that taking some of those degrees out of the language makes it easier to focus them on your problem domain.

Yeah, that's why Kubernetes had to develop code generators. So focused.

That made that to themselves, the original prototype was in Java and changed to Go thanks to some recently joined team members that were very munch into Go.

Re: Generics enabled by default in Go tip

#174

Post by valenterry »

Two thoughts:

1.) In a "simple language" (e.g. without generics) each line of code is easy to read/understand. But reading/understanding the whole program or application is difficult. In "not-simple languages" it's the other way around.

2.) An important criteria to judge the future of a language is how foresight the language authors have. I read that the go authors said in the past that they were not ready to add generics because they didn't know how to do so in a good way. True or not, retrospectively adding generics is not a great indicator for good language design to me. Even if the addition of generics is a net-positive thing, I expect that Go will go in the direction of C++, having a lot of accidental feature complexity in the language.

I think it's better to do it like Lisp and keep a simple (but nonetheless flexible) core. Or do it like Haskell and design the language to elegantly allow as much abstraction as possible, moving carefully towards that goal. For these kind of languages, you better have people who have years long experience in exactly this: designing powerful programming languages. A developer can be the best in their own field, but they are doomed to fail when trying to build a future-proof, well designed programming language on their first attempt. (btw, not relating to the Go author's here)

An example where this didn't work is Angular - from the first moment that I got in touch with it, I knew it was built by amateurs. It's only a framework, but the difference to a programming-language is minor in the case of these kind of all-encompassing frameworks. It is not surprising to me at all that the completely redesigned Angular later on.

Re: Generics enabled by default in Go tip

#175

Post by Gibbon1 »

rustc wrote: post #86
jshen wrote: post #51

Earlier quoted context omitted.

Learning things outside of complex computer science topics often adds more value to the world. The ability to write useful programs without dedicating ones life to esoteric comp sci topics is a net positive for the world.

Are generics really considered as "esoteric comp sci topics"?

I needed to use C# for some project. Used generics without actually being aware what they were. Helps that C# implements generics without type erasure.

Re: Generics enabled by default in Go tip

#176

Post by SamReidHughes »

puddingforears wrote: post #165
SamReidHughes wrote: post #126

Earlier quoted context omitted.

Linked lists are the one data structure that you never end up wanting a generic version of. They aren't really used as containers. (Except badly.)

They’re the easiest stack structure to implement. All your operations are against the head of the list and you either have a thing, don’t have a thing, or add a thing. I’d like to be able to maintain a stack of things whose types I don’t have to manually reify and erase. That’s not a tall order, and it’s certainly not “complexity”. It’s markedly weird that I can’t have that same structure and associated operations be…

If you want a stack you'll just use a growable array (in Go, a slice). A linked list is suboptimal.

Linked lists serve a real purpose in some situations where you really do want O(1) behavior. One example is when you are performing the operation while holding a mutex. But it's never the sort of thing where the right tool is a linked list generic container.

Re: Generics enabled by default in Go tip

#177

Post by tptacek »

takeda wrote: post #152
tptacek wrote: post #146

Earlier quoted context omitted.

I don't follow. I use unsigned ints in Go all the time. I've never been in a world of hurt with them. Mandatory explicit integer conversions (and the way Go consts work) are something Go gets right.

Ok, so you like that. I myself really hated when I used float32 and had to do this when I was doing calculations: result = (float32)Max((float64)a, (float64)b) I ended up switching the type to float64, and wonder why they even offer float32 if it's practically unusable. I had similar experience when I needed to use int8 or int16 etc. An alternative was to make own version of Max/Min and other math functions, but this…

I'm not sure I follow, because Rust is also (thankfully) fussy about integer types.

Re: Generics enabled by default in Go tip

#178

Post by Gibbon1 »

anothernewdude wrote: post #156
silisili wrote: post #9

Not to be contrary for its sake, but I'll say this is one change I'm really not happy about. I feel like it's a change to placate many, while driving a lesser amount away. Which is fine, but still feels like the end of something, as I am one of the aforementioned 'lesser.' As for why...I love above most the simplicity and readability of Go. Any change which encroaches that, which this does, is a net negative to me.

No generics, and lack of error handling are why I bounced off Go. Can I write a generic data structure? No. You have to cast from interface{}. Java 1.4.2 is dead, and rightly so. And manual error checking? No. Get that garbage out of my control flow. I'm not going to a language that has worse error handling than C. At least in C you can factor it out.

Writing stuff in C... one thing I would like is an error return keyword. And the ability to set how you'd like unhanded errors to be dealt with. Like unhanded error means program aborts. Let the programmer decide how sloppy he wants to be.

Re: Generics enabled by default in Go tip

#179

Post by rustc »

silisili wrote: post #145
AnimalMuppet wrote: post #79

Earlier quoted context omitted.

You sound like, for you personally, generics are like a poison atmosphere. You simply can't live in that environment. Why? Why so negative? I work in C++. Generics exist there. I don't use them except for some STL containers. I just... don't use them. I don't have problems where I need them. How does it hurt me if they exist? You may say that someone else will use them, and make your code more unreadable. They may, b…

I don't mean to be negative only, and appreciate your reply. But I know what happens in real codebases. Before long, scammy tutorials pop up showing Go as an essentially dynamic language, and that's what bootcampers write. As of today, they are forced to write simple, boring code. I never mind a carefully added thing, for carefully thought of situations, as this probably was. The problem is that I see the abuse from…

> Before long, scammy tutorials pop up showing Go as an essentially dynamic language

Sorry are you saying adding generics to Go makes Go closer to dynamic languages? Shouldn't that be the opposite?

> I knew a person who insisted on a lot of things when working in a Go code base...one of which was mixed typed tuples. It was ugly, awful code of interfaces all the way down. It's ugly and Go let you know that. A voice of reason would say...what are you doing? That's not how you do it in Go.

Do you have an example of this (code)? What's wrong with tuples with elements of different types? What's the alternative?

Re: Generics enabled by default in Go tip

#180

Post by mseepgood »

masklinn wrote: post #142
mseepgood wrote: post #106

Earlier quoted context omitted.

They can simplify code, but they don't simplify the language.

The langage which already had generics except special-cased to builtins the langage authors really wanted to be generic and they know better than the peons so they have the intellectual capacity to make this determination?

you sound bitter
Post reply on HN