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

Toward Go 2

blog.golang.org

Post reply on HN
Print view View original

51–60 of 670 posts

Re: Toward Go 2

#51

Post by Touche »

Spiritus wrote: post #36
solomatov wrote: post #18

Earlier quoted context omitted.

I would start using Go in my projects if it introduces generics. It's a show stopper for me.

The question is _why_ do you need generics, for what use case(s), etc? Saying “I need generics otherwise I won’t use Go” is exactly the type of feedback they don’t want. It seems like you’d have valuable feedback given that it’s a “showstopper” for you.

Do you not see how this is an insulting question? You know very well the use cases for generics. You do not need users to present new ones. You can literally Google "generics use cases" and get hundreds of thousands of results that directly answer that question.

Re: Toward Go 2

#52

Post by masklinn »

JepZ wrote: post #37
masklinn wrote: post #23

Earlier quoted context omitted.

> I mean 'generics' sounds like a complex concept from the java development and I am uncertain if that's really what we need in go. That's inane and insane. Java generics do almost nothing, they don't even exist at runtime in a language with (much like Go) heavy runtime semantics. Here's what Java's generics do: get typechecked, and insert implicit casts. > Yes, I am sure there are more container formats First, you f…

So if generics in java don't do anything beyond 'get typechecked, and insert implicit casts.' the empty interface is enough for all use-cases in go?

1. the empty interface does not do the first one, and thus does not allow writing typesafe structures and code

2. and it requires significant expense of explicit casts which are not just sanity checks (which is what they are in java, due to type system weaknesses)

Re: Toward Go 2

#53

Post by eropple »

kardianos wrote: post #24
eropple wrote: post #12

Earlier quoted context omitted.

> no longer even bother participating in Go-related discussions, because they've believe it will never happen /raises hand I like when tools are good, but I've basically written off Go as a tool for generating unsustainable code right now (and a big part of it is the odious options, either type-unsafety or code generation, for things that are trivially handled by parametricity). If things change, I'll be happy to rev…

I think the Go team would still like to understand your production uses that caused you to write off Go. What is your problem domain? How would you accomplish that in Go? How did you actually solve your problem with a different language? For me, user provided data structures are the only thing that comes to mind (sync.Map for example) in my production use of Go. But even then, my pain (time spent, errors made) due to…

My "problem domain" is "good, correct code". I write code in many different spaces, from web software to mobile apps to (a lot of) devops tools to (less these days) games. My criticism of Go isn't "it's not good at code for my problem domain," it's "it's not good at code for your problem domain, either, and your workarounds shouldn't need to exist."

User-provided data structures are a big one. (A language where I have to copypaste to have typesafe trees is a bad language.) But, beyond that, I build stuff to be compiler-verified. Here's a trivial example that I did yesterday that I straight-up can't do in Go, but did in C# as part of a object graph rehydration routine (where object A required pointers to object B from a different data set, and since it's 2017 we aren't using singletons so the JSON deserializer takes in converters that look up objects based on keys in object A's JSON representation):

   public interface IKeyed { T Key { get; } }
Just being able to do that on an object is powerful. C# has reified types; I know what T is at runtime. (I can't specialize on the type in C#, but I can fake it.) But I also know what it is at compile-time, and so I can't accidentally pass `IKeyed` and `IDictionary` to the same function because type constraints, yo.

I don't really care about fast code, because computers are all future-computers-from-beyond-the-moon. If I'm using a statically-typed language, I care about correct. Duplicated code is code that will--not may--lead to bugs. State I have to maintain in my head (like "this is an int map, talking to an int-keyed object set") is state that will--not may--lead to bugs.

If you're a statically-typed language that isn't helping me avoid bugs, you might as well not exist. You don't have to be whomping around stuff like Scala's Shapeless--I would argue that you shouldn't--but you have to provide at least a basic level of sanity and the difficulty of expressing stuff outside of parameterized types (even when there are workarounds) makes it not worth the hassle. I'll cape up for damned near everything in at least some context, from dynamic languages like Ruby and ES6 to Java (well, Kotlin) or C# to Modern C++ to Scheme or a Lisp. My no-buenos on programming languages are limited pretty exclusively to C and Go because both languages encourage me, encourage all of us who use them, to write bad code.

Re: Toward Go 2

#55

Post by eropple »

masklinn wrote: post #50
eropple wrote: post #28

Earlier quoted context omitted.

> they make 80% of what we would like to have generics for I regularly use generics in other languages for tasks unrelated to "containers"/data structures. They allow me to write less code and have the compiler check my mistakes. Containers are frequently where people start with parameterized types, but once you are in the habit of using them actively that's rarely where you stop.

> once you are in the habit of using them actively that's rarely where you stop. Eh. Many people don't ever go beyond that and it's fine, containers-type structures (to which I include stuff like futures or option types) and functions working on those are by far the most common use case.

For sure. But people like me write code for many-people. Giving us the tools to help make things better for many-people is wise. ;)

Re: Toward Go 2

#57

Post by coldtea »

Spiritus wrote: post #36
solomatov wrote: post #18

Earlier quoted context omitted.

I would start using Go in my projects if it introduces generics. It's a show stopper for me.

The question is _why_ do you need generics, for what use case(s), etc? Saying “I need generics otherwise I won’t use Go” is exactly the type of feedback they don’t want. It seems like you’d have valuable feedback given that it’s a “showstopper” for you.

Because I like both reusable implementations of algorithms across compatible types AND type safety.

It's not rocket science.

And because it's 2017.

Re: Toward Go 2

#58

Post by the_mitsuhiko »

Spiritus wrote: post #36
solomatov wrote: post #18

Earlier quoted context omitted.

I would start using Go in my projects if it introduces generics. It's a show stopper for me.

The question is _why_ do you need generics, for what use case(s), etc? Saying “I need generics otherwise I won’t use Go” is exactly the type of feedback they don’t want. It seems like you’d have valuable feedback given that it’s a “showstopper” for you.

The benefits of generics are well understood.

Re: Toward Go 2

#59

Post by int_19h »

tomovo wrote: post #11
tomovo wrote: post #9

Earlier quoted context omitted.

Go 2, codename "Hell with generics". Just kidding of course. I am sure some useful form of generics will eventually find its way in.

More importantly though, looking at C++ I think it may be hard to come up with a generics system that doesn't lend itself to abuse and ridiculous mega constructs. I would love to see something that provides power in ways that disallow craziness (Boost Spirit kind) but provide enough power to avoid all the cases that suffer without generics.

C++ doesn't have generics, it has templates, which are effectively a syntax-constrained form of macros. That's why it lends itself to abuse (or creative use, depending on your take on macros).

Re: Toward Go 2

#60

Post by smdz »

Analemma_ wrote: post #8

> For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. This is sampling bias at work. The people who need generics have long since given up on Go and no longer even bother participating in Go-related discussions, because they've believe it will never happen. Meanwhile, if you're still using Go, you must…

I have used generics for quite long. When I used it I loved it. Then I moved to a different language for a few years, and lost generics. Now I have written large programs in GoLang too - and frankly I do not miss out on generics at all. Now, I also find reading code with generics isn't straightforward either - it requires a slightly complicated mental model.
Post reply on HN