3 ms·

Why would it be the new Java/.NET? You vastly overestimate that separate runtime as being a huge positive, it is almost indifferent to most niches where these t

by kaba0 3y ago

Why would it be the new Java/.NET? You vastly overestimate that separate runtime as being a huge positive, it is almost indifferent to most niches where these two are most common: servers, especially on the bigger side of things. For a devops team with a proper CICD pipeline, monitoring, whatnot, installing a runtime is beyond trivial, especially that many of it is container-based. So even if all else were equal, Go would need much much more positives to even start turning the wheel towards itself, momentum is huge in the industry (old Cobol systems are still clocking at places, even if they do so in a VM, as the hardware they are hardcoded against are too old now). Especially that it is not at all a net positive in many people's eyes: - it is very verbose (yes, it is in fact more verbose than Java, that had been bullied by everyone forever for being verbose..) - has terrible expressivity (java streams/.net linq) - smaller ecosystem (java is much larger than even .net, let alone go) - slow reflection (on the more enterprise-y end of the industry you sometimes need more dynamic workloads) Also add that both Java and .NET has native AOT compilation, so even that small benefit you mention may not be a dealbreaker, even if those are not as smooth a rides as go's.

za3faran 3y ago
Well said. In addition, golang seems to shun everything under the guise of "keeping things simple", so you don't see frameworks like Spring or ASP.NET. Of course pretending the issue doesn't exist doesn't make it so. At an employer, the reinvented a dependency injection + application framework, but poorly of course compared to the extremely mature offerings on the JVM and .NET, not to mention millions of dollars sank into maintaining it.
- trhhowaway232 3y ago
  Java DI isn't good either. It runs a full DAG on boot.
  - kaba0 3y ago
    There are entire second generation of “cloud-ready” frameworks for Java that does it at compile time instead.
doctor_eval 3y ago
Whenever someone mentions Java AOT, I look it up, and it’s a nightmare. Has it changed recently? I developed server software in Java for two decades, and I can tell you that the huge JVM was always a PITA for us, even after Docker became a thing. All those frameworks? We ended up throwing them out. And the slow startup speed of Java apps made our tooling sluggish. It was also a pain to ship tooling to non developers, for all the same reasons. Using Go after all this time was like a breath of fresh air. It’s fine for you to assert your own preferences and biases but you don’t represent all enterprise server developers.
- pjmlp 3y ago
  The only change is that now there are free beer AOT compilers, commercial AOT compilers have always been an option since around 2000.
  - doctor_eval 3y ago
    OK... and these AOT compilers work identically to JIT compilers in every way, with no caveats other than needing to specify the architecture in advance. Right..?
    - pjmlp 3y ago
      Naturally depends on the use case, yet they work good enough to be in business for 20 years. https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/products-services/jamaicavm-tools/ https://www.aicas.com/wp/products-services/jamaicavm-tools/ https://www.codenameone.com/ https://www.codenameone.com/ Android 5 & 6 (only changed back into JIT/AOT due to long compile times), https://www.infoq.com/news/2014/07/art-runtime/ https://www.infoq.com/news/2014/07/art-runtime/ Unfortunely the best well known, Excelsior JET, is no longer in business, most likely due to GraalVM and OpenJ9 being available as free beer, while PTC, Aicas Codename One are safe in their domains. There is also RoboVM (https://github.com/MobiVM/robovm https://github.com/MobiVM/robovm) as free beer, however it actually started as a commercial product, and the acquisition from Xamarin kind of stagnated it (naturally).
