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.
> 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.
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.
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.
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.
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
> 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.
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.
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).
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.
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...
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?
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.
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.
[+] [-] meddlepal|10 years ago|reply
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.
[+] [-] nv-vn|10 years ago|reply
[+] [-] hackercomplex|10 years ago|reply
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
[+] [-] fweespeech|10 years ago|reply
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.
[+] [-] SiVal|10 years ago|reply
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.
[+] [-] champion|10 years ago|reply
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.
[+] [-] Consultant32452|10 years ago|reply
[+] [-] preordained|10 years ago|reply
[+] [-] tetraodonpuffer|10 years ago|reply
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.
[+] [-] Eridrus|10 years ago|reply
[+] [-] wcummings|10 years ago|reply
[+] [-] brianpgordon|10 years ago|reply
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.
[+] [-] edem|10 years ago|reply
> 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
[+] [-] zmmmmm|10 years ago|reply
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.
[+] [-] hibikir|10 years ago|reply
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.
It's a very unfortunate problem.
[+] [-] burntcookie90|10 years ago|reply
[+] [-] zeveb|10 years ago|reply
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.
[1] http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
[+] [-] mschuster91|10 years ago|reply
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.
[+] [-] jcrites|10 years ago|reply
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.
[+] [-] edwinnathaniel|10 years ago|reply
I also don't see tutorials or books that create too many layers for a while (especially post EJB2/EJB3.0 days).
[+] [-] peterashford|10 years ago|reply
[+] [-] nemik|10 years ago|reply
[+] [-] exabrial|10 years ago|reply
[+] [-] hackercomplex|10 years ago|reply
[+] [-] g_josifov|10 years ago|reply
[+] [-] davidw|10 years ago|reply
[+] [-] glorge|10 years ago|reply
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.
[+] [-] edem|10 years ago|reply
[+] [-] champion|10 years ago|reply
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.
[+] [-] g_josifov|10 years ago|reply
Very elegant introduction to Java Land, it uses Java EE 7 and by default two servers Payara or Wildfly(around 100MB).
[+] [-] Yhippa|10 years ago|reply
[+] [-] Edmond|10 years ago|reply
[+] [-] throwaway437812|10 years ago|reply
[+] [-] Freak_NL|10 years ago|reply
[+] [-] zmmmmm|10 years ago|reply
[+] [-] vorg|10 years ago|reply
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.
[+] [-] lmm|10 years ago|reply
[+] [-] vbezhenar|10 years ago|reply
Another option is Scala, but Kotlin is superior for most projects IMO.
[+] [-] Consultant32452|10 years ago|reply
[+] [-] Mikeb85|10 years ago|reply
I can certainly imagine a future where Java is the top performing language for any application.
[+] [-] jkot|10 years ago|reply
Kotlin is best of both worlds, highly expressive, good compatibility and pretty simple.
[+] [-] michaelvkpdx|10 years ago|reply
I'm still writing Java to make money to buy music. Just like the 90's.
[+] [-] vfc1|10 years ago|reply
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.
[+] [-] edwinnathaniel|10 years ago|reply
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.
[+] [-] stevehiehn|10 years ago|reply
[+] [-] melted|10 years ago|reply
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.
[+] [-] ajainy|10 years ago|reply
-=-= 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.
[+] [-] mobiuscog|10 years ago|reply
Java / JVM is the right tool for some jobs, and not the right tool for many others.
It's definitely not an essential for core services and web applications, but is a valid option.
[+] [-] DigitalJack|10 years ago|reply
[+] [-] x3n0ph3n3|10 years ago|reply