4 ms·

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 mon

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.
- CamouflagedKiwi 5y ago
  I don't think this is a meaningful limitation any more. Go's ecosystem is big enough - I've been using it for a few years now and have only found a few esoteric things that aren't supported (and nothing big enough to be a showstopper). The quality is also really good; I've been impressed by many of the libraries we've picked up. Especially in light of vulnerabilities like log4j or that similar Struts one Equifax had a few years back, I'd much rather be working in the Go ecosystem than Java's.

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.
CamouflagedKiwi 5y ago
I don't think this is a meaningful limitation any more. Go's ecosystem is big enough - I've been using it for a few years now and have only found a few esoteric things that aren't supported (and nothing big enough to be a showstopper). The quality is also really good; I've been impressed by many of the libraries we've picked up. Especially in light of vulnerabilities like log4j or that similar Struts one Equifax had a few years back, I'd much rather be working in the Go ecosystem than Java's.