KronisLV 3y ago
> Why would it be the new Java/.NET? Because it's a seemingly "boring" technology that's not too hard to learn, seems to have a decent community/ecosystem in the works (let's see where it is in 5-10 years) and overall could hit the sweet spot of just being able to get things done with it in a 9-5 by a bunch of regular developers. > You vastly overestimate that separate runtime as being a huge positive, it is almost indifferent to most niches where these two are most common: servers, especially on the bigger side of things. For a devops team with a proper CICD pipeline, monitoring, whatnot, installing a runtime is beyond trivial, especially that many of it is container-based. I use containers and that won't change anytime soon, they're great! That said, CLR and JDK have some space overhead, even if a counterpoint could be made that storage is on the cheap side nowadays. However, there are also those who don't use containers and don't always have 1:1 reproducible environments (even though they should). I've personally seen a difference in the MINOR version for JDK bring down production by having some sort of an issue that caused the performance under load to decrease 10x in an enterprise project. It would be nice to get rid of that risk and just ship the whole thing, much like how a fat .jar instead of configuring an application server like Tomcat separately makes things easier, just a step further. Now, Java has some solutions for that, but I think that Go is in an even better position in that regard!

by kaba0 3y ago

za3faran 3y ago

Well said. In addition, golang seems to shun everything under the guise of "keeping things simple", so you don't see frameworks like Spring or ASP.NET. Of course pretending the issue doesn't exist doesn't make it so. At an employer, the reinvented a dependency injection + application framework, but poorly of course compared to the extremely mature offerings on the JVM and .NET, not to mention millions of dollars sank into maintaining it.

trhhowaway232 3y ago
Java DI isn't good either. It runs a full DAG on boot.
- kaba0 3y ago
  There are entire second generation of “cloud-ready” frameworks for Java that does it at compile time instead.

doctor_eval 3y ago

Whenever someone mentions Java AOT, I look it up, and it’s a nightmare. Has it changed recently? I developed server software in Java for two decades, and I can tell you that the huge JVM was always a PITA for us, even after Docker became a thing. All those frameworks? We ended up throwing them out. And the slow startup speed of Java apps made our tooling sluggish. It was also a pain to ship tooling to non developers, for all the same reasons. Using Go after all this time was like a breath of fresh air. It’s fine for you to assert your own preferences and biases but you don’t represent all enterprise server developers.

pjmlp 3y ago
The only change is that now there are free beer AOT compilers, commercial AOT compilers have always been an option since around 2000.
- doctor_eval 3y ago
  OK... and these AOT compilers work identically to JIT compilers in every way, with no caveats other than needing to specify the architecture in advance. Right..?
  - pjmlp 3y ago
    Naturally depends on the use case, yet they work good enough to be in business for 20 years. https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/products-services/jamaicavm-tools/ https://www.aicas.com/wp/products-services/jamaicavm-tools/ https://www.codenameone.com/ https://www.codenameone.com/ Android 5 & 6 (only changed back into JIT/AOT due to long compile times), https://www.infoq.com/news/2014/07/art-runtime/ https://www.infoq.com/news/2014/07/art-runtime/ Unfortunely the best well known, Excelsior JET, is no longer in business, most likely due to GraalVM and OpenJ9 being available as free beer, while PTC, Aicas Codename One are safe in their domains. There is also RoboVM (https://github.com/MobiVM/robovm https://github.com/MobiVM/robovm) as free beer, however it actually started as a commercial product, and the acquisition from Xamarin kind of stagnated it (naturally).

KronisLV 3y ago

> Why would it be the new Java/.NET? Because it's a seemingly "boring" technology that's not too hard to learn, seems to have a decent community/ecosystem in the works (let's see where it is in 5-10 years) and overall could hit the sweet spot of just being able to get things done with it in a 9-5 by a bunch of regular developers. > You vastly overestimate that separate runtime as being a huge positive, it is almost indifferent to most niches where these two are most common: servers, especially on the bigger side of things. For a devops team with a proper CICD pipeline, monitoring, whatnot, installing a runtime is beyond trivial, especially that many of it is container-based. I use containers and that won't change anytime soon, they're great! That said, CLR and JDK have some space overhead, even if a counterpoint could be made that storage is on the cheap side nowadays. However, there are also those who don't use containers and don't always have 1:1 reproducible environments (even though they should). I've personally seen a difference in the MINOR version for JDK bring down production by having some sort of an issue that caused the performance under load to decrease 10x in an enterprise project. It would be nice to get rid of that risk and just ship the whole thing, much like how a fat .jar instead of configuring an application server like Tomcat separately makes things easier, just a step further. Now, Java has some solutions for that, but I think that Go is in an even better position in that regard!