19 ms·

The funny thing is that from a purely technological point of view, Java (even the 5-year-old Java 8 and certainly recent versions) is far ahead of most other st

by pron 8y ago

The funny thing is that from a purely technological point of view, Java (even the 5-year-old Java 8 and certainly recent versions) is far ahead of most other stuff hyped on HN (as well as less hyped stuff). Virtually no other platform comes close to that combination of state-of-the-art optimizing compilers, state-of-the-art GCs, and low-overhead in-production profiling/monitoring/management. And much of the cutting-edge development and technological breakthroughs on these matters continues to take place in Java (disclosure: I work on OpenJDK full-time). Just in the past few years we've seen the release of open-source GCs with less than 2ms worst-case pause times on terabytes of heap (ZGC and Shenandoah), a revolution in optimizing compilers (Graal/Truffle), and there's an upcoming release to streaming access to low-overhead deep profiling (JFR). So Java is not only the safe choice for serious server-side software; it's also the bleeding edge.

sonnyblarney 8y ago
This - Java 8 'feels' legacy, but in so many ways it's miles ahead of upstarts. Sometimes we forget that the JVM (almost) = Java and that thing is a beast.
crimsonalucard 8y ago
True, but java carries a lot of legacy.
- Bombthecat 8y ago
  So do the framework within Java.
- crimsonalucard 8y ago
  Wow I'm getting voted down. I guess I should reverse what I said because it's obviously not true at all. Java carries zero legacy.
  - gerbilly 8y ago
    No, you don't need to reverse your opinion at all. Personally, I voted you down because your opinion was stated in a sort of offhanded manner that does not do the subject justice.
    - crimsonalucard 8y ago
      The manner is neutral. It's only a couple words. You want me to write a whole essay on the pros and cons of legacy? In that case I would invite a negative vote because in those cases you can disagree. In this case it's just a statement that is true.
      - gerbilly 8y ago
        Legacy is a poorly defined term anyway. Is COBOL legacy, how about jQuery? ... It's mostly a derisive term that seems to mean: "Old technology I don't like."
- BenoitP 8y ago
  Java, or projects in Java? Java pretty much has to, in order to preserve the most important feature a runtime can have: backwards compatibility. Projects in Java are cursed from the beginning: the language has great constructs for boxing complexity (modifiers, inheritance, interfaces, generics, design patterns allowed by performant virtual calls, etc.). This means that when projects in other languages become unmanageable, Java will keep chugging business requirements like no other. Accumulating complexity is the fate of every successful system; and Java makes you go a long way. Now, a newly arrived person on the job market will face systems with a pile of convoluted business logic a few century.human's high. The first ticket will be: 0.5 month of getting accustomed to the language/framework, 1 month of archeology, producing 50 lines of code, 150 of tests, break a few tests, 0.5 month of corrections; For something that would take one day as a greenfield project. The job might pay well, but will be very lowly gratifying. Now the sound enterprise strategy is to keep using Java: the platform allows for deeper and finer integration into the business processes. But the sound individual strategy for newcomers is to stay the hell away from it. Oh, you will only work with Rust/Go/Elixir/etc? Here, have a greenfield project. Clojure/Scala/Kotlin/Ceylon/Frege/Groovy might be the best of both worlds.
  - sbov 8y ago
    It sounds like you're basically saying its difficult and slow to work on large projects, and the solution is to not work on large projects. And that new languages implicitly mean smaller and thus easier projects because they haven't had time to grow. The weird thing I always get with the always greenfield developers is how you know you aren't just creating even larger messes tomorrow vs the messes you're avoiding today. I guess it isn't your problem though if you're always working greenfield - it's someone else's.
- jjoonathan 8y ago
  "Legacy" includes good things too, not just bad things. I grew up promising myself that I'd never touch Java, but when I did, it was a relevation. Everything just works. The debugger was just "attach and go" -- no recompilation with different flags, no fishing for the IDE / plugin version in which it wasn't broken, no glaring missing features (conditional breakpoints, stack traces...) The frameworks were refreshingly complete; I always felt that extensibility mechanisms were available so that I didn't have to gamble that my requirements fell into the "just works" subset rather than the "just doesn't" subset. I never had to wonder if integrating with some bog-standard protocol would mean maintaining my own open source project; maven always had something workable available. Java wasn't born like this, but the legacy it accumulated made it formidable. Early-adopting a hip language nets you a few sexy wins at the cost of completely eliminating a gigantic Brontosaurus-size long tail of important functionality and ecosystem maturity.
  - crimsonalucard 8y ago
    You're right. I never said otherwise.
- gerbilly 8y ago
  Yeah, there is the legacy of the thousands of mature libraries, frameworks and development tools. Legacy isn't always a bad thing.
  - crimsonalucard 8y ago
    never said it was bad. But just wanted to state that it's not all newness.
    - gerbilly 8y ago
      To me Java is like a diesel engine, old but proven technology that can keep on chugging for hundreds of thousands of hours. (Not to discount the recent improvements in GC, etc which are also amazing...)
  - tomohawk 8y ago
    Having moved to a stack with a much more competent standard library, it's much nicer to have that great standard library than to have to wade through a rich set of libraries all the time to achieve the same thing. I'm talking about Go, of course. It's just nice getting right to work coding up an http server without having to think about what "web framework" I should need to select, or which logging library to use.
    - kgc 8y ago
      What stack?
- sebazzz 8y ago
  Once you write code, it is legacy.
babaganoosh89 8y ago
For such an advanced JVM, having to prewarm it by calling code 5000x times or the JVM being much more memory hungry than other non-JVM languages doesn't feel like the cutting edge.
- knowsmorsecode 8y ago
  What?
  - stingraycharles 8y ago
    I suspect that the parent is talking about the JVM's JIT, where it compiles java bytecode into machine instructions after loading the application. This is why the first few requests on a JVM are usually considerably slower than the rest. Parent is obviously exaggerating with the 5000x, and he could have made his point in a different way, but there's some truth to it.
    - shawnz 8y ago
      At the same time, JIT can outperform native code in some specific circumstances, since there are certain optimizations which can be proven safe at runtime which can not be guaranteed to be safe at compile time
      - xxs 8y ago
        Actually one of the less known features of the JIT is the ability to deoptimize/recompile based on CHA (class hierarchy analysis) or pushed compilation request via invokeDynamic&friends.
      - gameswithgo 8y ago
        this is a thing people say a lot but it is not something that seems to often result in an actual java program or benchmark being faster than program compiled AOT by an equivalently smart compiler (llvm etc)
    - wolf550e 8y ago
duxup 8y ago
>stuff hyped on HN HN is going to be inclined to take a look at new-ish stuff.
- TeMPOraL 8y ago
  Indeed. For better or worse, that's what the "N" in "HN" stands for - "News".
mfatica 8y ago
How does this compare to the .NET ecosystem?
- dRaBoQ 8y ago
  Why downvote ? C#/Visual Studio is one of the best languages out there.
