If you're not picking the JVM in 2016 to build your core services and web applications then you're making a mistake that is going to cost you time and money either upfront in building things that already exist or later down the road when you start to need more performance and your RoR application isn't cutting it anymore.
Say what you will about Java the language (I agree it's not particularly "sexy") but the JVM is a performance beast. You can write Java or pick from one of several other languages that range across different paradigms from static functional to dynamic (current gen: Scala, Groovy, JRuby, Jython, next-gen: Kotlin, Ceylon). Integration is usually painless between these languages. It's also highly configurable and can be tuned to virtually any workload.
You get the huge benefit of a very mature and common shared infrastructure and tooling environment. Your operations team will thank you for solidifying on a single runtime environment.
Java is great. The whole ecosystem is really really solid in general and it's truly a pick what you want platform at this point. The JVM is magical for web applications and services.
I'm really not a fan of these kinds of blanket statements where you lump everything into "JVM" or "failure". The JVM is a good platform for performance, stability, etc. but it's not the only one. The .NET ecosystem is pretty high up there for performance (and gives you a bit more room for fine tuning) and it easily has some of the best support in the industry (both 1st and 3rd party). And we've all seen success stories with Node.JS, RoR, and all sorts of niche languages that probably wouldn't have happened with a different language (because of factors like needing to get up quick prototypes for startups or just the culture at those specific companies). There's no road that will "set you up for failure," so to speak. In reality, it comes down to what works for your team and your application, and a lot of times there's no clear-cut winner in those cases.
.NET is a pretty strong contender and provides a lot of the benefits of Java, I agree. C# was ahead of Java language-wise for many years, though Java is catching up, and there are elements of the CLR and model that I'd prefer over Java, such as properties. I also recall the .NET assembly model being clearer than Java equivalents like classloader. await's pretty nice. It's all been focused around Windows though for years. (Random question: Do the concurrency concepts all work out on a platform with no IO completion ports? Is there a high quality .NET implementation using epoll?)
The open source community isn't there around .NET the way that it is around Java, however. Java's libraries are a big part of what make it so effective. Perhaps Microsoft's recent change in stance and decision to open source a lot of the toolchain will influence that, but it will be playing catchup for years. I see .NET as being an engineering coup from Microsoft with intrinsic value comparable to Java, while Java has that plus a large community and better cross-platform support.
When I work in Java, the wide availability of libraries and frameworks really helps. Take a look at the number of Apache projects written in Java: https://projects-old.apache.org/indexes/language.html#Java - many of those are very high quality and useful, and those are just the Apache ones.
I feel like the perception that Oracle isn't evolving Java is heavily parroted by people outside the ecosystem. From a Java developers perspective they have done far more in the last two releases than Sun did after 1.5.
I agree with you - generalizations are never a good thing. I did however, have negative experiences with .NET in the enterprise space. I worked in C# for a few years improving some web services for a Finance company. This was long before Java 7 even, so as a language C# 4.0 seemed amazing to me at the time. Lambdas, LINQ etc, - I was blown away. Microsoft ecosystem, however was not really wowing me in any way. There wasn't for example any sort of equivalent to JMS in Microsoft land - MSMQ was simply pathetic in terms of functionality. Apache Active MQ for .NET wasn't really mature at that point. Then, there is the Microsoft SQL server which, again is not really good at any particular thing.
I'm more fatigued by the constant "use the right tool for the job" - impossible to argue with, and utterly useless advice for actually making decisions. Some tools really are better than others, and there is a lot of value in standardizing on a single platform. http://www.teamten.com/lawrence/writings/java-for-everything...
Sure, but let's have that debate, and set down a philosophy around that. What you're arguing is not that Java is everything - but that a polyglot stack has dangers, that certain tools are often unobjectably better than others, and that we shouldn't sugar coat that. I agree, as would many of our friends in the space.
But if you're saying that everyone who is in Javascript, Ruby, Python, Go, PHP (and others) should all refactor into Java because it's the one and only ideal web backend in 2016 (or design new apps exclusively in Java) - I could pick a 1000 holes in that argument. The original comment I reacted to was:
> If you're not picking the JVM in 2016 to build your core services and web applications then you're making a mistake
My apologies if this comes across negatively (which I don't intend, as this is a respectful debate among people who care deeply about their craft) - but I'm just not convinced that you're really a full supporter of the original commenter. Your blog seems to show a fair degree of pragmatism (you consider other languages/frameworks, might use them, are ok if your friends are not using Java). I'm totally fine with "I think the majority of people should use Java" (I don't fully agree with that, but in a world where many people knew that ecosystem, I think it's a great choice) - but the commenter went much further. If s/he is looking to start a debate, then I'm fine; if that person would join any company and religiously uphold that viewpoint, I don't think they'd be the right person for many companies.
P.S. If I'm wrong, and if Java is the ecosystem that for the next few years the rules them all, I really want to make a Lord of the Rings-inspired meme about it
> If you're not picking the JVM in 2016 to build your core services and web applications then you're making a mistake that is going to cost you time and money either upfront in building things that already exist or later down the road when you start to need more performance and your RoR application isn't cutting it anymore.
Honestly, unless you are operating on thin margins due to your business structure ... this isn't really an issue.
Pretty much anyone with well padded margins that the primary cost is engineering time or product costs [e.g. Physical products to ship] this is a complete non-issue as long as the datastore/service architecture is designed for horizontal scaling.
I'm constantly amazed by the tribalism of developers and the delusion that language performance is in any way relevant.
The reality is you need to just stick with one language so you can keep your engineering talent, tooling, etc. consistent due to the economies of scale of avoiding duplication of effort [libraries, learning time, tooling, etc]. The gain is in terms of engineering costs, not hardware costs.
The language, honestly, just does not matter when we can have a 10 man IT team with ~$50k/year in hardware handling a $100mil/year in business with good margins. It just doesn't even register.
Good for you that you are in that kind of business. I've never worked on anything where we didn't need more performance in the end. And when you do need it you need it quick. Having an environment and tools (e.g. top class profilers) that make that possible is often the only way to get it done in time.
I keep wondering how Java compares to Go these days. I'm not advocating Go, just wondering how much of an advantage Java has for server-side "web applications and services" for new businesses that are the usual small to medium scale with a single-digit number of developers and no legacy vs giant enterprise scale.
It just sounds as though the advantages of Java help large, complex systems of services and developers more than they help the vastly more numerous small-med systems.
Can someone with experience comment, because I'd like to understand the options a bit better.
This startup: https://www.kashoo.com/home was built by a husband doing all the tech, and a wife doing the non-tech part. The app was written using Java and GWT. Can the husband roll faster if it was using Rails? probably but not significantly.
Another anecdotes: I was part of a team of 3-4 developers delivering a portal solution for British Columbia compensation board (WorksafeBC, http://bit.ly/1QhUH8L NOTE: it's a few pages of PDF to show the size of the app).
The thought of Java is slow, not agile, and probably overkill for small team, small project, small this and that is probably not warranted.
I've mentioned this in another thread: choose Java and you'll set for at least 5-7 years with minimum problem, focus on solving business problems and less on infrastructure, upgrades of software/libraries, choices of latest du jour). Those open source libraries are damn solid and I very rarely need to worry much whenever I upgrade those libraries. Open the pom.xml, bump up the version number, sit back and enjoy the latest version.
Do you want to write a mobile app? 1/2 of the popular platform is already covered with Java so you just have to worry about the other one.
I'm having a very very hard time justifying the use of Go for "Web Application". I just can't see the benefit over Java (I'm scoping this to just those 2 platforms).
Java and Go are pretty similar at the language level, and you're right that the advantages of both are more applicable in large systems. For a small business situation something like Ruby may well be a better choice.
Java has a more powerful type system (though still poor by modern standards). Both have weaknesses regarding error handling - Go encourages you to err on the side of repetitive code, Java encourages you to err on the side of handling errors only at very high level, I'm not sure which is worse. Java has a much bigger ecosystem and better tool support, though a lot of it is written for pre-C10K days and assumes a "1 thread per connection/request" model - but frankly for a small business type situation that's fine. The go concurrency model is overkill at the low end and not flexible enough at the high end, but if you're in the sweet spot then you can write code more efficiently there than in Java.
>"If you're not picking the JVM in 2016 to build your core services and web applications then you're making a mistake that is going to cost you time and money either upfront in building things that already exist or later down the road when you start to need more performance and your RoR application isn't cutting it anymore."
That sounds like a fantastic problem to have. Airbnb, Teespring, (Rap) Genius, Github and many others have run into it and I don't see how one could wish more for a friend building out a new wep app in 2016.
The best part is that if you build quickly and hit scaling problems, you have the resources to invest into making your product performant. The second best part is that if you don't hit scaling problems, at least you haven't wasted time on optimizing something the market didn't want.
You forgot to mention Clojure which also has a dialect which compiles to JavaScript (ClojureScript) has excellent tooling (EMACS/Cursive/Leiningen) and has full interoperability with Java.
Does Kotlin offer anything Rails like with batteries included? I'm steering away from Ruby. I love Rails but ruby becomes a monster when a project gets larger. I've looked at TypeScript and Express.js but I'm worried I gotta deal with type definitions a lot.
Kotlin is pretty immature (and overhyped, IMO). Some people like Play and that's probably the closest JVM equivalent to Rails. I find the monolithic "batteries included" frameworks are part of the problem with large projects and it's better to have small well-encapsulated libraries that you can put together yourself.
I work in Scala and I use Wicket for HTML pages (technically a framework (though decoupled from any database access), but it gets out of your way a lot, has a very clean separation between the framework and your code (no magic)); it's probably the best example of good OO I've seen, in any language, with a component model that really works where all your pages are reusable components made of reusable components that are themselves made of reusable components, and there's a really clear separation between markup and logic.
If I'm writing a "web API" I use spray. It has this DSL that lets you write routing definitions which are as clear as a config file but are ordinary code obeying all the rules of the language, so you can safely refactor them the normal way. And it works very nicely with the scala type-system, letting you separate out cross-cutting concerns like logging or database transactions in ways that are low-overhead but visible and safe (and it's natively async, so can be incredibly high performance, not that I've ever needed that). For a "single page application" scenario I've used a TypeScript frontend (in angular) talking to a spray backend (I'd like to try out Scala.js soon).
Just curious, how do you figure Kotlin is over-hyped? Seems to me it has good tooling support, incredibly easy Java interop, and seems to produce more or less the same JVM code as Java (so good performance). All the while being slightly more pleasant to work with.
I think it's strictly worse than Ceylon - less mature, less featureful, and a lot less well designed.[1] And JetBrains have a bad habit of advertising features long before they're actually implemented, as well as talking up Kotlin for about a year and a half before it had any kind of stable release.
[1] And frankly if there's nothing it can do that Scala can't and the design isn't any cleaner than Scala (arguable, but I feel Kotlin is very ad-hoc and will look worse than Scala by the time it reaches the same age) then I'll just stick with Scala - whereas Ceylon can make at least some case for migrating from Scala.
Express isn't like Rails. It's more like Sinatra, but has probably even less stuff. There's no official or popular Rails for Node yet. People have made stuff like Sails but not many use it.
Yeah that's what I meant. The Node ecosystem doesn't really care for Rails-like frameworks so they stagnate. Most Ruby companies run Rails. Most Node companies run Express, Hapi, or Koa. Not Sails.
It's rails like through its middleware pipeline design. That's a requirement for me.
That allows Express third party middleware to add missing parts like Strong Params and easier HTTP Caching.
It would be nice to have batteries included but not at the cost of a giant box still design that I suspect Sails and other have. Pipeline design is important and Express does that really good.
Koajd has the same problem Express.js has, its batteries/middleware are not Omakase first class but third party. So I expect friction as things move forward in terms of updates. Ever dealt with RubyGems when upgrading Rails?
Imagine if your core app consisted of all different third party libs and you wanna update Express/Koa?
Then we have typedefinitions for all those libraries. Which why I'm looking for alternatives with typed languages.
You might have misunderstood my question or I'm getting things wrong again. :-)
All the Java frameworks are usable in Kotlin. I don't know any specific that covers all the bases Rails does - what I usually see are patchworks and a lot of SpringCore/JPA/Hibernate.
Personally, my go-to choice is always something simpler (eg Netty, Vertx, Spark etc - those are more like Express.js or Sinatra than Rails).
There's also JavaLite, which explicitly tries to look like Rails (including database migrations, an ActiveRecord-style ORM, etc)
Haskell is less of an option than any of the functional languages that work on the JVM. I like Haskell, it's a language that forces you to challenge your knowledge and assumptions. But it is not in the same level as JVM langs. Maybe once it matures more. Hopefully.
I'm skeptical that any other language will be nearly as easy write, operate, and maintain in production as Java.
It's really easy to administrate Java applications. You can connect to the JVM and examine what objects are in the heap, or request a thread dump and see what threads the application has launched and what they're doing. There are rarely any (JVM-level) correctness issues since code is safe and has a simple exception model - JVMs are rock solid and virtually never crash. There are advanced profiling tools available, and simple ones built in. It's easy to deploy applications due to Java's jar and class model. You can inspect a class and see its code as-deployed. Building Java code is simple, so there are rarely any build tooling or reproducibility issues.
Java also has excellent tools for logging and metrics emission, like Log4j / Slf4j and utilities like Metrics. These are just a few of the system-level features that are critical in large-scale deployments, and in practice these elements matter quite a lot for managing production apps. The language itself is only part of the story.
The Java language has also been improving substantially. Java 1.8 launched a lot of great features, like lambdas, functional interfaces, streams, and other modern elements that give me most of what I expect from a modern language and allow me to write clear and concise code that is statically typed, in the context of really strong IDEs. Java's portability makes it straightforward to develop an application from any platform (not just the server platform you deploy on).
IDE support is crucial and frequently overlooked. Automatic code completion, refactoring, and inspection ("show all usages of this method") are essential to working on large code bases together as a team. Java also has style enforcement and static analysis tools like FindBugs, Fortify, CheckStyle, etc. Java's open source community is extremely strong - look at all of the work happening under the Apache umbrella such as Hadoop, Spark, and Hive [1] or Google's umbrella, like Google Guava [2] or the Dataflow SDK [3]. There are excellent concurrency tools like java.util.concurrent, Guava's futures, and Akka.
I agree with meddlepal on this one. It's hard to do better than Java for the backend.
I don't really know how most of these relate to Haskell specifically. For example, you bring up safety and the exception model used in Java, but Haskell puts an even higher priority on safety/correctness than Java does. IDE support may be weaker, but IDEs tend to solve problems very specific to the languages they target, namely Java in this case. Refactoring is seen as much less of a problem, for example, since the lack of side effects lets you move any function to wherever you want in your code without breaking anything and the type system/compiler guide you through the entire process if you mess something up. And besides, pretty much every popular editor or IDE has a Haskell plugin that is easily as good as most of the Java tooling out there.
These are the kinds of questions I'd be concerned with:
Can I easily develop Haskell from any platform (Windows, Mac, Linux) and are good IDEs available on all of them? My team is diverse and I don't want to tell my engineers what platform they have to use for development. Can I meaningfully develop my server software on those platforms and deploy it to another OS (Linux)?
I agree that Haskell's type system will catch problems made in refactoring, but it's about avoiding the effort. If I wish to rename a method or a class, I don't want to spend time updating the text manually everywhere that is relevant and working through compiler errors - I just want to say "rename class", "rename method". In large code bases this prohibits people from improving the code over time and doing maintenance work.
Are there Haskell IDEs of equivalent quality to Eclipse and IntelliJ? My software development is a lot slower if I need to remember the standard library precisely and type its methods and classes, rather than typing TPE and allowing the IDE to auto-complete it to ThreadPoolExecutor; and it's a lot slower if I can't highlight a method and quickly invoke the IDE command for "show me all methods that call this method", or "show me the implementation of this class / method". I've personally found that this kind of code authoring and navigation assistance has a dominant impact on practical development speed.
When I've written a unit test, can I easily select the test in my IDE and run that single test with a keystroke, attaching a debugger if needed? (Maybe Haskell needs fewer unit tests, but for business software I doubt it.) That same test suite will be run by my build system at build time to make sure everything passes.
How would I accomplish in Haskell the equivalent of what Metrics helps you solve in Java? https://dropwizard.github.io/metrics/3.1.0/ Or Log4j and Slf4j? Managing log messages from large applications is important, since log messages are the primary after-the-fact record of what processing took place. They're often all you have to go on, aside from any metrics you've produced. (I would not buy the idea that Haskell code is so defect-free that these kinds of tools are unnecessary. In any case, Metrics is about performance metrics and business-relevant metrics.)
Are there profiling tools comparable to JProfiler? Can I easily get stack traces and heap dumps at runtime? In Java there are great interactive tools to explore these, to inspect every object and its properties and GC state. If the application crashes (not the runtime), is good troubleshooting information available to figure out what went wrong? It's more difficult, though still possible, to attach debuggers to production code and step through, so log messages are a poor man's after-the-fact trace. That said, I can still attach a debugger to a JVM remotely over the network and inspect the threads, heap, etc., and step through code execution. Is it easy to debug (attach a debugger to) a Haskell program as-is over the network in production?
How would I write a distributed map/reduce job with Haskell and execute it across a large fleet, like I would with Java using Hadoop, Spark? Are there distributed actor frameworks with the quality of Akka, or messaging systems like Kafka? Are there good RPC libraries for Haskell to interact with other applications written in Apache Avro, Google Protocol Buffers, Cap'n Proto, and so on? The tools I mention are solid, and very widely deployed - they're not obscure.
There are a lot of practical large-scale problems that I can solve easily in Java, ones where many other programmers would be familiar with the solution I'd use. If there are good ways to solve these problems then I'd love to learn more. I've always been a fan of the Haskell language and its concepts, as well as F# and Scala. However, despite my wish to use them, I've run into a lot of practical challenges. These extra-linguistic factors involved in running software in production dominate the linguistic ones.
Those are absolutely the correct kind of questions to be asking. I think Haskell has very good answers to most of them, sometimes better than the answer for Java. I actually use Scala pretty much full time these days myself, but I think the original post was overstating the case for the JVM. I agree with the value of a single runtime, good instrumentation, and avoiding non-memorysafe or non-crossplatform code, but the JVM is absolutely not required to accomplish those things.
You can do RoR on Jruby. It won't be as performant as staticly typed languages, but it is often good enough. You do lose the benefits of static typing though with refactoring.
I work at HubSpot, and was among the initially skeptical from having had bad experiences in Java in the distant past and spent more time in Ruby in the years prior which I mostly enjoyed.
The Java ecosystem truly saved itself from its own enterprise madness. Libraries and frameworks today look nothing like they did in the past. I think that is somewhat due to language features (annotations, lambdas, etc) but also due to a cultural shift in what is valued.
One of the things I've appreciated more than I would have expected is by having a single back-end language we have very strong community of developers. There is no split among different factions. (I hear rumors of sharp divides between python and node camps at Uber, for example.) Even though technically we have a platform capable of running languages in many languages, the value of the community focused on a single back-end language toolchain is extremely valuable.
This right here. I have been preaching this message for ages. You simply cannot account the immense benefits of having everyone working on the same stack. Even just splitting into two languages you start getting huge knowledge barriers and a major loss in shared skill growth. If you've chosen Java/C#/etc for your base language you need to have a DAMNED good reason for bringing in another one. And the other one being the best option for the problem of the day is not a good enough reason if your primary language is capable of solving the same problem in a slightly less elegant way.
Yep. I've used a variety of different languages, and it always struck me as odd that Java was considered some uncool cumbersome language, and enterprise-y in some sort of bad way. It's not a dream to code in, but it is highly practical and in no way limits what you can do or makes anything particularly hard. I see now that I joined the Java party in better days.
I've done a lot of Java, and I'd say the stereotypes didn't come from nowhere (XML is great! Enjoy using XML for dependency injection and configuration!). Not to mention the lack of expressivity of the language causing the proliferation of FactoryBeans.
The other issue is that the "IE effect": the language stopped evolving for years. In the meantime, Microsoft launched C#, and Java is only catching up now in terms of convenience. But even with Java 8, as far as I know, a lot of things are still strictly worse than in many other languages (no import aliases in 2016, no shorthand for getters/setters...). To a large extent, it's still a language that forces you to live in a IDE even for trivial things, due to the amount of boilerplate you need for even simple things.
Of course, compared to C#, it still benefits from a considerably larger and IMHO higher-quality ecosystem, as well as working very well with some non-Java open-source solutions (eg, Postgres), though it's generally poorly integrated on all platforms it runs on.
C# the language is fine, but C# the ecosystem is kind of a mess. There are multiple approaches that attempt to solve the same problem (PCLs versus shared libraries; both have their place but they overlap uncomfortably) and cross-platform development is an abject disaster (CoreCLR may eventually get to a good place but I wouldn't use Mono in production for long-running services). NuGet--itself a problem in many ways, it's very poor the second you get off the happy path--exists but in my experience its usage is spotty, whereas even the jankiest Ant projects I've ever worked with at least used Ivy. Libraries in NuGet are also, I think, a lot more hit-or-miss than I'm used to either in Ruby or on the JVM. Some stuff is real good (JSON.NET!). Some stuff is real, real bad (the bajillion competing and differently defective YAML tools), and there isn't the same sort of cultural focus on pushing the good to the forefront.
This isn't a strong defense of Java, because I think the JVM and its ecosystem isn't super great either. I really like C# and I pay for ReSharper despite not doing C# professionally (I've been using it for about a decade but never taken a job in it). But while C#-the-language has greatly improved, the ecosystem still feels five-plus years behind.
That's why I think Kotlin is going to clean up. It's a language specifically designed to be commercially successful by providing you with a better Java. For instance this line of code:
data class Person(var name: String, val age: Int)
compiles down to a JavaBean with getName/setName type methods, a getAge but no setAge (val is immutable), an equals, a hashCode, a toString and a few other useful methods as well like copy() which lets you create clones of the object with any fields modified.
So with Kotlin you get many of the benefits of C# and some features that C# is only just introducing now, or in its next versions, but it all interops seamlessly with Java.
I think it will fail in the same way as Xtend or (to a certain extent) perl. It puts too much focus on one-off productivity features which results in an inconsistent language with loads of edge cases, and it doesn't have any compelling "you can't do this in Java" selling points, just a bunch of minor syntax sugar.
Ceylon has all the advantages of Kotlin, but put together a lot more coherently, and with a really compelling fundamental feature (union types).
Last time I used it was when EJB, JSP and co. were "big". And it always felt like a struggle to get this strange overload of "design patterns" running. Maven and code generators did their fair share to add some "what is even happening"-moments to my experiences.
I just sticked to get things up and running fast with JavaScript and throw in some C if the performance suffers too much.
my last exposure to Java was many years ago in the EJBs timeframe, and I didn't have a lot of fun with it (leading to staying away from Java positions since then).
Last year I had to work on a Spark application and I was honestly a bit uneasy when I started but I was quite surprised at how much nicer it was to develop in Java 8 and how well IntelliJ worked (first time in probably 20 years that I wasn't using emacs for development) and the performance was quite surprising as well.
I still mostly work in python day-to-day, but if I was looking at starting something from scratch, Java would definitely something I'd look at quite seriously.
The post mentions a few: Dropwizard for RESTful APIs (http://www.dropwizard.io which includes a bunch of good libraries), Guava, Guice, Hysterix, etc. We use Kafka for stream processing, Hadoop for batch processing.
SQL is just one type of DB language we use, but yes we use JDBI with some extensions we've built (such as https://github.com/HubSpot/Rosetta and other non-opensource) for our SQL database of choice, MySQL.
But we also use a number of other databases with native java clients, such as HBase and ElasticSearch.
Parallel Universe made a comprehensive 3-part blog post to modern Java. They cover language features like lambdas, as well as notable libraries for build, deployment, monitoring, and web development.
So, is the idea to avoid ORM, JSF, JavaBeans, CDI Beans and all JavaEE in general?
How is web application development done? I guess the back-end is made in Java with an API, and another language is used for the front-end.
I agree that Java is the best programming language to write web services in right now.
But I have to admit that the most threatening counter-argument to using Java in 2016 is that Scala is, to all appearances, a strictly better language. It's similar to Java and does everything Java does, but better- it has type inference, it does away with primitive types and arrays, it has compiler-checked string interpolation, it has declaration site variance, it has a richer collections library, powerful syntactic sugar, robust mechanisms for dealing with asynchronous programming... I could go on and on. And it's deeply interoperable with Java so it should be a no-brainer to use it wherever possible.
Java's saving grace in my opinion is, ironically given Java's history, its culture. When you find that you need to use a small class from a library, you pray that it's written in Java, because most of the time you can just go to its source in your IDE and see painstakingly detailed Javadoc describing exactly what each public method does and common pitfalls. And Java isn't very expressive so all code looks the same- you just have to understand how the components interact with each other. If, on the other hand, the class is written in Scala, you're vastly more likely to crash into a brick wall of undocumented one-liners that are complicated greatly by uses of the downright tricky bits of Scala's type system. Using typesafe's libraries (akka/akka-stream/slick) is an exercise in poking your code experimentally until it magically compiles, usually due to some random undocumented import. And scala culture's love of DSLs and lifted types is downright hostile to ease of debugging. It's hard to overstate how much of an impact these factors make throughout a workweek.
And yes, lots of Scala code is good and lots of Java code is bad. But I think the stereotype generally holds true.
On the contrary Scala is baroque, its syntax is not following any known pattern. For example if I want to write a recursive function I have to indicate my return parameter type otherwise not. It doesn't matter whether you come from a C background or a Java background...or any background because of this:
> def addInt( a:Int, b:Int ) : Int = {
> var sum:Int = 0
> sum = a + b
> return sum
> }
You have to relearn how a function looks like in the first place. Return types are at the end, parameter types are after the parameter name separated by a colon.
If you want a language which runs on the JVM Clojure is a way better option. You don't have to learn its syntax since there is hardly anything you can call one. It is binary compatible with itself which is not true with Scala, you can choose whether you want a type system or not since it is optional (look at clojure/core.typed). It is also interoperable with java but it has a much better functional approach to programming compared to Scala since everything is immutable but it is not wasteful because of persistent data structures and for concurrency you have the STM which IMHO is a strict upgrade to the Actor model. Writing DSLs with the powerful macros Clojure has is more usable than any non-lisp language and the result is more expressive.
So to add it all up with Scala you add a lot of complexity and a lot of pitfalls you can fall into while with Clojure you take away complexity while retaining the vast Java ecosystem for interoperability. Don't take my word for it but take a look at Uncle Bob's talk "Clojure is the new C" : http://www.infoq.com/presentations/clojure-c
Function declaration syntax where the return type is last is very common in functional languages. It's even allowed in C++11, because it allows one to define return types that depend on parameter types. An example taken from http://en.cppreference.com/w/cpp/language/auto,
template<class T, class U>
auto add(T t, U u) -> decltype(t + u) // return type is type of operator+(T, U)
{
return t + u;
}
It's quite a sensible approach, and hardly an impediment to understanding. A more valid concern is that Scala introduces a lot more concepts. I don't necessarily agree with it, but I think it's a potential issue, whereas a simple syntax difference that a lot of languages have is not a big deal.
> You have to relearn how a function looks like in the first place. Return types are at the end, parameter types are after the parameter name separated by a colon.
Sorry but you pretty much say clojure is the best, however it has a lisp syntax, which IS baroque and most people aren't use to this.
These days if you want to have a functional style.
You eiter use Scala or Kotlin.
Clojure is too much of a unicorn. People won't learn this. Also people doesn't care how good the language is or what design patterns were used. People use these languages cause they think the language has a actual value for them (as you think about clojure)
By baroque I mean it is overly complicated. Clojure syntax or LISP syntax for that matter is everything bot overly complicated.
> People won't learn this.
Say that to Uncle Bob or the guys who maintain ClojureScript, Cursive (JetBrains based Clojure IDE) or Om which is a port of React not to mention Apache Storm which was written in Clojure.
Don't get me wrong I still think Clojure has it's place, but saying others are overly complicated when talking about Clojure is somehow awful. Lisp is near dead, without Clojure lisp would only be used to train how to implement parsers, compilers, academic stuff.
Yeah there are a few people who know lisp, you also forgotten about Walmart, which is a lisp user, however the majority of people in functional languages still won't learn Clojure.
But still don't care about, use the tool/language you are familiar with, especially if you could use it in your company. I also see a lot of pressure against scala, and I'm a scala user, but I just don't care.
Types on the end are very common in many languages, a lot more common (and IMO readable) than lisp-style (+ a b) which you have to learn to use clojure.
An optional type system is almost useless (believe me I spent a lot of time trying to use the checker framework in Java before switching to Scala), because libraries don't have to follow it, and you never know whether the type definitions for a given library are true or not.
Scala is generally immutable by default and has persistent data structures.
STM is great but you can do it fine in Scala. It's just not a language-level feature because it doesn't need to be - Scala is expressive enough that you can write an STM implementation in a library.
Scala's DSL support is great (look at e.g. Spray route definitions) and can usually done in ordinary code without macros, which in turn means you have full IDE and tool support for them. The trouble with lisp DSLs is that your syntax still has to look like lisp - the support for e.g. infix operator syntax is quite limited (you have to use reader macros which are more complicated and harder to work with). But for a lot of business domains the natural language of the domain uses infix operators.
> When you find that you need to use a small class from a library, you pray that it's written in Java, because most of the time you can just go to its source in your IDE
I have to say, this is the big plus for Java for me. I find myself in the weird position that while I dislike writing Java, I love reading it. The simplicity and constrained nature of the language, the incredible IDE support, the JVM features (connect to a running VM and start setting breakpoints to answer questions like "when does this method get invoked"), etc. It's hard to escape the logic that if I want people to like reading my code, I ought to be writing it in Java.
You are right: Scala is a wonderful language crushed by its culture. Not only the DSL love.
And then there's the in-language tribalism. You find people that work/worked in Twitter, that tell you that anything that Typesafe, the company that does most of the development of the language, is not worth using: They have their own stack for everything. Then, you have the Scalaz tribe: They also dislike the standard library, along with the Twitter libraries. And now we have TypeLevel, which splinters from the scalaz group. You don't have one camp: you at least have three or four, and having talked to prominent members of each of those subcultures, good luck ever getting them to try to unify anything: There is much intra tribe hate in public, and it gets even nastier when they are in private.
Having worked with people from each tribe at one point or another, I think that the situation is pretty hopeless, and the community knows it. The best way for Scala programmers to bond is to hate on a tribe that neither of them belongs to!
Just look at the two keynotes in Scala exchange 2015: One by Jessica Kerr, the other by Miles Sabin. Two people that come from very different backgrounds, writing very different code (business scala vs shapeless). But what both were talking about was how far the community has to go to make the language more approachable. And yet, I am pretty sure that the code Miles finds approachable, Jess would find completely unapproachable, while Miles might hate on how Jess doesn't really use enough types.
Kotlin has most of the complexity of Scala, and very little of the power. If you want a clean language that offers Scala-like functionality, Ceylon is the one to watch.
I spent literally one evening reading Kotlin reference and I understood an entire language. It's just a Java with slightly altered syntax and a lot of simple yet useful batteries included. I immediately was able to start coding and reading standard library. On the other side in the past I spent around week reading book about Scala. Yet I couldn't read Scala library, it was just too complex. So I don't agree that their complexities are even comparable.
Scala is like a Haskell. It's very powerfull, but to understand and use the entire language, one should make a serious investment.
That's because Kotlin puts the complexity in the language and Scala puts it in the libraries. A lot of things are just a rule of the language in Kotlin but they're implemented in ordinary code in Scala. E.g. extension methods. Which means you can "understand" them quicker in Kotlin, but you can't change how they work or use them to implement a new structure.
> you can "understand" them quicker in Kotlin, but you can't change how they work or use them to implement a new structure.
I'm not sure that extension methods are a particularly fitting example here.
Scala adds a lot of boilerplate for — in my view — very little gain. Of course, Scala's extension methods are actually a special case for implicit conversions; yet, the Scala we write today in my experience tends to avoid implicit conversions per se.
E.g., I'd rather be explicit about a type conversion when that is what I want to achieve: for instance, I'd rather read `javaListMethod(mySeq.asJava)` than `javaListMethod(mySeq.asJava)`. Thus, I'd rather have a first-class construct for extension methods rather than having to write `implicit class RichSeq(val s: Seq) extends AnyVal { def asJava = ... }`
Boilerplate is a problem but doesn't make a language harder to understand. Language-level shortcuts to reduce boilerplate generally make the language harder to understand, IME (I'm thinking of e.g. Perl's $_).
I actually agree that implicit conversions are to be minimized. But you do need a way of doing the equivalent of the magnet pattern - which in Kotlin is either a different language-level feature, or simply impossible. I'm hopeful that a simpler underlying abstraction can be found - but Kotlin feels to me like it's just piling on a bunch of special cases without making any effort to be consistent or unified.
You won't be able to implement type classes. There might be something in that direction after 1.0; still, Kotlin is not supposed to be a contender with Scala w.r.t. expressive power. It is just Java with more concise syntax, and with most design patterns turned into language features: singleton, delegates, lambdas/sam, "utils" classes (extension methods).
This. Ceylon is what Java should have evolved into with better stewardship. Too bad it does not have the marketing muscle of a big corporation/consortium.
Has anything happened in Java to correct the fundamental issues raised in Steve Yegge's 2006 opus Execution in the Kingdom of Nouns[1]?
I last used Java two years ago, writing an Android app, and at the time I think Yegge's critique still stood. Not to mention the fact that it was a colossal amount of typing and boilerplate in order to do anything.
We're using Go at the current place, and I'm loving it. Android development in Go would be a sheer joy.
When you try to use Java you will need new, young programmers.
Experienced Java programmers will most often be indoctrinated/trained/used to over-engineering and wrapping everything in layers upon layers of abstractions. And the existing Java learning books, tutorials and examples still tend to follow that mindset.
The more abstracted your code is, the slower it will run, the more memory it will consume and most especially the more difficult it will be to get a new developer up to speed.
This sounds like unjustified FUD. It's not been my experience. A large amount of infrastructure at companies like Google, Amazon, Facebook, Ebay, etc. is written in Java and the code I've seen from those companies is well-engineered. Google Guava stands out as an example of extremely strong style. Apache Hive and Avro (from Facebook) are also clear and not overly complex.
I believe you that there are ineffective programmers of any language who over engineer, but I haven't seen that from personal experience with Java programmers. To the extent that it's a problem, it sounds like a hiring problem rather than a Java problem.
Guava is much better than average Java, even written at Google by experienced engineers. There are few who have the luxury of polishing to the extent they do.
> A large amount of infrastructure at companies like Google, Amazon, Facebook, Ebay, etc. is written in Java and the code I've seen from those companies is well-engineered.
Being a big company doesn't imply good Java code. Just look at Lotus Notes, SAP, Eclipse, the whole IntelliJ ecosystem... all slow-as-fuck, resource-eating monsters that have fast, non-Java alternatives that prove that the job can be done in "fast and lean" (except SAP, though. But SAP rants, I tend to get carried away in these).
Sorry but I don't feel that way. I've been using Java since 2008 and have worked with other engineers. Nobody would want to write more code than it has to be.
I also don't see tutorials or books that create too many layers for a while (especially post EJB2/EJB3.0 days).
While it's possible you have discovered some exciting new problem, Eclipse is likely more your problem than the JVM. I've never increased the heap size of IntelliJ from its default size of 750M except when dealing with extraordinarily large Scala projects. I've had Sublime Text use more RAM than that with some plugins.
I prefer VIM, but I still need Eclipse to do my job effectively due to circumstance.
Like Eclipse only plugins whose functionality I would have to take time I can't justify to duplicate. Plus the additional maintenance cost of the dev team no longer having a homogeneous environment. All to allow me to be able to... do what I already do.
Don't get me wrong, I'd really enjoy taking a week to explore the options and put together a better development environment for myself and my team. I do make improvements where I can already. But we're already an effective team despite Eclipse's flaws, the RoI just isn't there from a business perspective.
Did you hear then over the sound of your garbage collector?
But seriously, I'm a huge JVM fan yet I know that if memory is a limiting factor, I should look elsewhere. I just don't current work in any environments where my program has less than 64mb to use.
in the Ruby world people end up consuming more RAM when using the C based ruby (MRI) because in order to achieve concurrency they must scale with processes and that consumes an absorbent amount of RAM. With JRuby you can scale concurrency with native threads that have minimal memory overhead.
> in order to achieve concurrency they must scale with processes and that consumes an absorbent amount of RAM
While the trolling you responded to about Java and RAM is untrue, this also is not really true (I assume you meant exorbitant, not absorbent). Concurrency happens just fine in MRI in many cases because the blocker is the global interpreter lock; if you're doing I/O, threads operate concurrently in MRI. In addition, the overhead of a process in Ruby isn't all that much, and in the rare case where it is (typically a web application) you've got tools such as Unicorn that will prefork and allow you to share/COW that overhead.
The overhead for a unix process is significantly more than a lightweight JVM thread. In some cases this memory overhead can prevent you from utilizing the smaller cloud instance types which are sometimes the most cost efficient.
Also with MRI you can't light up all 4 cores, or 8 or 16 without spawning extra processes which burn memory and that can make your server less cost efficient if your app can use the RAM.
I would gently suggest that you are laboring under incorrect assumptions. There is nothing "lightweight" about JVM threads; they are standard native threads on normal platforms and on Linux a thread context switch has roughly the same performance overhead as a process context switch. (There is a difference, and if you study the kernel source I'm sure you can divine it, but you will also quickly realize that it is a rounding error compared to the first cache eviction of the new context.) The memory overhead of a process in Linux is literally measured in tens of kilobytes.
I also suggest you look into preforking and copy-on-write and ensure that you are clear on how Linux works with regards to memory usage; modern Linux systems indeed do not necessitate "burning RAM" to use multiple processes (indeed, the fork paradigm is the standard Unix approach for a reason, it only makes sense to make it performance-friendly). I would also note that while a Ruby or a Python can do this, Java, in standard configurations, cannot, were one to desire the ability to do so (and I've had reasons to run JVM applications in a multiprocess mode before).
I don't dislike Java, don't get me wrong. I write a great deal of Kotlin. But accuracy is important.
I know they're native threads, they're lightweight compared to unix processes. You're trying to change the subject to CPU performance during context switch when what we were discussing in memory consumption.
The memory overhead of a MRI ruby process running on linux is much higher than the overhead of a native JRuby thread, they are apples and oranges, surely we agree on that point because you can check it via a simple ps aux command.
Perhaps I am mistaken, but from what I've read to run unicorn following their recommended guidelines you need to spawn at least 1 MRI process for every CPU core, but if your application blocks on IO rather than CPU during it's request cycle which is common then you will need more processes than CPU cores in order to handle concurrent HTTP requests. At that point you're wasting many orders of magnitude more memory than JRuby for every "unit of concurrency" so to speak.
by the way Kotlin looks interesting, thanks for pointing it out I was not familiar
Attempting to cite `ps`, which includes the unique pages as well as all shared pages used by the process--i.e. pages created by its parent to store such trivialities as the entirety of the Ruby runtime and the classes loaded therein--makes me question your understanding of the Linux process and memory model. Do you understand how fork(2) works on a modern Linux machine with regard to memory page sharing from parent to child? Suffice to say that nobody running a hojillion processes in Unicorn or another forking process worker--and I should point out that I have written one of these in Ruby, this isn't Unicorn magic--is suffering under the tyranny of large amounts of duplicated data. (I'm sure there are people who spin up X of a process from the jump, but they are swimming upstream and are not the norm in my experience.)
The difference in memory usage between a forked process on a shared-page/copy-on-write OS and a thread is infinitesmal. You'd have better luck arguing about having a JIT and better perf (and there you'd be incontrovertibly correct, but I don't think it really matters for 95% of everything).
So, Java guys, what do you recommend if someone wants to have a Rails-like experience where programmer time is more valuable than 'web scale' performance? Say, also that I don't want to have to pay oodles of money for some server with a terabyte of memory to hold the application. Honest question - I haven't kept up with what's happening in Java land, and am curious what you'd recommend for that kind of side-project thing.
"Dropwizard (http://www.dropwizard.io/) pulls together stable, mature libraries from the Java ecosystem into a simple, light-weight package that lets you focus on getting things done."
It's easy to get up and running, and I've grown to appreciate the emphasis on stable, mature libraries in Dropwizard compared to some of the more bleeding edge libraries that I've fought with in other "opinionated" Java frameworks that try to approximate the RoR experience.
Dropwizard gives you the option of using either JDBI or Hibernate for an ORM. My suggestion would be to go with Hibernate, even though it's a beast and you will waste time deciphering cryptic error messages and hunting down crippling N+1 select performance problems. Even with those issues, I feel that Hibernate is worth using, as even on small projects it can save you from writing thousands of lines of monotonous database access code.
There is [Grails](https://grails.org/) which I honestly did not use so I can't comment on it but people seem to like it. It is Groovy based though. The most common framework nowadays is Spring and its ilk (including Spring MVC and its friends). BUT there is Spring Boot which is basically a meta framework which takes an opinionated "sensible defaults for all the stuff" approach and you can get a project working with 5 clicks basically. Try out the [Spring Boot initializr](https://start.spring.io/). The biggest problem with these frameworks is the magic. While you are fine with the defaults it works. You can check the config files and tinker with them but there are a lot of layers to peel away if you are presented with some exotic Exception which will happen sooner or later. I'm also interested in what other options I have in Javaland currently because I'm steering away from it to Clojure islands and even the Node archipelago...
I'll put a second vote for Spring Boot. You're right that when the magic fails it can get a little complicated. However, I've found Spring documentation to be very good. Also, once you understand a little of how it's put together it becomes pretty easy to selectively replace whatever piece of the magic with your own custom version.
I know but I'm not sure I want to do it every time the magic breaks. In clojure for example I only have to dig into compojure and ring 4-5 layers deep involving 20 files. With spring with all the reflection, indirection (annotation processing) and such it is common to have a call stack 30-40 levels deep. Much more time consuming to debug imho.
> I can't comment on it but people seem to like it
Not sure how many Grails 2.x systems out there have been upgraded to Grails 3.x, or how many new Grails systems have been started in version 3.x. I don't think it's many though, which suggests a general decline in Grails use.
For a side project I've deployed some simple endpoints to Heroku and used Spark (http://sparkjava.com/). Spark is a Java Sinatra clone rather than full Rails.
That said, not sure I'd pick it for simple side-projects. Part of the benefit here is how it works for a large dev team, with a large codebase, etc.
Could you elaborate on that? With OpenJDK at least the software side of things is pretty much stable and open (in a FOSS sense), so I take you are referring to possible legal ramifications of Oracle's actions?
I never really managed to figure out the OpenJDK story apart from that it is what gets included in Linux distros and it sort of works. Read not too great stories about its performance in the past, am not exactly sure about its compatibility (it seems to lag behind a bit), Windows support is a whole complicated story of its own... Call me ignorant, but at first glance it doesn't look attractive. On top of all that, indeed Oracle being involved with development at all, together with their reputation of being a legal hothead.
Not mentioned in my initial post, but I also like to keep my code portable between server and client. Firstly, there's no way I'm going to require clients to have Java installed. Secondly, a truly native GUI is practically impossible, so I would already corner myself into needing a second language anyway.
OpenJDK performance has been closing the gap with the Oracle JRE over time. One big gap was different graphics renderers but this is being fixed in Java 9 (possibly earlier).
Java 8+ has a "javapackager" tool that makes native installers/packages for each platform which contain a bundled JRE. So your users no longer need one installed themselves. And finally SWT lets you use native widgets if you want them.
It did not seem to really address the issue of polyglot very much (given it is in the HN title) rather than just promoting the virtues of Java. One of the strengths of the JVM is the ecosystem of JVM languages that has evolved. You can stick with the JVM and get many of the benefits mentioned while still being polyglot. In particular you can throw in a dynamic language (Groovy, JRuby, Jython) alongside the Java core and get the benefits of a dynamic language for parts of the code where that is suitable, without losing many of the other benefits. Groovy, in particular, is 100% bidirectionally compatible with Java and has close enough syntax that a developer team well versed in Java will pick it up quickly. Perhaps Kotlin qualifies in this regard as well. To me the optimal setup is a strong Java core defining the APIs and core services, while the less core code can benefit from using more expressive dynamic languages. For example, the drudgery of writing unit tests is hugely alleviated by doing in something like Groovy rather than straight Java.
> Groovy, in particular, is 100% bidirectionally compatible with Java and has close enough syntax that a developer team well versed in Java will pick it up quickly.
Groovy's only close to the Java 1.7 syntax. Java 1.8 uses the -> symbol in a completely incompatible way to Groovy.
And the most common use case for Groovy, i.e. Gradle, only uses some DSL syntax which is totally unlike anything you've seen in Java. There's no overlap at all.
Groovy feels like it's dying as far as I can see - partly because you can write almost word-for-word the same code in Scala and not have to sacrifice type safety.
I think the problem is more that development has really slowed since they lost the sponsorship of the company that was funding development (which employed almost the entire dev team). It's not clear to me what the future of Groovy is. However it's about 1000x more accessible to Java developers than Scala is. Scala reinvents the whole type system and uses custom collections etc. That makes reverse interoperability (I write a class in Scala and then use it from Java) significantly more challenging than Groovy where Groovy code looks identical to native Java in most respects.
You can use Scala like that if you want to though - you can stick to the Java collections (even implement the scalaz typeclasses for them), or one effective technique is to write a Java interface and then have a Scala class implement it. Most Scala users do find it worth moving beyond Groovy-like code, but you don't have to.
> Groovy code looks identical to native Java in most respects
Maybe your definition of "most respects" doesn't include the Gradle DSL or Java 8 lambdas.
Nowadays I use Clojure for those quick'n'dirties testing Java code. A well-placed macro eliminates plenty of boiler-plate specific to the test at hand.
Java platform and libraries are very mature and good. Java as a language is not. I suggest to take a look at Kotlin. It uses JVM, it uses Java standard library, but it provides much better language, while keeping simplicity and it's close enough to Java to be a drop-in replacement. And IDE support is excellent, if we are talking about Intellij Idea. Kotlin is really Java++. No reason to choose Java over it.
Another option is Scala, but Kotlin is superior for most projects IMO.
I have two good reasons not to choose Kotlin. The first is until I started reading this thread on HN I had never heard of Kotlin. The second is I attempted to find kotlin in a job listing on Monster.com in several major cities and managed to only find one single listing in Los Angeles. The job listing says they are transitioning to Java. My argument of course is from the greater view of the business and not a laser focus on Kotlin as a technical decision, but for most projects you should choose a much safer option with insane amounts of support and developers on the market by the boat loads.
I will say, Java performance always impresses me. Trying a few benchmarks relating to economics, OpenJDK 1.8 somehow beats C++ and Fortran on my machine (!!!). And of course, there's plenty of nice, high performance JVM languages (Kotlin, Scala, Clojure), and you can tune the JVM a number of ways.
I can certainly imagine a future where Java is the top performing language for any application.
My choice is Kotlin. Java8 is a bit strange, and does not have many features: type inference, named and default arguments... Scala is too heavy and sometimes complex.
Kotlin is best of both worlds, highly expressive, good compatibility and pretty simple.
Maybe for the backend, but for the frontend Java has messed up really bad. Some of the worst aberrations ever created in the history of software development are Java frontend frameworks: think JSF to start.
There is nothing like Javascript for the frontend, and if its for developing micro-services and not monoliths I think Javascript is also a pretty good choice for the backend as well. There are some good solid libraries like express, sequelize, passport.js that be used to build solid micro-service backends, in every way comparable in functionality and performance to Java.
> I think Javascript is also a pretty good choice for the backend as well.
Definitely not for me and for a few of my buddies who happened to use NodeJS already. NodeJS is a good "glue" appserver for gateway to other microservices I give kudos that far but not more.
Its nice to see articles like this. JAVA seems to be the butt of many jokes on Hacker News. It seriously makes me worry that i'm a bad developer or something because i actually like JAVA + Spring.
To me it's not so much Java that's the problem, it's the kind of programmer it seems to foster. The language itself is simple enough, so people invent all kinds of architectural bullshit and overengineer everything to hell to appear smart. As a result you get code that replaces compile time errors with run-time errors, and it's fucking impossible to debug or understand because everything needs three dozen libraries and five hundred classes before you can even start doing anything worthwhile.
This is not Java's fault, per se. You can write simple, performant, sane code in it. It's just that 95% of people choose not to.
I have a feeling that this is part of the reason why Go is gaining popularity (even though I dislike Go as well, for different reasons): much of this garbage (such as DI frameworks, AOP/runtime bytecode modification out the wazoo) are either impossible or deliberately inconvenient there, and writing overly complicated code is socially unacceptable.
It's interesting to see shift towards. Always remind of 2005, when everyone was blogging about RoR.. Then 2010, everyone was blogging about scala. Personally, I could never find any good reason to move away from JAVA. Yes, learning multiple languages might give you better perspective on software development but when we talk about some serious enterprise software development (it's not only language but cost of development too), JAVA is good enough.
-=-=
Another thing I am realizing, over the period, specially shift in architecture style because spring (aka IOC pattern), it has made programmers better. We can't blame everything on EJBs etc any more. Early JAVA programmers were treating java as magic bean instead of putting good effort on learning & writing programs right away.
Oracle should thank Apache & Spring.. in my opinion.
I'm a Clojure fan, but I always have this niggling concern in the back of my mind that Oracle is going to do something catastrophic and fracturing to the JVM and Java.
Say what you will about Java the language (I agree it's not particularly "sexy") but the JVM is a performance beast. You can write Java or pick from one of several other languages that range across different paradigms from static functional to dynamic (current gen: Scala, Groovy, JRuby, Jython, next-gen: Kotlin, Ceylon). Integration is usually painless between these languages. It's also highly configurable and can be tuned to virtually any workload.
You get the huge benefit of a very mature and common shared infrastructure and tooling environment. Your operations team will thank you for solidifying on a single runtime environment.
Java is great. The whole ecosystem is really really solid in general and it's truly a pick what you want platform at this point. The JVM is magical for web applications and services.