Go replaces Java for Google and most other companies.
Go was supposed to replace C++ but didn't even come close despite the best intentions of Pike and ken.
Comical.
If you have the time and resources though... go for it!
Edit: But it does seem like there's already some contenders for Go's go-to framework (Like Django/Rails are for their respective language)
http://robfig.github.com/revel/
I'd rather have a framework with a community that ensures that it is guaranteed to be maintained in the future.
Go tries to be safer and more automatic, like Java. While it's more organized and prescriptive than C or C++, it's less religious than Java about everything being a class. So it encourages the pragmatism and low-levelness of closer-to-the-metal languages while also abstracting out a lot of the details which get in the way of just writing systems.
Because they want both speed and OO programming? :)
C++ is a multi-paradigm language. It has more abstractions than C, while retaining the ability to get down to the metal when you need to. Arguably, these higher level features are desirable when working on larger code bases. C++ also has features that make it easier to write clean and correct code (such as RAII). Templates and operator overloading makes for writing expressive libraries. I remember reading and article that compared C and C++ in the context of a matrix library. The C++ code was much more concise and readable, and was easier to get right compared to C, mainly due to those two features.
Furthermore, C++ can actually be faster than C. The canonical example is the templated std::sort() vs C's quicksort(). The C++ compiler is able to inline the comparator argument to the former, whereas qsort() takes a function pointer.
http://commandcenter.blogspot.fi/2012/06/less-is-exponential...
Apparently the remaining C++ users are really fixated on something called zero cost abstractions, and it's not a goal of Go: "Zero cost isn't a goal, at least not zero CPU cost. Go's claim is that minimizing programmer effort is a more important consideration."
(though I don't think C++ succeeds in "zero cost abstractions")
Channels and Goroutines are easily available in java.util.concurrent.
If you really want compilation to pure native code, there native code compilers for Java as well.
HAHAHAHAHAHAHAHAHAHA. No.
The Java specification allows for green threads, N:1 mapping of threads, or system threads, 1:1 mapping to system threads.
It is up to the Java VM or compiler to offer one implementation or even both.
Tasks in java.util.concurrent make use of thread pooling to also achieve N:1 mapping of tasks to threads.
The Squawk and the Cacao VMs are two examples of a Java VM using green threads,
From the documentation:
"Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run".
Same thing as in Java, just integrated into the language instead of a library. But then again, Scala offers that too.
You had the same thing in early Java with green-treads -- it is abandoned for modern JVMs, but you can mimic it. You can have millions of Scala actors.
>Goroutines are cheap: each goroutine starts at a size of 4k, and creating them is a really cheap operation.
Yes, but handling and migrating them is a "not really cheap operation". They are mostly useful as abstractions, as for performance you don't get anything over Java (if not worse: checkout Go vs Java concurrency benchmarks).
>Please show me a Java thread implementation with the same properties. Good luck with that.
Not sure I need all that "luck" you wish me. How about Java on Solaris, which multiplexes java threads to native threads?