- paulmd 8y ago
  C# is a better language. Java 8 started to catch up with some of the quality-of-live niceties, but Java has a lot of mistakes baked into the language and interfaces that can't be removed without potentially breaking a lot of stuff, which the consortium is not willing to do. C# and DotNet were designed with the wisdom gained from the early days of Java implementation and sidestepped a lot of these messes. Java has a substantially better ecosystem. The tooling is just miles ahead of what exists in the DotNet world. Until very recently you developed in Visual Studio and you ran on Windows in production and that was that. They're working on Linux support and a broader ecosystem but they are probably a decade behind what is available on Java. Even stuff like package management is crude, NuGet is a joke compared to Gradle.
  - GordonS 8y ago
    Packet is a great alternative to the NuGet client. Tooling might be slightly behind Java's, but honestly, there's not much in it. Dotnet Core might only have been available on Linux for a few years, but Mono was around for many before that. The dotnet CLI also recently got the concept of 'global tools', which are akin to NPMs. A lot of work is also underway on better cross-platform performance analysis, crash dump handling and the like for runtime in production[0] Is there anything in particular you miss? [0] https://devblogs.microsoft.com/dotnet/introducing-diagnostics-improvements-in-net-core-3-0/ https://devblogs.microsoft.com/dotnet/introducing-diagnostic...
    - WorldMaker 8y ago
      According to the roadmap, Mono's JVM interop used for Xamarin Android will be making its way more directly into .NET Core and will light up on almost every platform, which would give .NET greater, direct access to the Java ecosystem as well.
peterkelly 8y ago
Despite its title, the article was not about Java 8.
- outworlder 8y ago
  You can try appending "in Go" or "in Tensorflow" to see if the title still makes sense.
  - the_af 8y ago
    The author was trying to be polite and avoid sensitive issues, but one prefix that also almost always works in HN titles is "In China". You can have it all: "In China, IT runs on Java 8 in Tensorflow" The perfect HN title! :)
