I know there is a lot of hate for Java on HN but it is easily the most mature of the "fast" languages for the web. Are their glaring features missing in Java or huge wins in Go that I am missing?
I know there is a lot of hate for Java on HN but it is easily the most mature of the "fast" languages for the web. Are their glaring features missing in Java or huge wins in Go that I am missing?
We'd all be better off if this thread were actually a discussion of the libraries Dropbox released, and if subthreads like this dropped to the bottom of the page.
I downvoted you for that reason; not because it's a dumb question, but because it's in a very unfortunate spot on the thread.
- Very easy deployment (we can just copy the same binaries between our 64 bit linux boxes and run them)
- Go's libraries for developing minimal web interfaces are excellent
- Being strongly encouraged to do all the explicit error checking made our Go code much more reliable and easy to debug than our previous python versions.
Of course, all of this depends on how big the project is. We just have several components of a project that require a simple webpage frontend with a small REST backend to interact with Redis. Our entire server for both the frontend and backend is ~1200 lines of Go and easy to understand. If your project is much bigger, you may end up needing features that aren't present in Go (as was the case with Dropbox), which may slow you down some.
For scripting languages like Python or Ruby you can sell out-of-the-box performance and concurrency benefits.
For lower-level compiled languages you can sell the ease of cross-platform binary compilation and direct compatibility with C.
The only thing I can think of that might be interesting to someone with a monolithic Java codebase is the syntactical simplicity and speed of testing / deploying. But if you have such a codebase that's a major prospect for potentially minimal benefit. Not to mention you have a much larger set of developers to choose from.
edit: weirdest downvotes ever
Java the Language:
1. Go is more concise. You might not care, but I do.
2. Go uses explicit error return codes.
My experience is that practically and counter intuitively, explicit error return codes (that have to be explicitly checked for errors) result in more robust code than exceptions (checked or not). YMMV.
Java the Virtual Machine:
1. Go produces single file native binaries. You may not care, but if you do, that's a win.
Java the Ecosystem:
1. Go interfaces to C more easily;
2. Go has a more vibrant, more enthusiastic community right now.
3. Go advances more quickly.
(Of course, I can think of a lot more reasons that the Java ecosystem wins - but you asked to sell you on Go...)
But if you're looking for a new language, rather then Go specifically, I urge you to have a look at Nim (nee Nimrod). It's very impressive. I think it's what Go wanted to be.
Small nitpick, but the default error value returned is a string.
> 1. Go produces single file native binaries. You may not care, but if you do, that's a win.
So does Java. It is only a matter of picking the right implementation.
There are certified implementations with AOT compilers.
If you're already writing Java, Go isn't a huge win. If you're using Ruby/Python/JS and want more performance Go is a choice instead of the JVM.
Java's standard library is bytecode-compatible with Java1 programs, which will run fine on today's JVM's. This results in several very dumb and ugly inconveniences.
For example, take a look at the ArrayList javadoc. Notice the Object methods (clone(), and toArray()), which are there because the return-type polymorphism doesn't work (you cannot call a different method based on what you assign the function result to). So it's not possible to provide a valid Clone() method that returns something other than Object without breaking java1 programs that use it. (Go's has compiler hacks for core datatypes for some things, which of course means it's a matter of time until things break, but for now ...).
Of course if this was the only instance of this sort of problem, nobody would care, but you can find examples like this in most core classes.
TLDR: Go is in it's honeymoon period.
More detailed explanation :
http://stackoverflow.com/questions/17509659/why-standard-jav...
There isn't anything that you can write in Go but you cannot in Java. (Probably it's true the other way around as well.)
Go takes what I consider 'best practices' in Java, things like delegation-rather-than-inheritance, and manage-concurrency-through-BlockingQueues-and-ExecutorServices, and makes them the 'idiomatic' way to do things.
It's not so much huge wins as a bunch of small wins, a much tighter stdlib, and making it much harder to do some common java antipatterns like implementation inheritance and overdone design patterns. Oh, and the C interop is amazing.
The error handling, having to explicitly check return codes, seems like a huge burden at first but pays off later when you realize you can't have random exceptions bubbling all the way up the stack from anyplace in the code.
Do you need generics? then Go isn't for you.
FTFU ;-)
From there it's the concurrency primitives, goroutines and channels, that make Go a true winner. It's easy to build network services that can move work through various stages quickly and in parallel. SEDA-style workloads are a pleasure to implement in Go.
I can't speak to the technical merits of either language, but something can be said about choosing a language with a lot of hype as opposed to one that's hated in the community. From a recruitment perspective, choosing Go may be more favorable in a lot of developers eyes.
"From a recruitment perspective, choosing Go may be more favorable in a lot of developers eyes." -- from a recruitment perspective it's extremely easy to find (experienced) Java devs, and not so easy to find (experienced) Go devs.
That brought a smile to my face. I've been saying this about Java since 1994.
> from a recruitment perspective it's extremely easy to find (experienced) Java devs,
From my experience, that is true in the literal sense of "experienced = having experience". But not so true in the sense of "experienced = competent and knows their stuff", which is often implied. One of the things about new and fringe languages is that they are effectively a competence filter:
It is much more likely that e.g. a Lisp programmer, a Haskell programmer, an OCaml programmer or a $NEW_HOTNESS programmer for most values of $NEW_HOTNESS is a good one. I suspect Go is beyond NEW_HOTNESS status to work as a filter, though.
The problem is that the 'HN community' has IMO a pretty small overlap with the overall software development community.
Hype in the former does not equate to hype in the latter.