Live data from Hacker News

Why Generics?

blog.golang.org

161–170 of 261 posts

Re: Why Generics?

#161
post #30

Earlier quoted context omitted.

C++ solves all problem that can be solved with Go, but with a lot more features. Why are we not using C++ where Go is currently being used? By your logic, this shouldn’t be the case.

I'm pretty sure C++ is used for exactly the game thing Go is used for. And C++ is used for a lot of other things as well. In fact, you will probably have trouble finding a problem that wasn't solved by C++ by somebody. Scientific computing, server process, CRUD applications, embedded applications, AI, graphics, programming languages, libraries, etc. C++ has a lot more features and therefore it's actually able to be u…

I don't think it's the feature-set that makes C++ viable for more situations than Go. In my opinion that's only because Go uses managed memory. That takes part of the runtime behavior of the code out of the hands of the programmer. This counts out Go for situations where you need precise control over runtime behaviour.

That said; C++ is a ridiculously complicated language. I don't get why people think that Rust is difficult.

Re: Why Generics?

#162
post #150

Earlier quoted context omitted.

My work is a Ruby/JS shop, and we have some Go in production as well. We definitely need a little hand holding to ramp anybody new up on the Go codebases. In many cases our devs haven't used types, pointers or any equivalent of goroutines & channels. I've written just barely enough Rust to say there are even more concepts that would be new to my team. Even with Go being comparitvely simpler, I could go either way on…

> In many cases our devs haven't used types, pointers or any equivalent of goroutines & channels. How do you manage to get a job as a developer without having ever learned this stuff? Are these people that are just self taught straight to javascript / ruby? I mean, are CS course nowadays so bad that students come out of them without understanding things like type-theory, pointers etc

To be honest, this response feels a bit aggressive and dismissive to me.

Many of my coworkers (myself included) entered the profession through bootcamps. Others came up during the PHP/Wordpress to Ruby/Rails era of web development, and never had a reason to learn languages like C++ or Java. I don't think there's anything to make fun of, or apologize for in this scenario.

Re: Why Generics?

#163
post #91

Earlier quoted context omitted.

Must every popular language evolve into C++ or Common Lisp?

I wonder if there's room for a language that is small, allows for nearly limitless abstraction, and still has great tooling. Go is (or, you could argue, was) small, and now has better tooling, but is just beginning to increase its ability to create abstractions. Common Lisp is large (only 200 pages fewer in its spec than C++, if I remember correctly), has unparalleled tooling (like the don't-unwind-the-stack debuggin…

It's called Smalltalk.

Re: Why Generics?

#164

It might be fun to share my viewpoint from an angle that's probably fairly unique. I've started a number of large, highly deployed Go projects: Terraform, Vault, Packer, Consul, Nomad, and numerous libraries and other things. I started a company that employs hundreds of full time Go developers. Go has been one of our primary languages since Go 1.0 (and I used it prior to that). Let me start by saying that there are _…

I see the use for generics all the time. I came from Ruby, where we have enumerable so you get standard constructs like map, find, first, last, each_cons, etc. Because Go lacks them, people constantly reimplement these things with less intention-revealed code using ad hoc for loops. Ugh.

Thus you see very little use of collection pipelining in Go. https://martinfowler.com/articles/collection-pipeline/

Generics are such a powerful and useful idea. Bring it on.

Re: Why Generics?

#165
post #143
post #50

Earlier quoted context omitted.

I'm a little surprised the word 'mixin' appears nowhere in that article. Josh Bloch argued against the interface solution in Java (and in particular, read-only versus read-write interfaces), claiming there would be too many interfaces and it would confuse users, and that didn't sit right with me. To me it's his second-biggest sin against Java, and it's tied to the first. The only truly unforgiveable one is Unsupporte…

> The only truly unforgiveable one is UnsupportedOperationException. The guy who wrote the collections API for Java didn't know the first thing about the Liskov Substitution Principle, and gave the world an implementation that violates it... The implementation perfectly follows it because the LSP simply requires identical behavior, and the contract clearly states it may[1] throw an exception. All the implementations…

No they most definitely are not. One implementation receives a message. The other categorically rejects it. I cannot substitute them.

Re: Why Generics?

#166

Earlier quoted context omitted.

Inheritance makes generics difficult. For instance, if A If you are just reading the array, you would want Array[A] This problem doesn't come up in ML style languages because they do not make use of inheritence.

It comes up in Scala. The solution is to have notation to specify the variance of types.

Yes, though Scala can hardly be an example of simplicity.

Re: Why Generics?

#167

The decision to overload parentheses to express generic type is the only part of this spec I find nauseating. It doesn't scan well, and doesn't have a precedent in any major generic implementation I'm aware of. <, [, @-annotation... I don't care. Just don't mush it into the function declaration with the same syntax that encloses parameter.

So much this.

Re: Why Generics?

#168

Earlier quoted context omitted.

> because all existing implementations are bad I'm also not sure why in OOP-land, generics are this crazy experimental weird feature, when in functional languages, people figured out how to implement parametric polymorphism (the original term for generics) in quite reasonable ways. I get that subtyping adds some complexity, but overall I don't understand why such a basic way to build abstractions is so controversial…

Inheritance makes generics difficult. For instance, if A If you are just reading the array, you would want Array[A] This problem doesn't come up in ML style languages because they do not make use of inheritence.

Why in the case of writing to the array would you want Array[B] < Array[A]?

Re: Why Generics?

#169
If I'm understanding correctly, contracts are a way to implement compile time duck typing? If that's the case I think its a pretty neat twist on generics.

Re: Why Generics?

#170
post #102
post #50

Earlier quoted context omitted.

I'm a little surprised the word 'mixin' appears nowhere in that article. Josh Bloch argued against the interface solution in Java (and in particular, read-only versus read-write interfaces), claiming there would be too many interfaces and it would confuse users, and that didn't sit right with me. To me it's his second-biggest sin against Java, and it's tied to the first. The only truly unforgiveable one is Unsupporte…

> Rot in hell forever, Josh. And take your Effective Java with you to throw on the pyre. Well that seems uncalled for.

It’s fairly difficult to come to terms with an “everything was going pretty well until...” moment and doubly so when it can be personified.

Once we broke LSP, a cascade of similar ideas started showing up with regularity, especially in J2EE. I used to be able to go on at some length but now it’s more “I hope I never meet this guy because it’ll be awkward as hell.”

Post reply on HN