[djur]

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 of code basically follows the same rules as any other.

[1]: http://golang.org/doc/faq#Why_doesnt_Go_have_feature_X

[voyou]

"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/

[nickik]

I think what you are missing is that people do use abstraction if you offer it. Java or C# generics or even when C++ added templates. C++ templates where abused but it was done so often that is now standard.

If you look at code from the newer fancy languages people do use these fancy features.

[tonyhb]

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 most of this rant about channels.

[djur]

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.

[tonyhb]

In other statically typed languages you don't break type safety to implement abstractions.

In go, where interfaces are implemented by default and `interface{}` covers everything, you also don't need to. It's just a little bit (~6 lines) of code to add to guarantee it while they figure out a nice way to add generics.

[frou_dh]

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

[threeseed]

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.

[polskibus]

Compilation can be parallelized quite well if the code is structured properly. I used Xoreax grid engine (incredibuild) on Windows some time ago with C++ and it was great at speeding up our builds. Shame C# isn't parallelized in the same way.

Perhaps Go implementers could use similar approach?

[nickik]

As far as I know, correct me if I am wrong, D does have many of the features Go lacks, like generics, and also has very fast compile times.