Live data from Hacker News

Toward Go 2

blog.golang.org

611–620 of 670 posts

Re: Toward Go 2

#611

Earlier quoted context omitted.

Counting the weasel words.... 1. "might be" 2. "not entirely inaccurate" 3. "perhaps others" 4. "things like" 5. "the's reason to believe" 6. "apt enough" And that's just in your first sentence. My impression has always been that the Go core team is very open to the possible addition of generics, but also very wary of the very real downsides that generics have. Nothing I've ever seen from Rob or other core team membe…

> And that's just in your first sentence. Yeah, god forbid someone is not absolute in their statements, but gives the benefit of the doubt. I'd say it only counts as "weasel" word when you don't say what you mean to say or want to hide your true intention/reality. But, for all the "maybe" etc, the parent made clear what he thinks: that the Go team doesn't care about Generics. He's not going two ways about it, for thi…

Have you given Nim a look? It sounds like it would be perfect for you. :)

Re: Toward Go 2

#612

Earlier quoted context omitted.

Counting the weasel words.... 1. "might be" 2. "not entirely inaccurate" 3. "perhaps others" 4. "things like" 5. "the's reason to believe" 6. "apt enough" And that's just in your first sentence. My impression has always been that the Go core team is very open to the possible addition of generics, but also very wary of the very real downsides that generics have. Nothing I've ever seen from Rob or other core team membe…

> And that's just in your first sentence. Yeah, god forbid someone is not absolute in their statements, but gives the benefit of the doubt. I'd say it only counts as "weasel" word when you don't say what you mean to say or want to hide your true intention/reality. But, for all the "maybe" etc, the parent made clear what he thinks: that the Go team doesn't care about Generics. He's not going two ways about it, for thi…

[deleted]

Re: Toward Go 2

#613

Here be Opinions: I hate generics. also, I hate exceptions. Too many people are wanting "magic" in their software. All some people want is to write the "Happy Path" through their code to get some Glory. If it's your pet project to control your toilet with tweets then that's fine. But if it's for a program that will run 24/7 without human intervention then the code had better be plain, filled with the Unhappy Paths an…

As erlang shows, quite the contrary. If you want your code to stay up and running you should concentrate on the happy path, bulkhead and let it crash.

I advice to read about Human Factors and Complex Systems engineering. You will be surprised.

Re: Toward Go 2

#614

Earlier quoted context omitted.

> "how do we implement this in the best way?" They asked for use cases from a wide range of people to ensure they implement it in the best way. Subtly different, but essentially the same request. > I have a hard time believing that code at Google is so incredibly "special" that they need a special kind of generics. I didn't say they need special generics. I said the approach that works best at Google may not be the b…

> They asked for use cases from a wide range of people to ensure they implement it in the best way. Subtly different, but essentially the same request. Phrasing is important, and obviously (from the reactions of me and others in the thread) the phrasing was way off and perceived as condescending and lazy. > I didn't say they need special generics. I said the approach that works best at Google may not be the best appr…

> Phrasing is important, and obviously (from the reactions of me and others in the thread) the phrasing was way off and perceived as condescending and lazy.

Maybe, but I don't know that we should be attacking someone's poor communication ability. I'm sure I've misunderstood at least one of your points too. Let's just focus on what was actually asked for: Use-case examples.

> OK, so you said they don't need a special generics, but then say that they do.

There isn't an all encompassing 'generics'. Generics is a broad category of different ways to achieve reusable statements across varying types, in a type-safe manner. To try and draw an analogy, it is kind of like functional and imperative programming. Both achieve the function of providing a way to write programs, but the paradigms differ greatly. Each with their own pros and cons.

If imperative programming is the best choice for Google, that doesn't mean the community wouldn't be better served by functional programming, so to speak. And when it comes to generics, there are quite a few different paradigms that can be used, and not easily mixed-and-matched. They are asking for use-cases to determine which generics paradigm fits not only the needs at Google, but the needs everywhere.

> Also: ASK GOOGLE.

The Go team is Google. They have asked Google. Now they are asking everyone else. I'm not sure how to make this any more clear.

> Either Google is important enough to it in a way that works for them, or the community is more important and they get to choose.

In the past Google was seen as the most important, and they have been widely criticized for it. This is them moving in a direction that favours the community. And they are still being criticized for it... Funny how that works.

Re: Toward Go 2

#615
post #442

I should send this to rsc, but it's fairly easy to find examples where the lack of generics caused an opportunity cost. (1) I started porting our high-performance, concurrent cuckoo hashing code to Go about 4 years ago. I quit. You can probably guess why from the comments at the top of the file about boxing things with interface{}. It just got slow and gross, to the point where libcuckoo-go was slower and more bloate…

For (2), are you looking for overloading arithmetic operators (+, -, etc.)? Do people normally consider that under the umbrella of "generics"? For (1), for curiosity sake, I tried benchmarking the cuckoo.go file you posted. I'm curious if these numbers are in line with what you found. The first test I did was a Rand test, Putting 10,000 random string values under random string keys, then Getting the same 10,000 keys,…

