What do you mean "replacement for Java"? It's a completely different language:
* no classes (only structs and embedding)
* no VM, only a run-time (cross-compiling is trivial though)
* hardly anything is an object
* no exceptions
* concurrent by design
It's quite possibly the most distant language from Java in the procedural world, which I think is a good thing. It forces you to rethink your data and their interactions.
I think Go is a great language and works in most of the spaces where Java lives, except maybe GUIs, but Java was never any good at that anyway. It's more suited for the server, but it can work well for computationally-intensive tasks as well.
Go is better thought of as a replacement for whatever server stack you have than a replacement for a given language.
>> I think Go is a great language and works in most of the spaces where Java lives, except maybe GUIs, but Java was never any good at that anyway.
Eclipse is the world's most popular IDE it's written in Java, Minecraft one of the most popular Indie games ever made was written in Java. What gives you the impression that Java isn't good for GUI's? It's great for GUIs and it's cross platform from the start.
If Eclipse is evidence that Java is good at GUIs, I shudder to think what the output of something bad at them must be like to use.
edit: to give you a constructive response: Eclipse is an excellent illustration of how godawful Java is at GUIs. It chugs horribly on even high end hardware because of Java's interminable GC pauses getting in the way of interactive response times. It looks native nowhere, and somehow contrives to feel even more alien than it looks. It manifests platform dependent UI bugs, completely defeating every last shred of its claimed "write a GUI once, deploy it anywhere" advantages.
If you want to make the argument that Java is good for GUI's, feel free, but you just picked the two worst examples I could possibly think of. As a Mac user, the UI for Eclipse is such a huge turn-off that it soured me on Java as a whole (back before I really knew anything about Java; today, there's plenty of other stuff to dislike besides the GUI toolkit). And Minecraft? That's not a UI, that's an OpenGL game. Nothing about the custom OpenGL-based UI it presents to users says anything about Java, or has any bearing on other Java apps you might write.
Ok, you have a good point. I'll instead list Open Office and LibreOffice and Symphony and Lotus Notes. Those are hugely complex GUI's and work as good as or better than anything proprietary out there in the same class pf products.
What I was implying is that "built for concurrency" isn't just about threads (or goroutines). It's about communication between concurrent routines and shared state. Go is designed to have less coordination in concurrency by encouraging communication via channels instead of shared state.
Well, yeah, because Go is compiled, not interpreted. It's GC isn't as optimized as Java's, but for straight computational speed, it's pretty comparable to other compiled languages.
It just isn't a drop-in replacement for Java because it doesn't live in the same space. It does, however, have a similar feel as Python, especially with slices (except Go's don't copy data) and first-order functions. It's a completely different feel though than Python.
* no classes (only structs and embedding)
* no VM, only a run-time (cross-compiling is trivial though)
* hardly anything is an object
* no exceptions
* concurrent by design
It's quite possibly the most distant language from Java in the procedural world, which I think is a good thing. It forces you to rethink your data and their interactions.
I think Go is a great language and works in most of the spaces where Java lives, except maybe GUIs, but Java was never any good at that anyway. It's more suited for the server, but it can work well for computationally-intensive tasks as well.
Go is better thought of as a replacement for whatever server stack you have than a replacement for a given language.