3 ms·

dotnet and Java stand no chance in the modern world They are heavy, bloated, and try to do everything, at the end of the day they pick the lowest common denomi

dotnet and Java stand no chance in the modern world They are heavy, bloated, and try to do everything, at the end of the day they pick the lowest common denominator, for everything, and they ship it They want compile to a small executable, they are stuck and ended up just zipping everything and calling it a day They want to interop with native world, but they introduce runtime overhead and their GC/memory model is a barrier They want to AOT compile, but their runtime and libraries rely a lot on runtime reflection They want to be tiny, but they have ton of legacy package that makes them very heavy Just look at the success story of go, it invalidates any attempts to make both dotnet and java attractive, it is too late, even more too late in an ARM world where relying on a JIT is a weakness

vips7L 6y ago
> They are heavy, bloated, and try to do everything, at the end of the day they pick the lowest common denominator, for everything, and they ship it What does this even mean? > They want compile to a small executable, they are stuck and ended up just zipping everything and calling it a day Both can compile executables the same size as go? See core-rt or the graalvm native-image compiler. > They want to interop with native world, but they introduce runtime overhead and their GC/memory model is a barrier Java's GC's are probably better than any on the market, including go's. And I will agree that currently native interop from the JVM is more expensive than it should be, but they're working on it. > They want to AOT compile, but their runtime and libraries rely a lot on runtime reflection. Easily solved by just declaring what you reflect upon or using runtime agents to find it. It's more difficult than a language than was designed to do it from the start, but eventually all of the big libraries will have it declared already. Hibernate already does [0][1] [0] https://github.com/hibernate/hibernate-orm/blob/5eedda9a467fef44d924f64203023b2345b8415f/hibernate-graalvm/src/main/java/org/hibernate/graalvm/internal/GraalVMStaticAutofeature.java https://github.com/hibernate/hibernate-orm/blob/5eedda9a467f... [1] https://github.com/hibernate/hibernate-orm/blob/5eedda9a467fef44d924f64203023b2345b8415f/hibernate-graalvm/src/main/java/org/hibernate/graalvm/internal/StaticClassLists.java https://github.com/hibernate/hibernate-orm/blob/5eedda9a467f...
pjmlp 6y ago
I should resist to answer trolls, but then again, I can offer a presence to the audience. Java has had AOT compilation since around 2000, in fact the free beer AOT compilation and JIT caches now available on OpenJDK originate from BEA J/Rockit. Likewise in what concerns the free beer AOT and JIT cache on J9, it originates from WebSphere Real Time JVM. As most FOSS people weren't willing to pay for them, so urban myths about Java compilation support models get cargo culted, while those of us that don't have any issues working for the man got to enjoy them. Likewise .NET has had support for AOT compilation since the beggining with NGEN, then Windows 8 adopted the Bartok compiler from Singularity and Windows 8 .NET Native steems from Project N based on Midori learnings. And then there are the older ones from CosmOS, Mono, IL2CPP and the upcoming CoreRT. The success stories of Go are called Docker and Kubernetes, it hardly matters for anything else, while Java, .NET, alongside C++ and JavaScript, own the enterprise. Even Google has decided to replace the Go written parts in Fuchsia with either C++ or Rust.
- WhoCaresLies 6y ago
  I should also resist to answer to delusionists Java AOT story is all over the place, and it's not even good, remember the 300+mb executable from Excelsior? AOT low profile? yeah sure it invalidates the whole language features Dotnet AOT? i don't call experiments, products, and they have the same limitations as Excelsior AOT, they produce insanly large executables, or if you want to target something like GO, you need to give up on the language features, i don't call this a good experience Il2CPP, it's a transpiler; and same story as Excelsior AOT, it produces insanly large executable, the GC, and the code produced is very poor quality due to the nature of the language (lot manipulations at runtime, including reflection) Go success story is that it now go beyong docker and k8s, people write cli tools in GO (github cli one good example), they write all their servers in GO (Riot for example), and some start to do gamedev with GO (ebiten) Google is still using GO, it's not a system language it has a GC And since the Rust guy left, their rust effort vanished, at least publicly https://github.com/google https://github.com/google oh and BTW, we'll see wich one get flagged, the one who call someone a TROLL because he give valid arguments, or someone who call someone a delusionist
  - 6y ago

