31 ms·

Why we choose Java instead of a polyglot stack

175 points by wsorenson 11y ago

champion 11y ago
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.
- preordained 11y ago
  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.
  - k__ 11y ago
    Interesting. 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.
    - namelezz 11y ago
      What is "co."?
      - k__ 11y ago
        as in "...and company"
        namelezz 11y ago
        Thanks. I thought you were talking about an old dead tech(co. as abbreviation of Cobol)
  - mercurial 11y ago
    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.
    - buckbova 11y ago
      > 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/java/Lambda-QuickStart/index.html http://www.oracle.com/webfolder/technetwork/tutorials/obe/ja...
      - eropple 11y ago
        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.
- wcummings 11y ago
  HubSpot doesn't have language wars, only IDE wars ;)
  - i2shar 11y ago
    And hopefully IntelliJ wins hands down :)
- Eridrus 11y ago
  The blog post mentioned "modern java frameworks", can you specify which ones you're using?
  - champion 11y ago
    The post mentions a few: Dropwizard for RESTful APIs (http://www.dropwizard.io 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.
    - scopendo 11y ago
      Does that mean that you use JDBI for DB access?
      - bbeaudreault 11y ago
        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 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.
  - rpgmaker 11y ago
    Is there a guide to modern java frameworks and their use? I left java a while back when "EE" was full of shit.
    - champion 11y ago
      This is a good place to start: https://github.com/cxxr/better-java https://github.com/cxxr/better-java
      - karmapolice 11y ago
        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.
- tetraodonpuffer 11y ago
  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.
- Consultant32452 11y ago
  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.
nemik 11y ago
I also advocate for Java, but mostly because I invested in companies that manufacture RAM.
- hackercomplex 11y ago
  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.
  - eropple 11y ago
    > 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.
    - hackercomplex 11y ago
      exorbitant! quite right 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.
      - eropple 11y ago
        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.
meddlepal 11y ago
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.
- lmm 11y ago
  Java is great but there are other high-performance options with great languages e.g. Haskell.
  - deleted 11y ago
    [deleted]
  - bliti 11y ago
    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.
  - jcrites 11y ago
    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 https://projects-old.apache.org/indexes/language.html#Java [2] https://code.google.com/p/guava-libraries/ https://code.google.com/p/guava-libraries/ [3] https://github.com/GoogleCloudPlatform/DataflowJavaSDK https://github.com/GoogleCloudPlatform/DataflowJavaSDK
brianpgordon 11y ago
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.
- burntcookie90 11y ago
  I'd suggest taking a look at kotlin as well
  - lmm 11y ago
    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.
    - 11y ago
jkot 11y ago
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.
michaelvkpdx 11y ago
The dream of the 90's is alive and not just here in Portland! I'm still writing Java to make money to buy music. Just like the 90's.
mschuster91 11y ago
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.
- jcrites 11y ago
  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.
  - skybrian 11y ago
    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.
  - mschuster91 11y ago
    > 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).
- edwinnathaniel 11y ago
  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).
deleted 11y ago
[deleted]
throwaway437812 11y ago
Much of this makes sense, but the main thing that keeps me from using Java is the dark cloud hanging over it, called Oracle.
- Freak_NL 11y ago
  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?
  - throwaway437812 11y ago
    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.
    - mike_hearn 11y ago
      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.
    - keypusher 11y ago
      We have shipped high-traffic production web applications using OpenJDK for years.
vfc1 11y ago
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.
- edwinnathaniel 11y ago
  > 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.
  - deleted 11y ago
    [deleted]
x3n0ph3n3 11y ago
Another language fight full of hyperbolic claims. Fun.
zmmmmm 11y ago
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.
- vorg 11y ago
  > 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.
- lmm 11y ago
  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.
  - zmmmmm 11y ago
    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.
Mikeb85 11y ago
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.
vbezhenar 11y ago
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.
- Consultant32452 11y ago
  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.
