Channels Are Not Enough • Hacker News Board

Re: Channels Are Not Enough

#51

Post by tracker1 » Mon, Sep 15, 2014, 1:35 AM UTC

spion wrote: post #25

cjslep wrote: post #19

Earlier quoted context omitted.

> [...] but because its authors and community is incapable of admitting problems when they see them. What evidence did you see to make this conclusion? I can only find from their FAQ[0]: "Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do. Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet f…

I believe that this is evidence enough that they're downplaying the importance of generics. Specifically, the claim that "maps and slices" can replace the ability to write abstractions such as futures, promises, observables as well as generic function such as map, reduce etc comes off as either naive or disingenuous Furthermore, the "cost" of these features seems overstated to me. A lot of languages and runtimes alre…

I think a lot of the complexity even in your examples of passing functions for generic actions like map/reduce is dealing with closures and scope. I don't know enough about golang to comment on its' internals, but as I recall there was a lot of work and effort that had to go into the .Net runtime and compilers in order to support lambdas and generics properly. Which, imho was more than well worth it.

There are likely other issues that golang needs to solve that are much higher priority issues, and there are flexible, even scripted languages that can handle higher level logic problems and scale very well. I wouldn't really expect to have to use generics for most of the problems I would look to go as a first language for a given problem.

Of course all of the above said, I'm a node.js fan and really like what it has to offer. It just depends on your use cases. Go is a really clean language/platform with a lot in the box, that I do appreciate. I would be surprised if they didn't support generics for v2, if not before. But I can see why they would want to punt the issue while there are bigger problems and needs to address.

Re: Channels Are Not Enough

#52

Post by nf » Mon, Sep 15, 2014, 1:45 AM UTC

tomlu wrote: post #37

spion wrote: post #30

Earlier quoted context omitted.

I think that the "complexity" cost of generics is overstated, really. Can you explain how generics make user code more complex?

They refer to the complexity of the compiler and language, not to user code complexity. Any given language has a complexity budget and they wish to expend it elsewhere. (Note that I am in disagreement - I do think generics should be added).

No, that is not what I was referring to. It is definitely user code complexity that turns us away from generics.

People tie themselves in knots with generics all the time. Just look at pretty much any mature C++, Java, Scala, etc codebase.

Re: Channels Are Not Enough

#53

Post by spion » Mon, Sep 15, 2014, 2:01 AM UTC

cjslep wrote: post #38

spion wrote: post #25

Earlier quoted context omitted.

I believe that this is evidence enough that they're downplaying the importance of generics. Specifically, the claim that "maps and slices" can replace the ability to write abstractions such as futures, promises, observables as well as generic function such as map, reduce etc comes off as either naive or disingenuous Furthermore, the "cost" of these features seems overstated to me. A lot of languages and runtimes alre…

I don't have the hard numbers to back up the cost question, but I believe one contributing factor to the claims appearing "naive/disingenuous" to you may stem from the fact that you may be looking at the language Go from a totally different perspective than the creators when they first envisioned the language (I could be very wrong in this regard): "Go was designed to address the problems faced in software developmen…

With the right implementation debugging generics wont be hard. It doesn't have to be C++'s version of generics.

And I'm not buying the poor programmer understanding argument. Generics aren't that complex, they're just parameterized types. The fact that basic language libraries such as maps and slices cannot be implemented without them speak volumes about how fundamental they are when building abstractions.

My point is that most of the backpressure against generics seems to stem from perceived added complexity to the compiler and type system, and thats all. But I'm not convinced thats a valid argument. Truth be told, I'm not a language implementer. But I know that fast compilers and runtimes that implement generics exist, so I don't find the whole discussion believable.

Re: Channels Are Not Enough

#54

Post by spion » Mon, Sep 15, 2014, 2:06 AM UTC

nf wrote: post #52

tomlu wrote: post #37

Earlier quoted context omitted.

They refer to the complexity of the compiler and language, not to user code complexity. Any given language has a complexity budget and they wish to expend it elsewhere. (Note that I am in disagreement - I do think generics should be added).

No, that is not what I was referring to. It is definitely user code complexity that turns us away from generics. People tie themselves in knots with generics all the time. Just look at pretty much any mature C++, Java, Scala, etc codebase.

I'd say people tie themselves in inheritance and interface knots more often than generics knots. Especially invariant generics are rather hard to get wrong - they place such constraints on the types that most operations are unavailable.

Re: Channels Are Not Enough

#55

Post by eropple » Mon, Sep 15, 2014, 2:08 AM UTC

NateDad wrote: post #33

eropple wrote: post #28

Earlier quoted context omitted.

Which leads to writing the same code repeatedly--because trying to wedge in reusability via insufficiently expressive structural typing is entertaining but often fruitless--and making the user wonder why they didn't just use something modern (setting aside stuff like Scala, even C++ can do channels, and past that the reasons for Go start vanishing real quick).

I write go 40 hours a week and have been for over a year. There's been only a couple times I wanted generics and those are structures I haven't actually needed to reuse yet. I'm not guessing about not being generics much. Edit That being said, go is not for all projects. Some projects need a lot of generics. Don't use go for that.

Um, I've written Go. Nontrivial amounts, as it happens. In doing so, I recognized that I was regularly forced to write worse code in the pursuit of doing things idiomatically because I lacked the semantic richness of C++, let alone Scala. And this worse-is-better attitude of the Go community gives me a dim view of its future--and between its junk GC and its completely pedestrian semantic and syntactic propositions I already had a dim view of its present.

