Statistically LLMs generate more bugs for the same feature.

Right, but you should be doing analysis and choosing the right tool for the job. 9/10 or probably more Java projects never need to use FFI because of the sheer size of the Java ecosystem. C# has always needed a better FFI story because its ecosystem is an order of magnitude smaller.

Didn’t they start that from acquiring jet.com?

IIRC, they revamped Walmart.com around the time of the Jet.com acquisition, so that probably had something to do with it.

Cool! I had a friend working there at the time. First time I heard about F#

How about we just let people code how they want if the codebase doesn’t care how it gets written? If it doesn’t matter why must we use one particular tool versus another?

Because most code is paid for and the people paying want as much code as possible for as cheap as they can get it.

If your code is expensive, the fact is that now someone can write it cheaper.

That's the real problem, people making decisions that think more code == more software == more value. We've been through this over and over again, managers think they know better, engineers left to clean up their mess

Once union types land, it will just need first class support for checked errors instead of unchecked exceptions flying around everywhere.

You can't even read a file in Kotlin without Java.

Not true today anymore, but definitely true for a lot of its history.

thats pretty much what I mean, yes.

Java has first class sum types, pattern matching, and compiler exhaustion on types. It's probably far more expressive than C# currently until they get union types.

Well, C# has more powerful pattern matching, only compiler exhaustiveness on types is missing today. In Java, sum types (sealed interfaces/classes) require all members to have the same parent, so they can be used only in very narrow cases.

As opposed to C# that doesn't have any form of sum types?

C# will have more advanced sum types this year, it's currently in preview.

Their sum types aren't particularly useful since they can never be used to implement union types which I believe c# has plans for following their sum types already in preview. So I guess similarly neck and neck.

Afaik this was fixed a long time ago.

The GC is pluggable, that’s why you have so many to choose from depending on your work load. You rarely if ever have to touch those options. In the last 10 years all of my apps, since I run on a modern version of Java, only ever set max heap size and soon that will (finally) be figured out automatically: https://openjdk.org/jeps/8359211

I could be missing it because I’m not that familiar with bb, but looking at your repository it doesn’t look like you’re using any feature that was actually shipped with project Leyden. It looks like you’re just using AppCDS which has been around for a long time.

Ah it's not my repository (I don't have any public repo FWIW): it's a repository I stumbled upon and I decided to port it to a more recent version of the Leyden JVM (using proper AOT, not the very old CDS).

I re-used it for I found it's approach to generating 80 000 Clojure classes to then test bare JVM vs Leyden AOT vs full GraalVM startup timing interesting.