I agree with your goal. But the parent is correct in that learning a really different language will help you become a better developer and thus build better systems.

That isn't the only thing he said. I'm all for learning different paradigms, but he made a much different argument.

"i truly believe go contributes negative work to society"

people who program actually have a lot to learn from the fashion industry. trends are fine as long as trends are iterated on quickly. in comparison, it's taken programmers 15 years to make the half-assed-jump from java to go. and even then, the conceptual differences between java and go are minimal, superficial at best.

the fact is that go touts itself as a C++/java alternative but i see no significant/non-superficial reason to actually change languages. thinking in go is 99% the same thing as thinking in C++. consequently, 99% of the time doing stuff in go takes me roughly the same amount of time as doing the same thing in C++. programmers remain stunted.

we all know how efficient we can be writing code like in the von neumann style (not to mention 90% of programmers haven't yet even mastered that). to advance what people can do with computers it's time to start thinking beyond sequences of instructions and memory accesses, we need a language that encourages higher-order thinking. otherwise it's like building the empire state building with legos.

Two things. 1) Have you used Go? Your comments indicate to me that you have little Go experience - thinking in Go is quite different from thinking in C.

2) One line counter-example to disprove your negative-work argument: goroutines. Also known as: CSP-style concurrency in a procedural language.

I urge you to read up on goroutines. There are quite a few examples on the golang site of how you can use this feature to good effect, examples that would require you to think very differently than if you were in C.

Also, I'd like to point out that the Go project got started because Rob Pike and Ken Thompson grew tired of long build times while working with C++ while at Google. One of Go's objectives is fast compilation times. They are willing to stick to this goal at the expense of complex type systems. This is, if it is anything, not negative work.

Go routines + CSP are easily done in all mainstream languages.

Java: java.util.concurrent

.NET Task Parallel Library

C++ Parallel Patterns Library Threading Building Blocks Click Cilk Plus

D Actors + std.concurrency

Erlang Actors

Scala Actors

Haskell STM

Clojure STM

There are good things about Go, but people should learn other programming languages properly, before doing comparisons.

Threads are different from goroutines. A Go program can create 100'000 goroutines, if it makes sense for the algorithm. Try doing this with threads... Super-cheap threads open many possibilities, it's a significant change in how you think and design programs.

Among your examples, those that are comparable to goroutines are all for functional languages. There's nothing wrong with functional languages, but it's far from "all mainstream languages".

Yes there are, they are known as user space threads or fibers.

User space threads don't run in parallel, i.e. they don't take advantage of multi-core CPUs and can be blocking.

Fibers are for cooperative multitasking so no parallelism either.

Goroutines are multiplexed as needed onto system threads. http://golang.org/doc/GoCourseDay3.pdf

So they are a bit different, in the spirit of Go: they make for a simple and general solution to both parallelism and concurrency. They combine naturally with channels to give the functionality of OS threads, user threads and fibers.

As an aside: watching Pike's talk on lexing and parsing in Go really hits this point home. It shows how language support for cheap threads (goroutines) and channels really change the way you come up with an algorithm.

http://www.youtube.com/watch?v=HxaD_trXwRE