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

41–50 of 224 posts

Re: Channels Are Not Enough

#41

Post by djur »

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 has plenty of "magic": garbage collection, maps, slices, channels, goroutines. It just wants you to stick to the abstractions provided by the language and not create your own.

This is fine, it's a design goal of the language, but it's unsurprisingly frustrating for people used to more expressive languages.

Re: Channels Are Not Enough

#42

Post by Pxtl »

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?

It reminds me of the wonderful fun days of Java 1.2 - anybody remember how proud Sun was of how everything derived from object so you could use the untyped containers for everything?

Re: Channels Are Not Enough

#43

Post by f2f »

djur wrote: post #36
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…

That answer has been there for a while. There hasn't really been any indication that the issue actually is open, other than a refusal to state outright "no generics in Go". I can't decide if my biggest problem with that answer is that it suggests that the primary use case for generics is generic containers (when, really, the main benefit of generic containers is being able to implement generic algorithms on said cont…

Quit whining.

Re: Channels Are Not Enough

#44

Post by nknighthb »

djur wrote: post #41
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 has plenty of "magic": garbage collection, maps, slices, channels, goroutines. It just wants you to stick to the abstractions provided by the language and not create your own. This is fine, it's a design goal of the language, but it's unsurprisingly frustrating for people used to more expressive languages.

If there's any magic on that list, it's limited to the garbage collector, and to whatever extent it's magic, that magic would vanish if it were based on strict automatic reference counting.

The others are conveniences to avoid subtle bugs and millions of developers writing the exact same code in every project.

I've mentioned this before, but my experience is that "expressive" is synonymous with "obfuscated". Go helps us in writing clear, maintainable code, not clever code.

Re: Channels Are Not Enough

#45

Post by zaphar »

haberman wrote: post #40
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…

> 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. For what it's worth, I have had a similar experience. One time I expressed a personal opinion on G+ about something I don't like about Go personally. A Go fan re-shared this in the Go community and it turned into a debate. https://plus.google.com/+RalphCorderoy/po…

I'll just leave these here: https://groups.google.com/forum/#!msg/golang-dev/ZTD1qtpruA8...

https://github.com/clipperhouse/gen

I'm sorry you got the impression of that there is a strong bias against admitting problems. I haven't seen that bias at all myself. Instead I've seen a willingness to look at different approaches to the problem and an unwillingness to compromise the other design goals of the language.

Re: Channels Are Not Enough

#46

Post by burntsushi »

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…

You're claiming that they think generics have no value. That is incorrect. They just think there are other things that have more value.[1] In other words, they prefer a different set of trade offs than you do. I don't see how this could be reasonably considered "denial."

[1] - http://research.swtch.com/generic

Re: Channels Are Not Enough

#47

Post by EpicEng »

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.

Well it obviously depends on what kind of code you write. People writing certain types of libraries may benefit far more from generics than you would.

Re: Channels Are Not Enough

#48

Post by burntsushi »

djur wrote: post #41
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 has plenty of "magic": garbage collection, maps, slices, channels, goroutines. It just wants you to stick to the abstractions provided by the language and not create your own. This is fine, it's a design goal of the language, but it's unsurprisingly frustrating for people used to more expressive languages.

> but it's unsurprisingly frustrating for people used to more expressive languages

Speak for yourself. I know you certainly don't speak for me. I love Go. I love Haskell. I love Rust.

There are things in all languages that frustrate me. I can appreciate the particular trade offs made in each language. Believe it or not, I think the language specifications for both Haskell and Go are things of beauty. It's amazing how close the core of Haskell is to just a simply typed lambda calculus. It's amazing at how Go can be so well specified in such a short document with near perfect orthogonality in the language.

Many of your comments in this thread read (to me) as if you're speaking from a position of authority on what the right design for a language is. I think your comments would be better received if you expressed your thoughts as opinions rather than as things you consider facts.

Re: Channels Are Not Enough

#49

Post by zak_mc_kracken »

Pretty much every article that is posted about Go ends up in a never ending discussion about the absence of generics, which completely drowns the discussions about Go. As a result, the material on the web about Go has a very high noise/signal ratio, which is unfortunate.

Hopefully, the Go team will see this as one more reason to add generics to their language, but until they do that, Go will remain a niche language with a severely crippled potential.

Re: Channels Are Not Enough

#50

Post by threeseed »

djur wrote: post #4

This is a really great read, and goes beyond just channels and concurrency. It seems to me that Go is designed to discourage developing higher-level abstractions. That was my sense using it in the past, and it's only gotten stronger over time. Remember that one of Go's primary stated goals is "speed of compilation"[1]. Simplicity and ease of learning are paramount, and it's easier to learn a language where any chunk…

Speed of compilation doesn't mean you need a simplistic language.

With Java I can hot reload classes to get instant compilation times in 99% of cases. With languages that use a REPL I don't even need to compile at all until almost all my code is written.

Post reply on HN