Hacker News Reader

Comment by meddlepal | Hacker News Reader

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.

View on HN

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.

As a side note, Kotlin does properties very much like C# - take a look at it the next time you're doing Java and have a choice in the language.

I see a trend of more community for .Net ( because of Microsoft's efforts) and less through Java ( because of Oracle's non-efforts)

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.

Agreed, it's crazy that there are engineers in this world that can make blanket statements like this, especially on a site like HN.

There are a lot of great languages/frameworks, and it depends on the needs you have and your team.

(I'm so fatigued by this view I hear so regularly expressed in web dev that "X is the solution to everything" - no, it's very rarely the case)

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

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 couldn't agree more, but I think you should add Clojure to the list. There's also advanced profiling tools available for the JVM platform.

For those who do use Rails the Torquebox environment is available http://torquebox.org/

TorqueBox 4's web server is powered by Undertow. Check out the performance benchmarks: http://www.techempower.com/benchmarks/#section=data-r9&hw=i7...

undertow edge 183,150 requests per second on the JSON benchmark

> 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.

The OP's one-size fits all approach is simply wrong.

Simply because it is correct for a subset of organizations does not make it true for all organizations as the OP implied.

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).

PS: My experience might not reflect other people.

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.

In your list of JVM languages, you skipped Clojure, which has the side-benefit of a strong community working on ClojureScript.

Some people will always go with lighter systems, see how big Go is getting. And then integrate the subsystems with RPC.

That said, Clojure + Java is a sweet combination, they are pretty complementary IMO.

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.

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.

Keep in mind Sails has stagnated and there's a fork called TrailJS now.

The NodeJS 3rd-party ecosystem is really really fragile at the moment.

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.

For anyone who's interested, the github repo: https://github.com/trailsjs/trails

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.

Gotcha, thought you meant something else. Thanks for clearing it up. Have you looked into koa[1]?

[1] https://github.com/koajs/koa

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)

Take a look at the Play Framework or Ninja Framework.

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.

Java is great but there are other high-performance options with great languages e.g. Haskell.

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.

[1] https://projects-old.apache.org/indexes/language.html#Java

[2] https://code.google.com/p/guava-libraries/

[3] https://github.com/GoogleCloudPlatform/DataflowJavaSDK

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.

Yes, the installed base of working, high-performance, money-making programs written Haskell is astounding compared to those part-time Java amateurs.

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.

Reply on news.ycombinator.com