> For (2), are you looking for overloading arithmetic operators (+, -, etc.)? Do people normally consider that under the umbrella of "generics"?

Overloading is usually not a "generics" concern in most mainstream languages[1]. If you do a "type class"/"Rust-style-traits" (or even multiclasses) thing then it sort of naturally takes a front seat. Incidentally, Haskell fucked this one up horribly in some respects, see the "Num" type class.

Of course, e.g. Java could theoretically add an interface called Addable to complement Comparable which would sort-of allow generic "+", but they've chosen to not opt for that. The fact that the "first parameter" is privileged is also a bit of a detriment to such syntax conveniences. (I can expand on this, but it's bascially because that for "X op Y" and "Y op X" to work, they both need to know of each other. This problem can be solved by type classes, but cannot be solved by overloading, AFAIK.)

[1] If you do have overloading from the outset (like Java, IIRC), then you're constrained because you need to be able to "pick the most specific overload" in a "generic" context.

Re: Toward Go 2

#616
post #531

Earlier quoted context omitted.

I can sympathize with the dislike of exceptions. I very much prefer Rust's error handling model (return Result ) The fact that Go has had this much success without generics is mind-boggling to me.

Because Google. Go is quite similar to Limbo, by some of the same authors, how much success did it have outside AT&T?

Limbo was not freely available.

Re: Toward Go 2

#617
post #616
post #531

Earlier quoted context omitted.

Because Google. Go is quite similar to Limbo, by some of the same authors, how much success did it have outside AT&T?

Limbo was not freely available.

Vita Nuova has it on an open source license since March 2000, which means it has been freely available for the last 17 years!

Re: Toward Go 2

#618

Earlier quoted context omitted.

No. Unless someone finds a quote, the low order bit is that they didn't use the word "fuck" or any other swear word at all. You can't use the word "fuck" to accurately quote someone who didn't use that word.

Take a look at this article/talk https://commandcenter.blogspot.com/2012/06/less-is-exponenti... He's explicitly rude. Sets up a strawman argument with the developer who can't imagine programming without generics. Mocks the people who want generics. Gasps in faux disbelief that it could be solved by types. And then, when he goes in for the kill, to show once and for all that generics are pointless garbage: He attacks…

Rich Hickey's Tweet came to mind:

If you think you know how I ought to spend my time, come over and mow my lawn while I expound on the problems of dev entitlement culture.

I'm fine with RSC, Commander Pike, and those other benevolent dictators continuing to make much better decisions that I certainly ever would and more importantly to be super careful with what they add to the language. I write Swift, JS, objC, and Go. Go is the preferred language because it's simple and I have the entire SDK in my head.

I use Go a lot. I can't say i've ever run into not having generics being a huge deal.

Let's face it, for most programmers out there, generics is for type safe collections. If slices and maps weren't built into Go then i'd prolly have moved to something else.

That said i'd like to see more built in data structures

Re: Toward Go 2

#619
post #609

Earlier quoted context omitted.

This all depends on what "the job" being done well enough is. You can't use a research paper to refute the experience of the many programmers who successfully use for loops to get their work done. That's a statement about usability, not expressiveness. If you want to show something else is easier to use, you'd have to do a user study, and even that's not going to be universally applicable since it depends on the prev…

Interestingly there are user study, mainly on kids. They all show that the natural expression is through declarative programming and that for loop are never what comes naturally.

Interesting. Links?

Re: Toward Go 2

#620

Earlier quoted context omitted.

> They asked for use cases from a wide range of people to ensure they implement it in the best way. Subtly different, but essentially the same request. Phrasing is important, and obviously (from the reactions of me and others in the thread) the phrasing was way off and perceived as condescending and lazy. > I didn't say they need special generics. I said the approach that works best at Google may not be the best appr…

> Phrasing is important, and obviously (from the reactions of me and others in the thread) the phrasing was way off and perceived as condescending and lazy. Maybe, but I don't know that we should be attacking someone's poor communication ability. I'm sure I've misunderstood at least one of your points too. Let's just focus on what was actually asked for: Use-case examples. > OK, so you said they don't need a special…

> There isn't an all encompassing 'generics'. Generics is a broad category of different ways to achieve reusable statements across varying types, in a type-safe manner. To try and draw an analogy, it is kind of like functional and imperative programming. Both achieve the function of providing a way to write programs, but the paradigms differ greatly. Each with their own pros and cons.

Yes, thank you. Everybody in this thread already knows that. PICK ONE.

(EDIT: I should also add: Since Go is structually typed and has mutable variables, that should be a good indication of what to do and what not to do. See e.g. Java arrays, variance and covarince.)

> If imperative programming is the best choice for Google, that doesn't mean the community wouldn't be better served by functional programming, so to speak. And when it comes to generics, there are quite a few different paradigms that can be used, and not easily mixed-and-matched. They are asking for use-cases to determine which generics paradigm fits not only the needs at Google, but the needs everywhere.

And now you're trying to bring imperative vs. functional into this?

I think IHBT... and this really is my last comment in this thread. Have a good $WHATEVER.

Post reply on HN