> Not substantially. It made the concurrency decisions for you ahead of time, and if you need a different concurrency model, you're up shit creek. It's not tru

> Not substantially. It made the concurrency decisions for you ahead of time, and if you need a different concurrency model, you're up shit creek. It's not true. I'm not sure what concurrency models you feel you need but let's go through the most popular ones. There's event based programming which is essentially single-threaded and predicated on structuring your code around poll/kqueue/whatever loop. You can do that in Go since you can call any OS syscall from Go. It just leads to awkward code. There's shared memory multithreading with locks to protect data structures. You can do that in Go (except you use goroutines, which are multiplexed into OS threads by Go scheduler, instead of using OS threads directly as in C). And then there's Go's prefferred (but not exclusive) solution of channels/goroutines and idea of sharing memory by communicating (as opposed to communicating by sharing memory as in threads/locks based model). What concurrency models are available in C or Python or Java that you can't do in Go? > So is my Radio Flyer Wagon. You still can't do systems programming, embedded, high performance, or real-time work with it. As a rebuttal (?), it doesn't follow. As to your point, your definition of systems programming is different from that used by Go designers, since they are very insistent on calling Go a systems programming language. Please clarify what kind of systems programming you can do in C/Java that you can't do in Go? As to high-performance: I don't follow. It's fast. What kind of high performance programming you can't do in Go that you can do in C or Java? As to embedded - sure that niche is owned by C. How is it different from Python or Java and how does that make Go a niche language? The same goes for real-time where real-time systems are even more niche and are as much a property of the OS as it is of the language. You can't do real-time in any language on stock Linux kernel given that kernel can pre-empt any application at any time for any period of time. You make a lot of statements but nothing concrete enough to support them. I've shown that in Go you can use 3 concurrency models, 2 of which are currently most popular in the C/Java worlds. As to systems programming - you don't provide a definition or examples of what kind of programs do you consider as systems programming so it's hard to argue at that level. Does a web server qualify? (you can write one Go). Would a distributed database like HBase qualify? Even though one hasn't been written, HBase is Java and there's nothing that you can write in Java that you can't write in Go, with potentially better performance due to compilation to native code and more efficient memory usage.