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

121–130 of 224 posts

Re: Channels Are Not Enough

#121

Post by voyou »

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…

"Go is designed to discourage developing higher-level abstractions."

Yes, that does seem to be the distinctive thing about Go. It's almost like someone read Paul Graham's "blub" essay[1] and thought, "what would it mean to take seriously the idea that blub is the best language?"

Everyone knows that building abstractions has a cost - the cost of building the abstractions themselves, the cost of figuring out the particular abstractions employed in a given project, and the cost of comprehending a language flexible enough to support these abstractions. The hope is that the cost of abstraction is an investment: the time you put in will be rewarded in faster development when you put the abstractions to use. But at some point increased abstraction is going to give diminishing returns.

Now, most programs written today don't involve that much more abstraction than would have been possible with programs written in ALGOL; that is, we haven't seen a huge widespread increase in the power of abstraction used by most programmers in about 50 years. People like Alan Kay and Brett Victor[2] decry this stagnation, and maybe they're right to. But maybe the current low level of abstraction is so durable because it's a sweet spot between the benefits you get from abstraction and the costs involved in coming to grips with that abstraction.

Most people, particularly most people who develop programming languages, assume that we're nowhere near the point of diminishing returns for increasing abstraction. Go seems like an experiment to test the possibility that the maximum efficiency occurs at a much lower level of abstraction than we usually think. It will be interesting to see whether (or in what domains) that hypothesis turns out to be true.

[1] http://www.paulgraham.com/avg.html [2] http://worrydream.com/dbx/

Re: Channels Are Not Enough

#122

Post by MaulingMonkey »

Svip wrote: post #119
pjmlp wrote: post #107

Earlier quoted context omitted.

Simple languages shift complexity to the programmer's shoulders.

Writing more code is not the same as more complexity. Irritating, perhaps, but not more complexity. A larger language overhead to keep in mind is more complexity.

So if I have a larger language overhead to keep in mind, that's more complexity, but if I have a larger codebase overhead to keep in mind, that's not more complexity? You're trying to have it both ways, IMO.

Re: Channels Are Not Enough

#123

Post by p0nce »

zaphar wrote: post #45
haberman wrote: post #40

Earlier quoted context omitted.

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

> https://groups.google.com/forum/#!msg/golang-dev/ZTD1qtpruA8...

Everything in there listed as impractical in Go is possible in D without external tool, with just regular meta-programming:

- generating parsers from grammar https://github.com/PhilippeSigaud/Pegged

- embedding files as array of bytes:

    ubyte[] = import("file.jpeg");
- protobuf files at compile-time: https://github.com/msoucy/dproto

- generating tables at compile-time with CTFE

Instead of copying what works the Go leaders pretend it doesn't work.

Re: Channels Are Not Enough

#124

Post by gbog »

sriku wrote: post #57
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).

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.

> If there are complexities that programmers face that can be absorbed by a compiler, it must be

Not sure. If absorbing it would make the compiler much slower, much more complex, or the compiled code less deterministic, or corner cases in the compiler much more numerous, I think it may be reasonable to not go this path.

It looks like the go compiler in itself is a nice piece of engineering, like a F1 race car. And a bunch of guys say they want it with automatic gears. Proposing an automatic version would change too many things in the internals, and the result would be another kind of cars.

Re: Channels Are Not Enough

#125

Post by frou_dh »

rdtsc wrote: post #91
enneff wrote: post #86

Earlier quoted context omitted.

You have it all backwards. We didn't build Go in order to have arguments on a mailing list. And I don't think the people saying "I don't need generics," are lying. I think they actually believe what they say, and I'm sure if we did introduce generics today many of them would say "I think this is a mistake." Yes, the tradeoffs have been made. The language has been designed. It is very unlikely that Go 1.x will see gen…

> And simplicity is a core tenet of the language design. To sacrifice that would be to admit defeat entirely. We could have just been using C++ all along. Well that was my point it. Turning Go into something like Java or C++ will make it not Go any more. > We didn't build Go in order to have arguments on a mailing list. Not sure many popular languages were built for that. But arguments on mailing lists is what you ge…

Simple is the biggest weasel word in programming.

In practice it's pretty much a measure of the temperature of bear porridge that a given person currently finds just right.

Re: Channels Are Not Enough

#126

Post by burntsushi »

shadowmint wrote: post #92
burntsushi wrote: post #67

Earlier quoted context omitted.

> I don't know what in my comment suggests that you can't love both Haskell and Go I quoted it in my comment. You said: "but [Go is] unsurprisingly frustrating for people used to more expressive languages." I'm used to more expressive languages too, but I don't find Go frustrating. Therefore, your statement is false. You probably intended it to read like: "I am unsurprisingly frustrated with Go because I prefer more…

I am unsurprisingly frustrated with Go because I prefer more expressive languages, fwiw. (...and no, I don't think it's particularly wrong to assert that this is the case for other people too; there's plenty of evidence to support that people find the lack of generics in a fully featured language like go frustrating; and it's not surprising what so ever that this is the case)

> I am unsurprisingly frustrated with Go because I prefer more expressive languages, fwiw.

So? My point was not to claim the opposite of the OP, it was to point out that the generalization is false.

> (...and no, I don't think it's particularly wrong to assert that this is the case for other people too; there's plenty of evidence to support that people find the lack of generics in a fully featured language like go frustrating; and it's not surprising what so ever that this is the case)

I guess, if your evidence consists of people on HN and reddit complaining about Go.

Re: Channels Are Not Enough

#127

Post by pdpi »

Svip wrote: post #119
pjmlp wrote: post #107

Earlier quoted context omitted.

Simple languages shift complexity to the programmer's shoulders.

Writing more code is not the same as more complexity. Irritating, perhaps, but not more complexity. A larger language overhead to keep in mind is more complexity.

More code is more complexity from a maintenance point of view. You have to maintain n copies of the same code, specialised to n types. Find a bug in one, hopefully you'll remember to correct it for all n.

Re: Channels Are Not Enough

#128

Post by disputin »

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…

"...incapable of admitting problems..."

From the Go FAQ:

Why does Go not have generic types?

Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do.

https://golang.org/doc/faq#generics

Re: Channels Are Not Enough

#129

Post by frou_dh »

djur wrote: post #39
tonyhb wrote: post #34

Earlier quoted context omitted.

There's a way to make channels easy to use and abstract. Just make a typecast function. Details in a comment on the original post. The idea is that you create a library which communicates using channel interface. Great. Now you need to add `i.(myType)` wherever. So, create a function that accepts an interface, switches on type (switch i.(type)) and returns a value with your concrete type. It's a 6-liner solution to m…

In a statically typed language, it shouldn't be necessary to break type safety to implement basic abstractions. The only thing interface{} provides over void* is safe typecasting.

Well that's not to be sneezed at, even though it remains crude.

Re: Channels Are Not Enough

#130

Post by the_af »

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.

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

That's not my experience at all. Generics are generally not a source of pain. Do you have any specific examples of your claim?

Post reply on HN