6 ms·

Have any of the relevant limitations been removed in the last decade+? I don’t believe so. Project Valhalla is 9 years on, is there an end in sight? When Java

Have any of the relevant limitations been removed in the last decade+? I don’t believe so. Project Valhalla is 9 years on, is there an end in sight? When Java & the JVM were first released, the treatment of primitive vs. what we now call “boxed” types received a lot of criticism, mostly of an aesthetic variety. In retrospect, I wonder how much bigger the Java and JVM ecosystem would be if user-defined, non-reference types had been there from v1.0.

therealdrag0 5y ago
> how much bigger Isn’t it already crazy big? Not sure this was holding it back.
- twoodfin 5y ago
  There are many niches where Java & the JVM are absent or fighting an uphill battle to occupy at all. Of those I’m aware of, the only ones where value types wouldn’t help fitness tremendously are on the client side, already a lost cause.
  - kaba0 5y ago
    What would those niches be? Non-openjdk JVMs occupy even ultra-niche use cases like hard real time, military usage, embedded (though arguably Java ME is just a subset of Java, so you may or may not consider it the same), and the other direction of crazy performant server machines is well-served by OpenJDK — apparent in how is it used on a very very huge percentage of all web servers with top companies relying on it almost exclusively (apple’s servers are mostly Java, google has plenty of java applications, alibaba is a java webshop, twitter runs scala with graal, etc). Just an interesting note, OpenJDK’s GCs can handle heap sizes well into multiTERAbyte ranges.
dralley 5y ago
Someone linked the thread from 2012 and even then a few of the concerns had been alleviated. However, hardware has also changed at lot since 2009, so it would be neat if someone did a new analysis.
62951413 5y ago
https://news.ycombinator.com/item?id=29666279 https://news.ycombinator.com/item?id=29666279 confirms that they're actually working on it now but it's such a monumental effort. A few years wasted before JDK8 were very damaging. That's what made people look for alternatives to the JVM, not its treatment of primitives. If Loom and Valhalla come to fruition in a couple of years the JVM would be competitive against golang. But the problems golang has to catch up with Java (e.g. error processing and migrating the standard library to generics) seem easier to fix.
- kaba0 5y ago
  But the actually big thing golang has no chance of fixing is the relative size of the ecosystems. Java’s ecosystem is huge!
  - lbriner 5y ago
    A big ecosystem isn't necessarily good. Although big is relative, it can mean "mature, well-known, multi-featured, well-supported, well-documented", it can also mean "Complicated, hard-to-reason, hard-to-pick a library, hard to know which of the many approaches is correct". In general, I would argue that most frameworks start pretty sensible and consistent and are much easier to use and they get worse over time as they try to be all things to all people and get spread too thinly.
    - kaba0 5y ago
      Well, as per the often referenced ‘No silver bullets’ paper, the only way to significantly improve productivity is to reuse code — no managed language provides an order of magnitude productivity increase over another. So I have to disagree, the ecosystem (which in the concrete JVM case has multiple competing solutions to most problems, with quite good quality) is like the most important factor.
      - adgjlsfhk1 5y ago
        one that might is Julia. getting a like for like comparison is hard, but DifferentialEquations.jl is roughly 10x smaller than petc/odeint, faster, and more fully featured.

therealdrag0 5y ago

> how much bigger Isn’t it already crazy big? Not sure this was holding it back.

twoodfin 5y ago
There are many niches where Java & the JVM are absent or fighting an uphill battle to occupy at all. Of those I’m aware of, the only ones where value types wouldn’t help fitness tremendously are on the client side, already a lost cause.
- kaba0 5y ago
  What would those niches be? Non-openjdk JVMs occupy even ultra-niche use cases like hard real time, military usage, embedded (though arguably Java ME is just a subset of Java, so you may or may not consider it the same), and the other direction of crazy performant server machines is well-served by OpenJDK — apparent in how is it used on a very very huge percentage of all web servers with top companies relying on it almost exclusively (apple’s servers are mostly Java, google has plenty of java applications, alibaba is a java webshop, twitter runs scala with graal, etc). Just an interesting note, OpenJDK’s GCs can handle heap sizes well into multiTERAbyte ranges.

dralley 5y ago

Someone linked the thread from 2012 and even then a few of the concerns had been alleviated. However, hardware has also changed at lot since 2009, so it would be neat if someone did a new analysis.

62951413 5y ago

https://news.ycombinator.com/item?id=29666279 https://news.ycombinator.com/item?id=29666279 confirms that they're actually working on it now but it's such a monumental effort. A few years wasted before JDK8 were very damaging. That's what made people look for alternatives to the JVM, not its treatment of primitives. If Loom and Valhalla come to fruition in a couple of years the JVM would be competitive against golang. But the problems golang has to catch up with Java (e.g. error processing and migrating the standard library to generics) seem easier to fix.

kaba0 5y ago
But the actually big thing golang has no chance of fixing is the relative size of the ecosystems. Java’s ecosystem is huge!
- lbriner 5y ago
  A big ecosystem isn't necessarily good. Although big is relative, it can mean "mature, well-known, multi-featured, well-supported, well-documented", it can also mean "Complicated, hard-to-reason, hard-to-pick a library, hard to know which of the many approaches is correct". In general, I would argue that most frameworks start pretty sensible and consistent and are much easier to use and they get worse over time as they try to be all things to all people and get spread too thinly.
  - kaba0 5y ago
    Well, as per the often referenced ‘No silver bullets’ paper, the only way to significantly improve productivity is to reuse code — no managed language provides an order of magnitude productivity increase over another. So I have to disagree, the ecosystem (which in the concrete JVM case has multiple competing solutions to most problems, with quite good quality) is like the most important factor.
    - adgjlsfhk1 5y ago
      one that might is Julia. getting a like for like comparison is hard, but DifferentialEquations.jl is roughly 10x smaller than petc/odeint, faster, and more fully featured.