dRaBoQ 8y ago
C# ?
ksec 8y ago
This. Technically there is nothing I don't like about JVM right now, everything that seems impossible 15 years ago is now solved. AOT used to be bag of hurt with GCJ ( I know I could use Excelsior, not sure if it was free in my time though ), but now even that will be an supported option from Graal. Java the languages still isn't pretty, but it has been much improved. OpenJDK is GPL and apart form the trademark ( ? ) with Java ( I didn't read much into the JakartaEE problem, ) everything should be fine. I am just a little uneasy with Oracle lurking around, I just don't know what they are going to do next.
- pron 8y ago
  > I am just a little uneasy with Oracle lurking around, I just don't know what they are going to do next. What do you mean by "lurking"? Oracle is the company developing OpenJDK, and it will continue to do so. All our projects are done in the open, with lots of communication.
  - jptoto 8y ago
    The licensing has gotten super onerous.
    - sanxiyn 8y ago
      What licensing? OpenJDK is licensed under GPLv2 plus Classpath exception, the same as ever.
    - pron 8y ago
      The licensing has gotten far better. First, Oracle has just open sourced the entire JDK for the first time ever, and second, instead of offering a mixed free/paid, open/proprietary JDK (with -XX:+UnlockCommercialFeatures flags), it now offers the JDK under either a completely free and open license (under the name OpenJDK) or a commercial license for Oracle support subscription customers (under the name Oracle JDK).
      - ksec 8y ago
dlandis 8y ago
> So Java is not only the safe choice for serious server-side software; it's also the bleeding edge. Sure for core Java (OpenJDK), but what the future of JEE licensing and development? Even non-"enterprise" apps typically make use of some JEE stuff like servlets and JDBC. Is it really the "safe" choice when, apparently, the trademark agreements have just fallen apart? https://headcrashing.wordpress.com/2019/05/03/negotiations-failed-how-oracle-killed-java-ee/ https://headcrashing.wordpress.com/2019/05/03/negotiations-f...
- ses1984 8y ago
  Pardon my ignorance but what does any of that trademark stuff have to do with jdbc?
- lenkite 8y ago
  JDBC is not JEE - it is core Java. Servlets are the original web-container Java spec, independent of JEE. Both are great specs supported by several stable and performant implementations - rock solid tech compared to a lot of the flaky stuff you find advertised today.
  - 0db532a0 8y ago
    How are Java programmers implementing RESTFUL APIs these days?
    - atoko 8y ago
      Spring Boot with Webflux and any rx supporting libraries you can get your hands on
      - 0db532a0 8y ago
        Thanks.
    - lenkite 8y ago
      Many developers don't want to think too much and generally choose Spring boot for a stable, highly-popular and well-documented framework. There is nothing wrong with this choice but I find it too bloated for lean container based micro-services. Dropwizard and Micronaut are pretty good for getting a smaller and saner footprint. If you need more than REST, say you want a lean MVC-based web-framework, then Blade is also a good choice. You can also choose not to use a framework and say use code-generation from a swagger/openAPI REST document and implement the remaining bits on your own. If your deployment target is AWS, you can also choose to leverage Netflix's fantastic set of libraries. Java has tonnes of options, so you usually need to spend some time evaluating what goes into your stack.
chvid 8y ago
Yes! Java 8 is good. And Excel is by far the best spreadsheet out there. I don't know enough about Sharepoint but it seems like the normal world has actually chosen very well when it comes to technology.
SebastianM 8y ago
> low-overhead in-production profiling/monitoring/management This is a joke, right? The management overhead for the JVM in production environments is huge. It's really hard to get it right.
- StreamBright 8y ago
  Not sure what you are talking about. Can you give me some examples?
  - alfalfasprout 8y ago
    Tuning the heap size, GC tuning, etc. are often needed to avoid huge GC spikes out of the box. Not to mention performance is pretty meh compared to something like Go for applications where non-trivial compute is needed.
    - StreamBright 8y ago
      GC tuning should be trivial for every Java shop. Yeah I guess you can find use cases where Go is faster than Java but in that case if this matters I would go for Rust be because I like it more than Go.
papaf 8y ago
The funny thing is that from a purely technological point of view, Java (even the 5-year-old Java 8 and certainly recent versions) is far ahead of most other stuff hyped on HN (as well as less hyped stuff). The technology is certainly impressive but it isn't equipped to deal with the modern world. It is trivial to run 10 Node.js applications in the memory of one JVM application. This never used to be a problem, but now the cloud is forcing apps to pay for the resources they use its a kiss of death. There is also the move to serverless and the slow start of the JVM which makes it literally the worst choice out of all the alternatives. Oh, and lets not even start on the train wreck of Oracle's stewardship -- Java 11 is competing with Java 8. Java will survive but I cannot see it having any place in a modern software stack.
- sanxiyn 8y ago
  What's wrong with Oracle's stewardship? I am not a fan of Oracle, far from it, but Oracle's stewardship of Java has been exemplary.
  - papaf 8y ago
    Currently: - The licence changes causing a premature move to Java 11 or OpenJDK out of fear of an audit. Today a colleague was investigating a Segmentation fault in the JVM because we moved to the OpenJDK. This is not productive work. - The future of j2ee is uncertain: https://headcrashing.wordpress.com/2019/05/03/negotiations-failed-how-oracle-killed-java-ee/ https://headcrashing.wordpress.com/2019/05/03/negotiations-f... How did you get to "exemplary"? Have you got any examples?
- deleted 8y ago
  [deleted]
- haglin 8y ago
  I haven't tried serverless, but shouldn't that be Java's cup of tea? The JVM can load code dynamically and adapt the runtime to the work load. Maybe there is a framework missing, so those that provide serverless starts a new JVM per function call, but they shouldn't really have to do that.
gameswithgo 8y ago
.NET Core is winning a lot of benchmark comparisons now. And one might consider Rust to be more bleeding edge.
- pron 8y ago
  Java and Rust are both bleeding edge in their respective domains, which are quite disjoint. I like them both, and Rust may well dominate its domain one day as much as Java dominate its own (although Rust's domain is even slower-moving than Java's, so that process may well take decades). I don't know of .NET Core winning any quality industry benchmarks that people actually pay attention to, let alone a lot of them.
  - gameswithgo 8y ago
    TechEmpower BenchmarkGame And SIMD is coming soon in .NET Core 3 which should be a big jump for many workloads.
tomohawk 8y ago
It takes a lot of power to push something that large. A lot of brain power to grock the ecosystem. Outside of the Java bubble, the view is quite a bit different. All that sophistication looks like a wasted effort. Take something as simple as admining the garbage collector. Java has a big selection of GCs, and each has their bunch of knobs for tuning. And you have to pay attention to that stuff. After working with Go for several years, at large scale, we never once had to touch any knobs for GC. We could focus on better things. Any of the Java stuff we deploy and deal with we have this extra worry and maintenance issue. And that's just the GC.
- gerbilly 8y ago
  > Java has a big selection of GCs, and each has their bunch of knobs for tuning. And you have to pay attention to that stuff. You never have to touch them in the Java world either, unless you like making performance worse that is. I've never ever seen a case where fiddling with garbage collection parameters didn't make things slower. I worked with a guy who worked on a popular java compiler, and he says the same thing. he never twiddles GC parameters either.
  - nemothekid 8y ago
    Cassandra has benefitted from so many GC tweaks that I find this view hard to believe. i can only imagine someone having this view if they have never cared about latency. How have you never experienced a multi-second GC pause on default CMS settings?
  - tomohawk 8y ago
    What sort of scale are you working at? At our scale, it is normal to look into these sorts of things. Reading and understanding and applying articles like the following is absolutely necessary. http://clojure-goes-fast.com/blog/shenandoah-in-production/ http://clojure-goes-fast.com/blog/shenandoah-in-production/
    - gerbilly 8y ago
      Medium scale. It's not like I need to pimp each of my servers like it's a Honda Civic. If the load gets too high, I just add another instance. It's way more economical than wasting developer time fiddling with GC params.
tus87 8y ago
Poor start-up time, terrible application bloat, uninspiring language with poor concurrency support, massive RAM requirements, everything XML, complex tuning required, what a nightmare. No wonder the world is running towards Python and serverless as fast as they can...
- icedchai 8y ago
  Then they discover that even though Python is quicker to develop with, it actually runs much slower and has poor threading support. Since async only gets you so far, you try multiprocessing. It turns out running all those Python worker processes actually takes up more memory and CPU than the equivalent Java app... Also, most of the things you complain about are not Java: they are the fault of JEE (aka J2EE) and "app servers."
- chimpburger 8y ago
  CPython is 100 times slower and has no multi threading support (CPython is single threaded). JVM code can outperform native C code. The JVM supports many advanced languages (Scala, Clojure, Kotlin) and it can even run Python code (Jython) faster than CPython. For concurrency it has this ultra powerful library https://akka.io https://akka.io (Up to 50 million msg/sec on a single machine. Small memory footprint; ~2.5 million actors per GB of heap.)
  - ptx 8y ago
    Jython seems to be much, much slower than CPython, actually: https://pybenchmarks.org/u64q/jython.php https://pybenchmarks.org/u64q/jython.php The only benchmark where it's faster is the one involving threads, which makes sense. CPython definitely has multi-threading support, but it also has the Global Interpreter Lock preventing threads from actually executing bytecode at the same time. Jython doesn't. People have written patches that successfully remove that GIL, but those patches make single-threaded performance worse and thus haven't been accepted.
    - chimpburger 8y ago
      I consider that as basically no multithreading support. CPython multithreading is useless in comparison. Those benchmarks indicate that the Jython compiler is far from optimal. The equivalent code rewritten in Java would be an order of magnitude faster. https://julialang.org/benchmarks/ https://julialang.org/benchmarks/ (note the single Python outlier there is the result of calling a C library for matrix calculation). Anyway, the JVM and CPython are fundamentally not comparable. One is interpreting, and the other is a JIT compiler. There are Python JIT compilers that would make a better comparison. However, as a language, Python is not optimal for large codebases. Comparing the languages only (not their implementation), Python is good for small scripting tasks, Java is better for very large scale projects.
negamax 8y ago
Isn't Minecraft written in Java. Many Fortune XX have their entire product lines written in it. Frankly, I don't understand the hate it gets on HN.
- discreteevent 8y ago
  Most of AWS, a lot of Google - as far as I know.
- gameswithgo 8y ago
  yes, and I had to pay for a lot of ram on servers because of it ;( The creator of notch chose java because when he started minecraft he thought that would let it run in web browsers. He wouldn't choose java if he could do it over again.
  - negamax 8y ago
    Do you have the link to back up the statement about running in browsers? Notch is super talented. MC was released in 2009. No way, he didn't know about browsers and Java
  - pron 8y ago
    Paying for RAM on servers is one of the cheapest ways you can pay for performance.
- imtringued 8y ago
  It is also one of the poorest performing games in the history of video games.
vijucat 8y ago
Great points, but it's actually much simpler than that: if you want static types, you have already eliminated the majority of HN darlings (JS, Python, and Ruby). Where do you? Most developers turn to C++, Java, or C# (not Haskell or F#, for example), and of these, Java and C# are both great for productivity and not daunting for someone just starting out, unlike C++. There was a period after 200x where developers managed to throw out a bunch of babies along with the bathwater when they rejected Java, UML, SQL, and everything else that was used in 199x. After all, these are all literally from the last century, so they must be "uncool", amirite? /s The preference for dynamic or duck typing in the name of productivity has always rubbed me the wrong way. To keep it brief, my defense / elevator pitch for static typing is: "Slow is smooth. Smooth is fast" :-)
- mevile 8y ago
  While I still like Python, Python and Ruby haven't been darlings of anything in probably the last 10 years. Go, Rust, Swift, and Kotlin are newer statically typed languages that lots of devs on here like though.
  - archgoon 8y ago
    Python's relevance got renewed by the ML frameworks (Tensorflow) and notebooks (Jupyter).
    - new4thaccount 8y ago
      This. Jupyter notebooks, Matplotlib, Numpy, Spyder...all that made Python big again as ML and AI became the new hotness recently and the killer app for Python. Outside AI, Python is a really good scripting language for both Linux and Windows. My entire industry seems to run off of Python for process automation and analysis. It really is a lingua franca in this space.
      - lytefm 8y ago
        I agree. During my Maths + CS studies I've been using mainly MatLab and R, Andrew Ng's famous Machine Learning intro was also taught in MatLab/ Octave. But using just one „proper” general purposing language like Python instead makes way more sense, especially when building software from scratch. Need a custom ERP? Build one with django. A Web Server? Go with flask. Integrating some ML pipelines? Easy.
sl1ck731 8y ago
I was never super into Java development. I started working in 2014 and was introduced to Weblogic, Jenkins, huge Maven POMs and all the rest, then went into Cloud consulting. When I sit down to do anything I get so wrapped up in all the stuff that comes along with Java and feel like I have to use some huge IDE like Eclipse (I hate) or IntelliJ (I <3 U Jetbrains) to do anything "real". If I could just write code and have a simple package manager like NPM or even Go packages and not be hindered by trying to get VScode to work I would never look back. I just waste so much time trying to understand the ecosystem. I know that isn't a great excuse (not wanting to take the time to become an expert on tooling), but people who came into the professional space in the same time frame likely also just see it as an obvious path to just avoid all the cruft. What I really want is to get a "lite" Java project like this up and running with all of the smart people's opinions in place that I can develop entirely in a lite editor (preferably without XML anywhere). Maybe something like Spring Boot would solve that but I have not investigated that yet.
- bgorman 8y ago
  The answer you are looking for is called "Clojure".
- pdpi 8y ago
  Java-the-language is a fairly crummy thing to work with, it’s Java-the-ecosystem that’s genuinely good — the JVM, the tooling, etc etc. The quality of IDEs available is definitely a very large component of that. Doing Java on a lightweight editor seems like a way to pay the price without reaping the benefits.
  - js2 8y ago
    I use TextMate (!) to maintain an Android SDK that's a mix of Java, C and C++ avoiding Android Studio like the plague, to maintain an iOS SDK that's mostly Objective-C, similarly avoiding Xcode's editor, and to maintain the backend written in Python that these SDK's talk to. I've got enough going on in my head w/o having to deal with the complexity of two different IDEs. Anyway, for me Java-the-language is fine. The tooling, at least as it comes with Android (looking at you gradle and all its Android plugins) is what makes me want to pull my hair out.
matthewmacleod 8y ago
I had cause to use a bit of Java recently, so I could wrap an existing library that did exactly the thing I wanted. I haven't used it since university—back in the 1.4 days—and I was actually pleasantly surprised. Performance was great, concurrency was easy, features like type inference and streams made the experience much more pleasant, and obviously the development tools are still first-rate. The absence of a package manager like Bundler or Cargo was frustrating for someone coming from that environment – as was the effective requirement to use an IDE. But on the whole, the platform feels like something that totally-hip-and-edgy-clique developers like myself are too quick to discount.
- syjer 8y ago
  >The absence of a package manager like Bundler or Cargo was frustrating why you did not use maven or gradle?
overgard 8y ago
I used to be a Java hater (I'm much more neutral now -- I even find aspects of it pretty pleasant). To me, it was never about the technology of Java (always been pretty impressive), or even the language (a little verbose -- but so is C++ and C# and I like both of those), it was really just about the ecosystem. For whatever reason 2000s era java had soo many libraries that were just insanely over-engineered and had these absurdly deep object taxonomies and trying to figure out how to do something came down to figuring out how 5 or 6 different classes interrelated. It was such a nightmare, especially since the IDEs back then weren't as smart as they are right now. I think it's become a lot better now though, modern libraries seem to have learned a lot of those lessons, and having proper closures makes a huge difference, and things like IntelliJ are really great about making dealing with the verbosity much easier.
- jacques_chester 8y ago
  A lot of the improvements in the ecosystem came from improvements in the language. Go4 patterns are in part shaped by language.
- deleted 8y ago
  [deleted]
arcticbull 8y ago
Respectfully I'm not sure that's true. > State-of-the-art optimizing compilers. LLVM provides coverage for many of the new languages that are hyped these days (with the notable and truly unfortunate exception of Go). LLDB provides an excellent debugger infrastructure. > State-of-the-art GCs. True, there's some good work there but I'm excited about languages that don't need GCs at all, so that we can finally stop tricking the memory wizard into complying with our workloads and focus on determinism, power efficiency and memory efficiency. > Low-overhead in-production profiling/monitoring/management. Correct me if I'm wrong but a lot of that is available in dtrace is it not? This is actually why I'm so excited by LLVM. I think it's the biggest advancement in computer science in ages and ages. It allows compiler engineers to focus on bringing what they do better and differently to the stack. It allows them to leverage the years of work and bundles of PHDs worth of research that went into the rest. All that time Go wasted developing assemblers for platforms should have been spent focusing on Go and letting LLVM handle it. Over time the delta between what Java has and what LLVM has will shrink which in turn narrows the gap between Java and every other LLVM based language. Think about it, macOS is basically just various front-ends for LLVM. Apple's implementations of OpenCL and OpenGL, the Metal Shading Language and Core Image are all wrappers for LLVM. Swift is a wrapper for LLVM. Clang makes C and C++ fancy wrappers for LLVM. Rust is a wrapper for LLVM. Almost everything your mac does is a fancy front-end for LLVM. Even Safari was (until B3 backend) a fancy front end for LLVM.
- pron 8y ago
  As I said in another comment, there can be more than one thing that's cutting edge, especially as the JVM and LLVM operate at completely different levels. Never mind GCs -- LLVM isn't even safe, and neither is WASM; and that's good at that low level. In fact, LLVM is employed by Falcon, the Zing JVM's JIT, and OpenJDK's HotSpot is compiled to LLVM on Mac. > I'm excited about languages that don't need GCs at all, so that we can finally stop tricking the memory wizard into complying with our workloads and focus on determinism, power efficiency and memory efficiency. That's fine, but it seems like giving up GCs comes with its own non-negligible costs, so much so that the two hardly compete in the same domains. > Correct me if I'm wrong but a lot of that is available in dtrace is it not? They have similarities (closer analogs would be https://github.com/btraceio/btrace https://github.com/btraceio/btrace and http://byteman.jboss.org/ http://byteman.jboss.org/ than JFR), yes, but operate at different levels with somewhat different capabilities. > This is actually why I'm so excited by LLVM. I think it's the biggest advancement in computer science in ages and ages. LLVM is popular, extremely useful, and quite cutting edge in its domain, but there isn't much of a "computer science" advancement as there is, e.g., in Graal/Truffle. > It allows them to leverage the years of work and bundles of PHDs worth of research that went into the rest. It certainly does, but there's a lot that LLVM doesn't give language designers that a JVM does, like GCs and high-level language interop. > Over time the delta between what Java has and what LLVM has will shrink which in turn narrows the gap between Java and every other LLVM based language. I don't know if LLVM wants to operate at Java's level or vice versa. While LLVM may offer some basic GC and Java may offer "safe" LLVM with things like Sulong, I believe their main focus will be their own respective levels.
keypusher 8y ago
I think everything you mention here is actually related to the JVM and not Java specifically, and while I agree the work is impressive, it’s also true that languages such as Kotlin and Scala benefit from that work while also offering some very nice modern improvements.
sidlls 8y ago
Java itself is fine. It's very popular--and that's the biggest problem. Not the language as such but the developer ecosystem around it. I am dead tired of seeing 80-character camel-case function and variable names, annotations that hide critical functionality of the code, stack traces dozens or hundreds of lines long because of the amount of indirection and poorly conceived configuration "languages" used to support dependency injection so developers can save a few characters of typing or mask dependencies and complexity, etc. The language may be fine, but it has been appropriated into the worst sort of terrible programming paradigms one might imagine.
- datavirtue 8y ago
  "80-character camel-case function and variable names" Isn't that a good thing? Tell all of us developers who write clear, clean code why you think that is bad? I don't ever get to 80 characters but I do write methods names that describe exactly what they do. If I can write it comfortably then I know I tried to do too much in the body.
- Cacti 8y ago
  We aren’t talking about Java the language. We are talking about the JVM.
- ptx 8y ago
  The terrible programming paradigms are workarounds for the terrible language. I read an old blog post about Spring's @Required annotation versus plain constructor injection and typed out a small example to get a feel for it – a simple class with one required and one optional dependency – which resulted in 23 lines of plain Java with constructor injection, or 16 lines of Java with Spring @Autowired magic, or 7 lines of Kotlin – no magic needed.
alkonaut 8y ago
You are describing the Jvm there, mostly. The jvm is great, and java is pretty tired even in the latest incarnations. I would have nothing against working full time with a jvm stack. So long as java isn’t involved.

by pron 8y ago

sonnyblarney 8y ago

This - Java 8 'feels' legacy, but in so many ways it's miles ahead of upstarts. Sometimes we forget that the JVM (almost) = Java and that thing is a beast.

crimsonalucard 8y ago

True, but java carries a lot of legacy.

Bombthecat 8y ago
So do the framework within Java.
crimsonalucard 8y ago
Wow I'm getting voted down. I guess I should reverse what I said because it's obviously not true at all. Java carries zero legacy.
- gerbilly 8y ago
  No, you don't need to reverse your opinion at all. Personally, I voted you down because your opinion was stated in a sort of offhanded manner that does not do the subject justice.
  - crimsonalucard 8y ago
    The manner is neutral. It's only a couple words. You want me to write a whole essay on the pros and cons of legacy? In that case I would invite a negative vote because in those cases you can disagree. In this case it's just a statement that is true.
    - gerbilly 8y ago
      Legacy is a poorly defined term anyway. Is COBOL legacy, how about jQuery? ... It's mostly a derisive term that seems to mean: "Old technology I don't like."
BenoitP 8y ago
Java, or projects in Java? Java pretty much has to, in order to preserve the most important feature a runtime can have: backwards compatibility. Projects in Java are cursed from the beginning: the language has great constructs for boxing complexity (modifiers, inheritance, interfaces, generics, design patterns allowed by performant virtual calls, etc.). This means that when projects in other languages become unmanageable, Java will keep chugging business requirements like no other. Accumulating complexity is the fate of every successful system; and Java makes you go a long way. Now, a newly arrived person on the job market will face systems with a pile of convoluted business logic a few century.human's high. The first ticket will be: 0.5 month of getting accustomed to the language/framework, 1 month of archeology, producing 50 lines of code, 150 of tests, break a few tests, 0.5 month of corrections; For something that would take one day as a greenfield project. The job might pay well, but will be very lowly gratifying. Now the sound enterprise strategy is to keep using Java: the platform allows for deeper and finer integration into the business processes. But the sound individual strategy for newcomers is to stay the hell away from it. Oh, you will only work with Rust/Go/Elixir/etc? Here, have a greenfield project. Clojure/Scala/Kotlin/Ceylon/Frege/Groovy might be the best of both worlds.
- sbov 8y ago
  It sounds like you're basically saying its difficult and slow to work on large projects, and the solution is to not work on large projects. And that new languages implicitly mean smaller and thus easier projects because they haven't had time to grow. The weird thing I always get with the always greenfield developers is how you know you aren't just creating even larger messes tomorrow vs the messes you're avoiding today. I guess it isn't your problem though if you're always working greenfield - it's someone else's.
jjoonathan 8y ago
"Legacy" includes good things too, not just bad things. I grew up promising myself that I'd never touch Java, but when I did, it was a relevation. Everything just works. The debugger was just "attach and go" -- no recompilation with different flags, no fishing for the IDE / plugin version in which it wasn't broken, no glaring missing features (conditional breakpoints, stack traces...) The frameworks were refreshingly complete; I always felt that extensibility mechanisms were available so that I didn't have to gamble that my requirements fell into the "just works" subset rather than the "just doesn't" subset. I never had to wonder if integrating with some bog-standard protocol would mean maintaining my own open source project; maven always had something workable available. Java wasn't born like this, but the legacy it accumulated made it formidable. Early-adopting a hip language nets you a few sexy wins at the cost of completely eliminating a gigantic Brontosaurus-size long tail of important functionality and ecosystem maturity.
- crimsonalucard 8y ago
  You're right. I never said otherwise.
gerbilly 8y ago
Yeah, there is the legacy of the thousands of mature libraries, frameworks and development tools. Legacy isn't always a bad thing.
- crimsonalucard 8y ago
  never said it was bad. But just wanted to state that it's not all newness.
  - gerbilly 8y ago
    To me Java is like a diesel engine, old but proven technology that can keep on chugging for hundreds of thousands of hours. (Not to discount the recent improvements in GC, etc which are also amazing...)
- tomohawk 8y ago
  Having moved to a stack with a much more competent standard library, it's much nicer to have that great standard library than to have to wade through a rich set of libraries all the time to achieve the same thing. I'm talking about Go, of course. It's just nice getting right to work coding up an http server without having to think about what "web framework" I should need to select, or which logging library to use.
  - kgc 8y ago
    What stack?
sebazzz 8y ago
Once you write code, it is legacy.

babaganoosh89 8y ago

For such an advanced JVM, having to prewarm it by calling code 5000x times or the JVM being much more memory hungry than other non-JVM languages doesn't feel like the cutting edge.

knowsmorsecode 8y ago
What?
- stingraycharles 8y ago
  I suspect that the parent is talking about the JVM's JIT, where it compiles java bytecode into machine instructions after loading the application. This is why the first few requests on a JVM are usually considerably slower than the rest. Parent is obviously exaggerating with the 5000x, and he could have made his point in a different way, but there's some truth to it.
  - shawnz 8y ago
    At the same time, JIT can outperform native code in some specific circumstances, since there are certain optimizations which can be proven safe at runtime which can not be guaranteed to be safe at compile time
    - xxs 8y ago
      Actually one of the less known features of the JIT is the ability to deoptimize/recompile based on CHA (class hierarchy analysis) or pushed compilation request via invokeDynamic&friends.
    - gameswithgo 8y ago
      this is a thing people say a lot but it is not something that seems to often result in an actual java program or benchmark being faster than program compiled AOT by an equivalently smart compiler (llvm etc)
  - wolf550e 8y ago

duxup 8y ago

>stuff hyped on HN HN is going to be inclined to take a look at new-ish stuff.

TeMPOraL 8y ago
Indeed. For better or worse, that's what the "N" in "HN" stands for - "News".

mfatica 8y ago

How does this compare to the .NET ecosystem?

dRaBoQ 8y ago
Why downvote ? C#/Visual Studio is one of the best languages out there.
paulmd 8y ago
C# is a better language. Java 8 started to catch up with some of the quality-of-live niceties, but Java has a lot of mistakes baked into the language and interfaces that can't be removed without potentially breaking a lot of stuff, which the consortium is not willing to do. C# and DotNet were designed with the wisdom gained from the early days of Java implementation and sidestepped a lot of these messes. Java has a substantially better ecosystem. The tooling is just miles ahead of what exists in the DotNet world. Until very recently you developed in Visual Studio and you ran on Windows in production and that was that. They're working on Linux support and a broader ecosystem but they are probably a decade behind what is available on Java. Even stuff like package management is crude, NuGet is a joke compared to Gradle.
- GordonS 8y ago
  Packet is a great alternative to the NuGet client. Tooling might be slightly behind Java's, but honestly, there's not much in it. Dotnet Core might only have been available on Linux for a few years, but Mono was around for many before that. The dotnet CLI also recently got the concept of 'global tools', which are akin to NPMs. A lot of work is also underway on better cross-platform performance analysis, crash dump handling and the like for runtime in production[0] Is there anything in particular you miss? [0] https://devblogs.microsoft.com/dotnet/introducing-diagnostics-improvements-in-net-core-3-0/ https://devblogs.microsoft.com/dotnet/introducing-diagnostic...
  - WorldMaker 8y ago
    According to the roadmap, Mono's JVM interop used for Xamarin Android will be making its way more directly into .NET Core and will light up on almost every platform, which would give .NET greater, direct access to the Java ecosystem as well.

peterkelly 8y ago

Despite its title, the article was not about Java 8.

outworlder 8y ago
You can try appending "in Go" or "in Tensorflow" to see if the title still makes sense.
- the_af 8y ago
  The author was trying to be polite and avoid sensitive issues, but one prefix that also almost always works in HN titles is "In China". You can have it all: "In China, IT runs on Java 8 in Tensorflow" The perfect HN title! :)

dRaBoQ 8y ago

C# ?

ksec 8y ago

This. Technically there is nothing I don't like about JVM right now, everything that seems impossible 15 years ago is now solved. AOT used to be bag of hurt with GCJ ( I know I could use Excelsior, not sure if it was free in my time though ), but now even that will be an supported option from Graal. Java the languages still isn't pretty, but it has been much improved. OpenJDK is GPL and apart form the trademark ( ? ) with Java ( I didn't read much into the JakartaEE problem, ) everything should be fine. I am just a little uneasy with Oracle lurking around, I just don't know what they are going to do next.

pron 8y ago
> I am just a little uneasy with Oracle lurking around, I just don't know what they are going to do next. What do you mean by "lurking"? Oracle is the company developing OpenJDK, and it will continue to do so. All our projects are done in the open, with lots of communication.
- jptoto 8y ago
  The licensing has gotten super onerous.
  - sanxiyn 8y ago
    What licensing? OpenJDK is licensed under GPLv2 plus Classpath exception, the same as ever.
  - pron 8y ago
    The licensing has gotten far better. First, Oracle has just open sourced the entire JDK for the first time ever, and second, instead of offering a mixed free/paid, open/proprietary JDK (with -XX:+UnlockCommercialFeatures flags), it now offers the JDK under either a completely free and open license (under the name OpenJDK) or a commercial license for Oracle support subscription customers (under the name Oracle JDK).
    - ksec 8y ago

dlandis 8y ago

> So Java is not only the safe choice for serious server-side software; it's also the bleeding edge. Sure for core Java (OpenJDK), but what the future of JEE licensing and development? Even non-"enterprise" apps typically make use of some JEE stuff like servlets and JDBC. Is it really the "safe" choice when, apparently, the trademark agreements have just fallen apart? https://headcrashing.wordpress.com/2019/05/03/negotiations-failed-how-oracle-killed-java-ee/ https://headcrashing.wordpress.com/2019/05/03/negotiations-f...

ses1984 8y ago
Pardon my ignorance but what does any of that trademark stuff have to do with jdbc?
lenkite 8y ago
JDBC is not JEE - it is core Java. Servlets are the original web-container Java spec, independent of JEE. Both are great specs supported by several stable and performant implementations - rock solid tech compared to a lot of the flaky stuff you find advertised today.
- 0db532a0 8y ago
  How are Java programmers implementing RESTFUL APIs these days?
  - atoko 8y ago
    Spring Boot with Webflux and any rx supporting libraries you can get your hands on
    - 0db532a0 8y ago
      Thanks.
  - lenkite 8y ago
    Many developers don't want to think too much and generally choose Spring boot for a stable, highly-popular and well-documented framework. There is nothing wrong with this choice but I find it too bloated for lean container based micro-services. Dropwizard and Micronaut are pretty good for getting a smaller and saner footprint. If you need more than REST, say you want a lean MVC-based web-framework, then Blade is also a good choice. You can also choose not to use a framework and say use code-generation from a swagger/openAPI REST document and implement the remaining bits on your own. If your deployment target is AWS, you can also choose to leverage Netflix's fantastic set of libraries. Java has tonnes of options, so you usually need to spend some time evaluating what goes into your stack.

chvid 8y ago

Yes! Java 8 is good. And Excel is by far the best spreadsheet out there. I don't know enough about Sharepoint but it seems like the normal world has actually chosen very well when it comes to technology.

SebastianM 8y ago

> low-overhead in-production profiling/monitoring/management This is a joke, right? The management overhead for the JVM in production environments is huge. It's really hard to get it right.

StreamBright 8y ago
Not sure what you are talking about. Can you give me some examples?
- alfalfasprout 8y ago
  Tuning the heap size, GC tuning, etc. are often needed to avoid huge GC spikes out of the box. Not to mention performance is pretty meh compared to something like Go for applications where non-trivial compute is needed.
  - StreamBright 8y ago
    GC tuning should be trivial for every Java shop. Yeah I guess you can find use cases where Go is faster than Java but in that case if this matters I would go for Rust be because I like it more than Go.

papaf 8y ago

The funny thing is that from a purely technological point of view, Java (even the 5-year-old Java 8 and certainly recent versions) is far ahead of most other stuff hyped on HN (as well as less hyped stuff). The technology is certainly impressive but it isn't equipped to deal with the modern world. It is trivial to run 10 Node.js applications in the memory of one JVM application. This never used to be a problem, but now the cloud is forcing apps to pay for the resources they use its a kiss of death. There is also the move to serverless and the slow start of the JVM which makes it literally the worst choice out of all the alternatives. Oh, and lets not even start on the train wreck of Oracle's stewardship -- Java 11 is competing with Java 8. Java will survive but I cannot see it having any place in a modern software stack.

sanxiyn 8y ago
What's wrong with Oracle's stewardship? I am not a fan of Oracle, far from it, but Oracle's stewardship of Java has been exemplary.
- papaf 8y ago
  Currently: - The licence changes causing a premature move to Java 11 or OpenJDK out of fear of an audit. Today a colleague was investigating a Segmentation fault in the JVM because we moved to the OpenJDK. This is not productive work. - The future of j2ee is uncertain: https://headcrashing.wordpress.com/2019/05/03/negotiations-failed-how-oracle-killed-java-ee/ https://headcrashing.wordpress.com/2019/05/03/negotiations-f... How did you get to "exemplary"? Have you got any examples?
deleted 8y ago
[deleted]
haglin 8y ago
I haven't tried serverless, but shouldn't that be Java's cup of tea? The JVM can load code dynamically and adapt the runtime to the work load. Maybe there is a framework missing, so those that provide serverless starts a new JVM per function call, but they shouldn't really have to do that.

gameswithgo 8y ago

.NET Core is winning a lot of benchmark comparisons now. And one might consider Rust to be more bleeding edge.

pron 8y ago
Java and Rust are both bleeding edge in their respective domains, which are quite disjoint. I like them both, and Rust may well dominate its domain one day as much as Java dominate its own (although Rust's domain is even slower-moving than Java's, so that process may well take decades). I don't know of .NET Core winning any quality industry benchmarks that people actually pay attention to, let alone a lot of them.
- gameswithgo 8y ago
  TechEmpower BenchmarkGame And SIMD is coming soon in .NET Core 3 which should be a big jump for many workloads.

tomohawk 8y ago

It takes a lot of power to push something that large. A lot of brain power to grock the ecosystem. Outside of the Java bubble, the view is quite a bit different. All that sophistication looks like a wasted effort. Take something as simple as admining the garbage collector. Java has a big selection of GCs, and each has their bunch of knobs for tuning. And you have to pay attention to that stuff. After working with Go for several years, at large scale, we never once had to touch any knobs for GC. We could focus on better things. Any of the Java stuff we deploy and deal with we have this extra worry and maintenance issue. And that's just the GC.

gerbilly 8y ago
> Java has a big selection of GCs, and each has their bunch of knobs for tuning. And you have to pay attention to that stuff. You never have to touch them in the Java world either, unless you like making performance worse that is. I've never ever seen a case where fiddling with garbage collection parameters didn't make things slower. I worked with a guy who worked on a popular java compiler, and he says the same thing. he never twiddles GC parameters either.
- nemothekid 8y ago
  Cassandra has benefitted from so many GC tweaks that I find this view hard to believe. i can only imagine someone having this view if they have never cared about latency. How have you never experienced a multi-second GC pause on default CMS settings?
- tomohawk 8y ago
  What sort of scale are you working at? At our scale, it is normal to look into these sorts of things. Reading and understanding and applying articles like the following is absolutely necessary. http://clojure-goes-fast.com/blog/shenandoah-in-production/ http://clojure-goes-fast.com/blog/shenandoah-in-production/
  - gerbilly 8y ago
    Medium scale. It's not like I need to pimp each of my servers like it's a Honda Civic. If the load gets too high, I just add another instance. It's way more economical than wasting developer time fiddling with GC params.

tus87 8y ago

Poor start-up time, terrible application bloat, uninspiring language with poor concurrency support, massive RAM requirements, everything XML, complex tuning required, what a nightmare. No wonder the world is running towards Python and serverless as fast as they can...

icedchai 8y ago
Then they discover that even though Python is quicker to develop with, it actually runs much slower and has poor threading support. Since async only gets you so far, you try multiprocessing. It turns out running all those Python worker processes actually takes up more memory and CPU than the equivalent Java app... Also, most of the things you complain about are not Java: they are the fault of JEE (aka J2EE) and "app servers."
chimpburger 8y ago
CPython is 100 times slower and has no multi threading support (CPython is single threaded). JVM code can outperform native C code. The JVM supports many advanced languages (Scala, Clojure, Kotlin) and it can even run Python code (Jython) faster than CPython. For concurrency it has this ultra powerful library https://akka.io https://akka.io (Up to 50 million msg/sec on a single machine. Small memory footprint; ~2.5 million actors per GB of heap.)
- ptx 8y ago
  Jython seems to be much, much slower than CPython, actually: https://pybenchmarks.org/u64q/jython.php https://pybenchmarks.org/u64q/jython.php The only benchmark where it's faster is the one involving threads, which makes sense. CPython definitely has multi-threading support, but it also has the Global Interpreter Lock preventing threads from actually executing bytecode at the same time. Jython doesn't. People have written patches that successfully remove that GIL, but those patches make single-threaded performance worse and thus haven't been accepted.
  - chimpburger 8y ago
    I consider that as basically no multithreading support. CPython multithreading is useless in comparison. Those benchmarks indicate that the Jython compiler is far from optimal. The equivalent code rewritten in Java would be an order of magnitude faster. https://julialang.org/benchmarks/ https://julialang.org/benchmarks/ (note the single Python outlier there is the result of calling a C library for matrix calculation). Anyway, the JVM and CPython are fundamentally not comparable. One is interpreting, and the other is a JIT compiler. There are Python JIT compilers that would make a better comparison. However, as a language, Python is not optimal for large codebases. Comparing the languages only (not their implementation), Python is good for small scripting tasks, Java is better for very large scale projects.

negamax 8y ago

Isn't Minecraft written in Java. Many Fortune XX have their entire product lines written in it. Frankly, I don't understand the hate it gets on HN.

discreteevent 8y ago
Most of AWS, a lot of Google - as far as I know.
gameswithgo 8y ago
yes, and I had to pay for a lot of ram on servers because of it ;( The creator of notch chose java because when he started minecraft he thought that would let it run in web browsers. He wouldn't choose java if he could do it over again.
- negamax 8y ago
  Do you have the link to back up the statement about running in browsers? Notch is super talented. MC was released in 2009. No way, he didn't know about browsers and Java
- pron 8y ago
  Paying for RAM on servers is one of the cheapest ways you can pay for performance.
imtringued 8y ago
It is also one of the poorest performing games in the history of video games.

vijucat 8y ago

Great points, but it's actually much simpler than that: if you want static types, you have already eliminated the majority of HN darlings (JS, Python, and Ruby). Where do you? Most developers turn to C++, Java, or C# (not Haskell or F#, for example), and of these, Java and C# are both great for productivity and not daunting for someone just starting out, unlike C++. There was a period after 200x where developers managed to throw out a bunch of babies along with the bathwater when they rejected Java, UML, SQL, and everything else that was used in 199x. After all, these are all literally from the last century, so they must be "uncool", amirite? /s The preference for dynamic or duck typing in the name of productivity has always rubbed me the wrong way. To keep it brief, my defense / elevator pitch for static typing is: "Slow is smooth. Smooth is fast" :-)

mevile 8y ago
While I still like Python, Python and Ruby haven't been darlings of anything in probably the last 10 years. Go, Rust, Swift, and Kotlin are newer statically typed languages that lots of devs on here like though.
- archgoon 8y ago
  Python's relevance got renewed by the ML frameworks (Tensorflow) and notebooks (Jupyter).
  - new4thaccount 8y ago
    This. Jupyter notebooks, Matplotlib, Numpy, Spyder...all that made Python big again as ML and AI became the new hotness recently and the killer app for Python. Outside AI, Python is a really good scripting language for both Linux and Windows. My entire industry seems to run off of Python for process automation and analysis. It really is a lingua franca in this space.
    - lytefm 8y ago
      I agree. During my Maths + CS studies I've been using mainly MatLab and R, Andrew Ng's famous Machine Learning intro was also taught in MatLab/ Octave. But using just one „proper” general purposing language like Python instead makes way more sense, especially when building software from scratch. Need a custom ERP? Build one with django. A Web Server? Go with flask. Integrating some ML pipelines? Easy.

sl1ck731 8y ago

I was never super into Java development. I started working in 2014 and was introduced to Weblogic, Jenkins, huge Maven POMs and all the rest, then went into Cloud consulting. When I sit down to do anything I get so wrapped up in all the stuff that comes along with Java and feel like I have to use some huge IDE like Eclipse (I hate) or IntelliJ (I <3 U Jetbrains) to do anything "real". If I could just write code and have a simple package manager like NPM or even Go packages and not be hindered by trying to get VScode to work I would never look back. I just waste so much time trying to understand the ecosystem. I know that isn't a great excuse (not wanting to take the time to become an expert on tooling), but people who came into the professional space in the same time frame likely also just see it as an obvious path to just avoid all the cruft. What I really want is to get a "lite" Java project like this up and running with all of the smart people's opinions in place that I can develop entirely in a lite editor (preferably without XML anywhere). Maybe something like Spring Boot would solve that but I have not investigated that yet.

bgorman 8y ago
The answer you are looking for is called "Clojure".
pdpi 8y ago
Java-the-language is a fairly crummy thing to work with, it’s Java-the-ecosystem that’s genuinely good — the JVM, the tooling, etc etc. The quality of IDEs available is definitely a very large component of that. Doing Java on a lightweight editor seems like a way to pay the price without reaping the benefits.
- js2 8y ago
  I use TextMate (!) to maintain an Android SDK that's a mix of Java, C and C++ avoiding Android Studio like the plague, to maintain an iOS SDK that's mostly Objective-C, similarly avoiding Xcode's editor, and to maintain the backend written in Python that these SDK's talk to. I've got enough going on in my head w/o having to deal with the complexity of two different IDEs. Anyway, for me Java-the-language is fine. The tooling, at least as it comes with Android (looking at you gradle and all its Android plugins) is what makes me want to pull my hair out.

matthewmacleod 8y ago

I had cause to use a bit of Java recently, so I could wrap an existing library that did exactly the thing I wanted. I haven't used it since university—back in the 1.4 days—and I was actually pleasantly surprised. Performance was great, concurrency was easy, features like type inference and streams made the experience much more pleasant, and obviously the development tools are still first-rate. The absence of a package manager like Bundler or Cargo was frustrating for someone coming from that environment – as was the effective requirement to use an IDE. But on the whole, the platform feels like something that totally-hip-and-edgy-clique developers like myself are too quick to discount.

syjer 8y ago
>The absence of a package manager like Bundler or Cargo was frustrating why you did not use maven or gradle?

overgard 8y ago

I used to be a Java hater (I'm much more neutral now -- I even find aspects of it pretty pleasant). To me, it was never about the technology of Java (always been pretty impressive), or even the language (a little verbose -- but so is C++ and C# and I like both of those), it was really just about the ecosystem. For whatever reason 2000s era java had soo many libraries that were just insanely over-engineered and had these absurdly deep object taxonomies and trying to figure out how to do something came down to figuring out how 5 or 6 different classes interrelated. It was such a nightmare, especially since the IDEs back then weren't as smart as they are right now. I think it's become a lot better now though, modern libraries seem to have learned a lot of those lessons, and having proper closures makes a huge difference, and things like IntelliJ are really great about making dealing with the verbosity much easier.

jacques_chester 8y ago
A lot of the improvements in the ecosystem came from improvements in the language. Go4 patterns are in part shaped by language.
deleted 8y ago
[deleted]

arcticbull 8y ago

Respectfully I'm not sure that's true. > State-of-the-art optimizing compilers. LLVM provides coverage for many of the new languages that are hyped these days (with the notable and truly unfortunate exception of Go). LLDB provides an excellent debugger infrastructure. > State-of-the-art GCs. True, there's some good work there but I'm excited about languages that don't need GCs at all, so that we can finally stop tricking the memory wizard into complying with our workloads and focus on determinism, power efficiency and memory efficiency. > Low-overhead in-production profiling/monitoring/management. Correct me if I'm wrong but a lot of that is available in dtrace is it not? This is actually why I'm so excited by LLVM. I think it's the biggest advancement in computer science in ages and ages. It allows compiler engineers to focus on bringing what they do better and differently to the stack. It allows them to leverage the years of work and bundles of PHDs worth of research that went into the rest. All that time Go wasted developing assemblers for platforms should have been spent focusing on Go and letting LLVM handle it. Over time the delta between what Java has and what LLVM has will shrink which in turn narrows the gap between Java and every other LLVM based language. Think about it, macOS is basically just various front-ends for LLVM. Apple's implementations of OpenCL and OpenGL, the Metal Shading Language and Core Image are all wrappers for LLVM. Swift is a wrapper for LLVM. Clang makes C and C++ fancy wrappers for LLVM. Rust is a wrapper for LLVM. Almost everything your mac does is a fancy front-end for LLVM. Even Safari was (until B3 backend) a fancy front end for LLVM.

pron 8y ago
As I said in another comment, there can be more than one thing that's cutting edge, especially as the JVM and LLVM operate at completely different levels. Never mind GCs -- LLVM isn't even safe, and neither is WASM; and that's good at that low level. In fact, LLVM is employed by Falcon, the Zing JVM's JIT, and OpenJDK's HotSpot is compiled to LLVM on Mac. > I'm excited about languages that don't need GCs at all, so that we can finally stop tricking the memory wizard into complying with our workloads and focus on determinism, power efficiency and memory efficiency. That's fine, but it seems like giving up GCs comes with its own non-negligible costs, so much so that the two hardly compete in the same domains. > Correct me if I'm wrong but a lot of that is available in dtrace is it not? They have similarities (closer analogs would be https://github.com/btraceio/btrace https://github.com/btraceio/btrace and http://byteman.jboss.org/ http://byteman.jboss.org/ than JFR), yes, but operate at different levels with somewhat different capabilities. > This is actually why I'm so excited by LLVM. I think it's the biggest advancement in computer science in ages and ages. LLVM is popular, extremely useful, and quite cutting edge in its domain, but there isn't much of a "computer science" advancement as there is, e.g., in Graal/Truffle. > It allows them to leverage the years of work and bundles of PHDs worth of research that went into the rest. It certainly does, but there's a lot that LLVM doesn't give language designers that a JVM does, like GCs and high-level language interop. > Over time the delta between what Java has and what LLVM has will shrink which in turn narrows the gap between Java and every other LLVM based language. I don't know if LLVM wants to operate at Java's level or vice versa. While LLVM may offer some basic GC and Java may offer "safe" LLVM with things like Sulong, I believe their main focus will be their own respective levels.

keypusher 8y ago

I think everything you mention here is actually related to the JVM and not Java specifically, and while I agree the work is impressive, it’s also true that languages such as Kotlin and Scala benefit from that work while also offering some very nice modern improvements.

sidlls 8y ago

Java itself is fine. It's very popular--and that's the biggest problem. Not the language as such but the developer ecosystem around it. I am dead tired of seeing 80-character camel-case function and variable names, annotations that hide critical functionality of the code, stack traces dozens or hundreds of lines long because of the amount of indirection and poorly conceived configuration "languages" used to support dependency injection so developers can save a few characters of typing or mask dependencies and complexity, etc. The language may be fine, but it has been appropriated into the worst sort of terrible programming paradigms one might imagine.

datavirtue 8y ago
"80-character camel-case function and variable names" Isn't that a good thing? Tell all of us developers who write clear, clean code why you think that is bad? I don't ever get to 80 characters but I do write methods names that describe exactly what they do. If I can write it comfortably then I know I tried to do too much in the body.
Cacti 8y ago
We aren’t talking about Java the language. We are talking about the JVM.
ptx 8y ago
The terrible programming paradigms are workarounds for the terrible language. I read an old blog post about Spring's @Required annotation versus plain constructor injection and typed out a small example to get a feel for it – a simple class with one required and one optional dependency – which resulted in 23 lines of plain Java with constructor injection, or 16 lines of Java with Spring @Autowired magic, or 7 lines of Kotlin – no magic needed.

alkonaut 8y ago

You are describing the Jvm there, mostly. The jvm is great, and java is pretty tired even in the latest incarnations. I would have nothing against working full time with a jvm stack. So long as java isn’t involved.