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

Channels Are Not Enough

gist.github.com

Post reply on HN
Print view View original

21–30 of 224 posts

Re: Channels Are Not Enough

#21

Post by spion »

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…

That really depends on what you mean by "most of the time". After all, you only write a generics based library once, and you reuse it many times - therefore on the outside it appears that you don't really use generics all that much.

In my opinion, depriving a "normal" language user of generics is like depriving a Lisp user of macros. Whatever it is, its definitely not just "bold".

Re: Channels Are Not Enough

#22

Post by dkarapetyan »

georgemcbay wrote: post #16
dkarapetyan wrote: post #14

Earlier quoted context omitted.

What exactly do you mean by "magic"? Most of the time when I hear people talk about "magic" they usually mean a theory or abstraction that they don't understand or don't want to understand. Are generics magical in your opinion?

What makes things magical or not (the way I think of magical) isn't about the theory of the feature but rather how they are implemented and how much is hidden from the person using them in terms of code complexity and just overall work being done relative to what they think they did. I'm perfectly comfortable with the "theory of generics", but when generics first came on the scene for C++ back during the time period…

There is a bit of contradiction in your definition then. I don't think anyone using Go understands how the compiler does all the transformations necessary to get from Go to machine code. In that sense Go as a whole is pretty magical but you seem perfectly happy with that.

Modern application programmers and even system programmers by your definition rely on a lot of "magic". Even the machine code these days is a layer or two removed from the actual metal with all the caching and microcode that reside on the CPU.

Re: Channels Are Not Enough

#23

Post by georgemcbay »

wyager wrote: post #18
georgemcbay wrote: post #12

"I want all this Then perhaps Go is not the language for you. There are a lot of design decisions in Go that seem arbitrarily restrictive at first but are there, AFAICT, to (as much as is reasonable) force programmers to write code where what is happening is explicit and obvious without having to dive down into layers and layers of abstraction to find "the magic". This is, IMO, a feature and not a bug, but YMMV.

Go doesn't prevent "magic", it just makes you hide the magic in ugly places. Can't have a flexible iterator system because it might introduce complexity? Better just hide complexity in a next() function. Can't have generics (except for the google-approved map, slice, chan...) because it might introduce complexity? Better just shift that complexity to unsafe use of interface{}.

It doesn't "prevent" "magic", but it "highly discourages" it.

And again, I think it is a feature and not a bug.

I didn't always think that way, I had a really rough start with Go because I was using it as if I were programming in a slightly different dialect of C++ which it isn't. When I write Go as if it is Go, I just don't see these "missing features" as problems at all.

But this debate has been going back and forth since Go was first made public, so anyone who has tried Go and dismissed it based on these lack of features is unlikely to be persuaded otherwise here and they should continue to use other languages until such a time as Go supports what they want (if ever). That's the beauty of having so many languages to choose from.

Re: Channels Are Not Enough

#24

Post by ufo »

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…

Correct me if I'm wrong but doesn't the current state of affairs (using Interface{}) have all the downsides of Java's boxing but without any of the type safety?

Re: Channels Are Not Enough

#25

Post by spion »

cjslep wrote: post #19
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…

> [...] 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 already implement generics without significant compile-time or run-time overhead - why is it that hard for Go to do that?

Re: Channels Are Not Enough

#26

Post by ufo »

stcredzero wrote: post #5
jorlow wrote: post #3

Earlier quoted context omitted.

The problem (which the article touches on) is that you have to resort to interface{} to make things reusable since Go doesn't have generics. So you have to pick between using a library (which will handle edge cases better) or compile time type checking.

How about replacing certain compile time type checks with smoke tests and runtime assertions, or unit tests?

Inserting the assertions by hand is annoying and error prone - even if you want the assertions to be checked at runtime its still very helpful if the programming language inserts the type checking automatically for you.

Another thing is that assertions can only check primitive type. To check if a function pointer or object respects an interface you need to add an extra wrapper around it to check all its return values (and this is so annoying to do by hand that noone bothers to do it)

Re: Channels Are Not Enough

#27

Post by NateDad »

ufo wrote: post #24
eloff wrote: post #17

Earlier quoted context omitted.

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…

Correct me if I'm wrong but doesn't the current state of affairs (using Interface{}) have all the downsides of Java's boxing but without any of the type safety?

The answer is not that you should use an empty interface, the answer is not to write generic functions.

Re: Channels Are Not Enough

#28

Post by eropple »

NateDad wrote: post #27
ufo wrote: post #24

Earlier quoted context omitted.

Correct me if I'm wrong but doesn't the current state of affairs (using Interface{}) have all the downsides of Java's boxing but without any of the type safety?

The answer is not that you should use an empty interface, the answer is not to write generic functions.

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).

Re: Channels Are Not Enough

#29

Post by enneff »

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 at an environmental level.

The Go creators do not deny that generics would make things easier. In particular, concurrency is one area where some kind of parametric type system would be really helpful. But we, and many others, are finding Go to be a great tool for a wide variety of jobs. It has won developer mindshare specifically because of our focus on simplicity. It doesn't seem worth compromising that to reduce the occasional bit of repetitive code.

Re: Channels Are Not Enough

#30

Post by spion »

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…

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