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

A Proposal for Adding Generics to Go

blog.golang.org

Post reply on HN
Print view View original

211–220 of 273 posts

Re: A Proposal for Adding Generics to Go

#211

Post by brundolf »

philosopher1234 wrote: post #206
brundolf wrote: post #198

Earlier quoted context omitted.

It's the subjective impression I've formed from, among other things, reading articles like this: https://fasterthanli.me/articles/aiming-for-correctness-with... Ctrl+F for "Let's start with Go" to jump to the relevant part

FWIW I would take fasterthanli.me with a grain of salt. The guy is a serial Go hater. His points stand on their own, but I don't think he appreciates Go's benefits. I think "A Philosophy of Software Design," Rob Pike's talks, or Russ Cox's blog posts are a good place to look if you want to understand what is valuable about Go and the reason to believe it would actually scale very well to large codebases.

Thanks for the references, I'll look at what the other side has to say

I am aware that fasterthanli.me can be a bit, shall we say... opinionated. Though as you say, his points do stand on their own. I can see the things he points out about the design philosophy of Go's language features and standard library and draw parallels to languages and libraries that I've used firsthand, and had firsthand frustrating experiences with when it came to navigating their magical behavior and lack of enforcement of contracts. But I'll keep an open-mind

Re: A Proposal for Adding Generics to Go

#212

Post by daypay »

Varriount wrote: post #97
systemvoltage wrote: post #92

Side tracking a bit: I wish there was a popular programming language like Go with rust-like package manager, Python style syntax and ability to hack, compilable, classic (classes, methods), and fast. Or I wish Go had classic OOP and raise Exception methods. Basically, I want fast statically typed python with better package management. Or other way to put it, I want Go with classic OOP and Exceptions.

You might be interested in Nim ( https://nim-lang.org ). I can't say that it's very object oriented, but it is very flexible.

Been using Nim for a few projects lately, absolutely love it.

Re: A Proposal for Adding Generics to Go

#213

Post by philosopher1234 »

Jtsummers wrote: post #209
philosopher1234 wrote: post #194

Earlier quoted context omitted.

Wrappers that don't wrap very much aren't worthwhile IMO. Its like getting an amazon box with a fedex box inside. Just give me the package itself.

Shallow wrappers that don't wrap much (now) but convey intent better are valuable if you buy into the idea of modularity and encapsulation in general. Some reasons (probably more out there): 1. The now-provided interface can more clearly express what the code is intending to do (better names for the operations you're providing than the underlying system has, remove_from_end to pop or dequeue ) 2. Hide methods of inte…

Wrapping to hide is valuable, but wrapping has a cost which is generally underrated. Every wrapper is a thing itself which must also be understood when trying to understand how things work. And every wrapper is a division between blocks of code, meaning if you have changes which impact multiple layers of wrap, its harder to determine what to change, and to maintain the understandability of each layer.

For this reason im an advocate of lazy wrapping. Create an abstraction at the last moment, when its painfully obvious what benefit it will provide, when you can see how it ties together disparate pre-existing code blocks, and when you have the highest confidence that it will stick and not need to be unwrapped next week by the senior dev.

Re: A Proposal for Adding Generics to Go

#214

Post by karmakaze »

sam_lowry_ wrote: post #123
stickfigure wrote: post #99

Earlier quoted context omitted.

I remember thinking something similar about my Java 1.4 codebase back in the early 2000s. It's fine, right? What could I be missing? The answer is: A lot.

I miss Java 1.4. It was small and concise. Java 5 added so much that none knows all of it. Just look at the length of Java Generics FAQ. It's hilarious.

Java before 5 wasn't a language, it was a library and number of jvm implementations. It wasn't until Java 5 that there was a memory model spec that defined how stuff was supposed to work.

Re: A Proposal for Adding Generics to Go

#215

Post by neetle »

enneff wrote: post #177
jacques_chester wrote: post #136

Earlier quoted context omitted.

It doubles down on Go's assumption that git repository === a proper package/module system. It mixes up URLs and URNs. If your git repositories aren't tagged just so , then go mod throws its hands up and simply invents a whacky snapshot version. Because it can't itself properly determine "earlier version" from "later version" on that snapshot, you often wind up with multiple snapshots from the same repo, not infrequen…

> you often wind up with multiple snapshots from the same repo Either I’m misunderstanding you or you’re mistaken. You can’t have multiple versions of the same module in a go build.

