Kotlin is best of both worlds, highly expressive, good compatibility and pretty simple.
Why we choose Java instead of a polyglot stack
21–30 of 155 posts
Re: Why we choose Java instead of a polyglot stack
#22Earlier 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.
Re: Why we choose Java instead of a polyglot stack
#23If 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…
Re: Why we choose Java instead of a polyglot stack
#24If 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.
Re: Why we choose Java instead of a polyglot stack
#25If 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…
Re: Why we choose Java instead of a polyglot stack
#26Earlier 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…
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
#27If 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…
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
#28I 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…
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
#29If 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.
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
Re: Why we choose Java instead of a polyglot stack
#30I'm still writing Java to make money to buy music. Just like the 90's.