davidw 11y ago
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.
- edem 11y ago
  There is [Grails](https://grails.org/ 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/ 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...
  - davidw 11y ago
    My question is pretty open-ended, so 'use XYZ in Clojure' works too.
  - vorg 11y ago
    > 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.
  - ccoggins 11y ago
    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.
zeveb 11y ago
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. [1] http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
stevehiehn 11y ago
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.
ajainy 11y ago
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.
DigitalJack 11y ago
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.
melted 11y ago
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.
mobiuscog 11y ago
Developers use the right tool for the job. 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.

175 points by wsorenson 11y ago

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.

preordained 11y ago
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.
- k__ 11y ago
  Interesting. 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.
  - namelezz 11y ago
    What is "co."?
    - k__ 11y ago
      as in "...and company"
      - namelezz 11y ago
        Thanks. I thought you were talking about an old dead tech(co. as abbreviation of Cobol)
- mercurial 11y ago
  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.
  - buckbova 11y ago
    > 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/java/Lambda-QuickStart/index.html http://www.oracle.com/webfolder/technetwork/tutorials/obe/ja...
    - eropple 11y ago
      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.
wcummings 11y ago
HubSpot doesn't have language wars, only IDE wars ;)
- i2shar 11y ago
  And hopefully IntelliJ wins hands down :)
Eridrus 11y ago
The blog post mentioned "modern java frameworks", can you specify which ones you're using?
- champion 11y ago
  The post mentions a few: Dropwizard for RESTful APIs (http://www.dropwizard.io 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.
  - scopendo 11y ago
    Does that mean that you use JDBI for DB access?
    - bbeaudreault 11y ago
      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 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.
- rpgmaker 11y ago
  Is there a guide to modern java frameworks and their use? I left java a while back when "EE" was full of shit.
  - champion 11y ago
    This is a good place to start: https://github.com/cxxr/better-java https://github.com/cxxr/better-java
    - karmapolice 11y ago
      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.
tetraodonpuffer 11y ago
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.
Consultant32452 11y ago
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.

nemik 11y ago

I also advocate for Java, but mostly because I invested in companies that manufacture RAM.

hackercomplex 11y ago
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.
- eropple 11y ago
  > 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.
  - hackercomplex 11y ago
    exorbitant! quite right 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.
    - eropple 11y ago
      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.

meddlepal 11y ago

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.

lmm 11y ago
Java is great but there are other high-performance options with great languages e.g. Haskell.
- deleted 11y ago
  [deleted]
- bliti 11y ago
  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.
- jcrites 11y ago
  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 https://projects-old.apache.org/indexes/language.html#Java [2] https://code.google.com/p/guava-libraries/ https://code.google.com/p/guava-libraries/ [3] https://github.com/GoogleCloudPlatform/DataflowJavaSDK https://github.com/GoogleCloudPlatform/DataflowJavaSDK

brianpgordon 11y ago

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.

burntcookie90 11y ago
I'd suggest taking a look at kotlin as well
- lmm 11y ago
  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.
  - 11y ago

jkot 11y ago

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.

michaelvkpdx 11y ago

The dream of the 90's is alive and not just here in Portland! I'm still writing Java to make money to buy music. Just like the 90's.

mschuster91 11y ago

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.

jcrites 11y ago
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.
- skybrian 11y ago
  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.
- mschuster91 11y ago
  > 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).
edwinnathaniel 11y ago
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).

deleted 11y ago

[deleted]

throwaway437812 11y ago

Much of this makes sense, but the main thing that keeps me from using Java is the dark cloud hanging over it, called Oracle.

Freak_NL 11y ago
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?
- throwaway437812 11y ago
  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.
  - mike_hearn 11y ago
    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.
  - keypusher 11y ago
    We have shipped high-traffic production web applications using OpenJDK for years.

vfc1 11y ago

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.

edwinnathaniel 11y ago
> 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.
- deleted 11y ago
  [deleted]

x3n0ph3n3 11y ago

Another language fight full of hyperbolic claims. Fun.

zmmmmm 11y ago

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.

vorg 11y ago
> 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.
lmm 11y ago
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.
- zmmmmm 11y ago
  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.

Mikeb85 11y ago

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.

vbezhenar 11y ago

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.

Consultant32452 11y ago
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.

davidw 11y ago

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.

edem 11y ago
There is [Grails](https://grails.org/ 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/ 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...
- davidw 11y ago
  My question is pretty open-ended, so 'use XYZ in Clojure' works too.
- vorg 11y ago
  > 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.
- ccoggins 11y ago
  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.

zeveb 11y ago

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. [1] http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

stevehiehn 11y ago

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.

ajainy 11y ago

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.

DigitalJack 11y ago

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.

melted 11y ago

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.

mobiuscog 11y ago

Developers use the right tool for the job. 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.