Live data from Hacker News

Why we choose Java instead of a polyglot stack

product.hubspot.com

21–30 of 155 posts

Re: Why we choose Java instead of a polyglot stack

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

Re: Why we choose Java instead of a polyglot stack

#22
post #17

Earlier quoted context omitted.

I'd suggest taking a look at kotlin as well

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.

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.

Re: Why we choose Java instead of a polyglot stack

#23

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…

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

Re: Why we choose Java instead of a polyglot stack

#24
post #16

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…

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.

Re: Why we choose Java instead of a polyglot stack

#25

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…

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.

Re: Why we choose Java instead of a polyglot stack

#26

Earlier quoted context omitted.

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…

> Of course, compared to C#, it still benefits from a considerably larger and IMHO higher-quality ecosystem . . .

Maybe so, it's been over a decade since I've coded in Java back in the days of java servlets.

But what MS has done with C# is great. It's turned out to be an awesome language with lambda, linq, async features that's really hard to beat.

edit: Looks like java 8 has lambda now.

http://www.oracle.com/webfolder/technetwork/tutorials/obe/ja...

Re: Why we choose Java instead of a polyglot stack

#27

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…

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

Re: Why we choose Java instead of a polyglot stack

#28
post #19

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…

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 f…

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

Re: Why we choose Java instead of a polyglot stack

#29
post #16

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…

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

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

Post reply on HN