_Technically_ you're right. Go considers v0/v1 to be a distinct module from v2. Most people would consider this to be the same module, but Go doesn't. If you want to know more, you can go read the manifesto released by the maintainers about how this is "the best thing ever".

If you never tag v1, you'll never have to deal with it.

Re: A Proposal for Adding Generics to Go

#216

Post by philosopher1234 »

brundolf wrote: post #211
philosopher1234 wrote: post #206

Earlier quoted context omitted.

FWIW I would take fasterthanli.me with a grain of salt. The guy is a serial Go hater. His points stand on their own, but I don't think he appreciates Go's benefits. I think "A Philosophy of Software Design," Rob Pike's talks, or Russ Cox's blog posts are a good place to look if you want to understand what is valuable about Go and the reason to believe it would actually scale very well to large codebases.

Thanks for the references, I'll look at what the other side has to say I am aware that fasterthanli.me can be a bit, shall we say... opinionated. Though as you say, his points do stand on their own. I can see the things he points out about the design philosophy of Go's language features and standard library and draw parallels to languages and libraries that I've used firsthand, and had firsthand frustrating experienc…

Certainly. As a counter-example to the pain of implicit functionality, take the UNIX file API. `open(1), write(1), close(2)...` represent hundreds of thousands of lines of code, spanning network devices, local file storage, integrity checking, and who knows what else, and all of it is hidden. It is precisely the mountainous heap of implicit behavior that gives these APIs value.

That being said, APIs with implicit function that are broken or surprising are painful, but I take this not as an indictment of implicit function, but as an indictment of buggy APIs. I think state and hidden functionality is the essential ingredient of highly useful code.

Re: A Proposal for Adding Generics to Go

#217

Post by mikepurvis »

recursive wrote: post #143
mikepurvis wrote: post #105

Earlier quoted context omitted.

New concepts, yes, but I think anyone who has spent any significant time programming in C++ will immediately recognize the problems that they are solving and how the solution works. That significantly eases the learning curve in my opinion.

But we weren't talking about those who had spent significant time working in C++.

Okay, fair. For myself, I'm coming from extensive experience in both Python and C++, and although I'm admittedly still in the honeymoon phase, my assessment so far is that Rust is an excellent union of the two.

Basically I get the high level abstractions and package management that I expect from Python, while inheriting a set of tools that help finally realize some of the high performance, zero-copy idealism of C++ (slices, lifetimes).

Re: A Proposal for Adding Generics to Go

#218

Post by karmakaze »

oefrha wrote: post #13

Related earlier discussions: - https://news.ycombinator.com/item?id=20576845 (2019 draft) - https://news.ycombinator.com/item?id=20541079 (also 2019 draft) - https://news.ycombinator.com/item?id=23543131 (2020 draft, i.e. the base version of the current draft)

Also the video[0] linked in the post seems to be ~Dec 2020 which is new to me.

[0] https://www.youtube.com/watch?v=TborQFPY2IM

Re: A Proposal for Adding Generics to Go

#219

Post by qsort »

AlphaSite wrote: post #129
anderspitman wrote: post #110

Earlier quoted context omitted.

I've used Java and Go. I find Go a far superior experience. Part of that is the standard library which seems to strike a perfect balance providing what you need but not too much. I also think a lot of it has to do with the culture of the languages. Kotlin is a pretty nice language, but using it for Android still makes me want to hit my computer with a hammer because the over-abstraction of the Java ecosystem is madde…

I was under the impression modern Java was becoming more functional than more OO (or at least de-emphasising inheritance).

That's definitely the path they're headed towards. @FunctionalInterface from Java 8 and type-inference from Java 11 and instanceof destructuring from Java 14 are the big changes. "Proper" modern Java is functional, at least at the surface level.

The big issue is that the ecosystem is kind of stuck; it's freaking 2021 and we're still targeting Java 8. Also the type system could be better, null references are everywhere even though there is Optional (I wish it had optional strict null checks a la Typescript, but I'm not sure how realistic that is), and the fact that you can't have List because generics won't work on primitives is just boneheaded.

But yeah, the language isn't the "Dog extends Animal" bullshit they teach you in school, at least not anymore.

Re: A Proposal for Adding Generics to Go

#220

Post by ianlancetaylor »

djhaskin987 wrote: post #102

Would someone mind enlightening me as to what the difference is between this draft and the 2020 draft.

Very little. The announcement here is not a new draft, it is starting the formal proposal process for adding type parameters to the language.
Post reply on HN