If you write reusable, future-facing code, generic types without the erasure of interface upcasting is required. There are no two ways around it.

Re: Channels Are Not Enough

#56

Post by kansface » Mon, Sep 15, 2014, 2:09 AM UTC

eloff wrote: post #17

spion wrote: post #11

Go doesn't let you build abstractions - it offers what it does, and if its not enough - tough luck. What I dislike worst is the denial of the Go community and creators, claiming that generics are too complex and that you don't really need them. I dismissed Go not because of its lack of abstraction power, but because its authors and community is incapable of admitting problems when they see them. A similar problem wit…

Lack of generics != lack of abstractions. The Go community freely acknowledges that generics are a nice feature, and that lacking them is a pain point of Go sometimes. Although many Go developers will tell you that sometimes turns out to be not that often in reality, which has also been my experience. Rob Pike has outlined the tradeoffs inherent with generics here: http://research.swtch.com/2009/12/generic-dilemma.ht…

The problem is that the code that needs generics is reusable abstractions in libraries. Thats probably 1-3% of code but it is also critically important and there is no convincing workaround.

Re: Channels Are Not Enough

#57

Post by sriku » Mon, Sep 15, 2014, 2:17 AM UTC

tomlu wrote: post #37

spion wrote: post #30

Earlier quoted context omitted.

I think that the "complexity" cost of generics is overstated, really. Can you explain how generics make user code more complex?

They refer to the complexity of the compiler and language, not to user code complexity. Any given language has a complexity budget and they wish to expend it elsewhere. (Note that I am in disagreement - I do think generics should be added).

That's a weird stance. If there are complexities that programmers face that can be absorbed by a compiler, it must be, because that would pay off for every programmer , in every project, in every bug prevented.

Re: Channels Are Not Enough

#58

Post by kansface » Mon, Sep 15, 2014, 2:19 AM UTC

enneff wrote: post #29

spion wrote: post #11

Go doesn't let you build abstractions - it offers what it does, and if its not enough - tough luck. What I dislike worst is the denial of the Go community and creators, claiming that generics are too complex and that you don't really need them. I dismissed Go not because of its lack of abstraction power, but because its authors and community is incapable of admitting problems when they see them. A similar problem wit…

> What I dislike worst is the denial of the Go community and creators, claiming that generics are too complex and that you don't really need them. That's not the claim. The claim is that generics add complexity to the language and its ecosystem. That, I'd hope, should be an undisputed claim. Go's lack of generics is a design tradeoff. The occasional piece of awkward code is worth the overall reduction of complexity a…

The answer to the question "where should complexity go?" is always "as low as possible". Complexity at higher levels interacts with more code and begets more complexity. The lack of generics or macros is complexity that is forced on the end user which could be handled by the compiler (language devs).

Re: Channels Are Not Enough

#59

Post by burntsushi » Mon, Sep 15, 2014, 2:22 AM UTC

eropple wrote: post #55

NateDad wrote: post #33

Earlier quoted context omitted.

I write go 40 hours a week and have been for over a year. There's been only a couple times I wanted generics and those are structures I haven't actually needed to reuse yet. I'm not guessing about not being generics much. Edit That being said, go is not for all projects. Some projects need a lot of generics. Don't use go for that.

Um, I've written Go. Nontrivial amounts, as it happens. In doing so, I recognized that I was regularly forced to write worse code in the pursuit of doing things idiomatically because I lacked the semantic richness of C++, let alone Scala. And this worse-is-better attitude of the Go community gives me a dim view of its future--and between its junk GC and its completely pedestrian semantic and syntactic propositions I…

> If you write reusable, future-facing code, generic types without the erasure of interface upcasting is required.

You're entitled to your opinions, but this is a patently false statement. There is plenty of C code currently running on my machine that was written decades ago and is still actively maintained.

> And this worse-is-better attitude of the Go community gives me a dim view of its future

The Go community actively embraces Worse-Is-Better. If your opinions are well formed enough that you know you want nothing to do with it, then what is your point exactly? Yeah, you hate Go because you hate Worst-Is-Better. So what?

Re: Channels Are Not Enough

#60

Post by burntsushi » Mon, Sep 15, 2014, 2:27 AM UTC

spion wrote: post #53

cjslep wrote: post #38

Earlier quoted context omitted.

I don't have the hard numbers to back up the cost question, but I believe one contributing factor to the claims appearing "naive/disingenuous" to you may stem from the fact that you may be looking at the language Go from a totally different perspective than the creators when they first envisioned the language (I could be very wrong in this regard): "Go was designed to address the problems faced in software developmen…

With the right implementation debugging generics wont be hard. It doesn't have to be C++'s version of generics. And I'm not buying the poor programmer understanding argument. Generics aren't that complex, they're just parameterized types. The fact that basic language libraries such as maps and slices cannot be implemented without them speak volumes about how fundamental they are when building abstractions. My point i…

> But I know that fast compilers and runtimes that implement generics exist, so I don't find the whole discussion believable.

Are you arguing that an implementation of generics in a programming language is free? (Whether it be performance or implementation complexity.) Because if not, then you admit there are trade offs. If there are trade offs, then it is conceivable that some circumstances (including programmer tastes) may lead to a valuation that is different from yours.

"Performance" of the compiler is a critical goal of the Go project. Could you point out for me an industrial strength compiler that supports a type system of your liking that can match the compilation speed of the Go compiler? (I can't think of one.) Because if not, then I'll have to invoke this: talk is cheap, show me the code.