vips7L 6y ago

> They are heavy, bloated, and try to do everything, at the end of the day they pick the lowest common denominator, for everything, and they ship it What does this even mean? > They want compile to a small executable, they are stuck and ended up just zipping everything and calling it a day Both can compile executables the same size as go? See core-rt or the graalvm native-image compiler. > They want to interop with native world, but they introduce runtime overhead and their GC/memory model is a barrier Java's GC's are probably better than any on the market, including go's. And I will agree that currently native interop from the JVM is more expensive than it should be, but they're working on it. > They want to AOT compile, but their runtime and libraries rely a lot on runtime reflection. Easily solved by just declaring what you reflect upon or using runtime agents to find it. It's more difficult than a language than was designed to do it from the start, but eventually all of the big libraries will have it declared already. Hibernate already does [0][1] [0] https://github.com/hibernate/hibernate-orm/blob/5eedda9a467fef44d924f64203023b2345b8415f/hibernate-graalvm/src/main/java/org/hibernate/graalvm/internal/GraalVMStaticAutofeature.java https://github.com/hibernate/hibernate-orm/blob/5eedda9a467f... [1] https://github.com/hibernate/hibernate-orm/blob/5eedda9a467fef44d924f64203023b2345b8415f/hibernate-graalvm/src/main/java/org/hibernate/graalvm/internal/StaticClassLists.java https://github.com/hibernate/hibernate-orm/blob/5eedda9a467f...

pjmlp 6y ago

I should resist to answer trolls, but then again, I can offer a presence to the audience. Java has had AOT compilation since around 2000, in fact the free beer AOT compilation and JIT caches now available on OpenJDK originate from BEA J/Rockit. Likewise in what concerns the free beer AOT and JIT cache on J9, it originates from WebSphere Real Time JVM. As most FOSS people weren't willing to pay for them, so urban myths about Java compilation support models get cargo culted, while those of us that don't have any issues working for the man got to enjoy them. Likewise .NET has had support for AOT compilation since the beggining with NGEN, then Windows 8 adopted the Bartok compiler from Singularity and Windows 8 .NET Native steems from Project N based on Midori learnings. And then there are the older ones from CosmOS, Mono, IL2CPP and the upcoming CoreRT. The success stories of Go are called Docker and Kubernetes, it hardly matters for anything else, while Java, .NET, alongside C++ and JavaScript, own the enterprise. Even Google has decided to replace the Go written parts in Fuchsia with either C++ or Rust.

WhoCaresLies 6y ago
I should also resist to answer to delusionists Java AOT story is all over the place, and it's not even good, remember the 300+mb executable from Excelsior? AOT low profile? yeah sure it invalidates the whole language features Dotnet AOT? i don't call experiments, products, and they have the same limitations as Excelsior AOT, they produce insanly large executables, or if you want to target something like GO, you need to give up on the language features, i don't call this a good experience Il2CPP, it's a transpiler; and same story as Excelsior AOT, it produces insanly large executable, the GC, and the code produced is very poor quality due to the nature of the language (lot manipulations at runtime, including reflection) Go success story is that it now go beyong docker and k8s, people write cli tools in GO (github cli one good example), they write all their servers in GO (Riot for example), and some start to do gamedev with GO (ebiten) Google is still using GO, it's not a system language it has a GC And since the Rust guy left, their rust effort vanished, at least publicly https://github.com/google https://github.com/google oh and BTW, we'll see wich one get flagged, the one who call someone a TROLL because he give valid arguments, or someone who call someone a delusionist
- 6y ago