They've added it as an option recently.

I don't think the runtime is "much more advanced", the JVM has had most of these optimizations for years.

The JVM famously boxes everything though, probably because it was originally designed to run a dynamic language. An array list of floats is an array list of pointers. This created an entire cottage industry of alternative collections libraries with concrete array list implementations.

A float[] is packed and not a list of pointers in the jvm.

An ArrayList<Float> is a list of pointers though.

Arrays have a static fixed size though, making them far less useful in practice. Anything one builds with generics is boxed. Dotnet doesn't have this problem.

Currently you can get around this with Panama, even if the API is kind of verbose for the purpose.

Eventually value classes might close the gap, finally available as EA.

Valhalla is over 10 years in the works already and there is still no clear date when or if at all it would be released. It's very difficult to change (or fix) such fundamental things so late in the game.

Because it is a huge engineering effort to add value types without breaking existing binary libraries.

Doing a Python 3 would mean no one wanted going to adopt it.

Yes it is long process.

Some of the JEP in the last versions are the initial baby steps for integration.

They're famously working on changing that. I think we're all hopeful that we'll start seeing the changes from Valhalla roll in post-25.

Almost none of this is in the JVM. Escape analysis is extremely limited on the standard JVM, and it's one of GraalVM's "enterprise" features. You have to pay for it.

> one of GraalVM's "enterprise" features. You have to pay for it.

Free for some (most?) use cases these days.

Basically enterprise edition does not exist anymore as it became the "Oracle GraalVM" with a new license.

https://www.graalvm.org/faq/

by dynamically allocating FFI trampolines, which add their own performance and lifetime issues that would be unacceptable for Rust.

(I work at PowerSync)

This is a good point, and we definitely agree that the local sqlite database should be the source of truth for all things state management. The example here is consistent with that view because the intermediate providers and notifiers are stateless, their only role is to bundle related functionality as well as exposing database queries as typed providers (making it easier to read results in widgets because no explicit StreamBuilder is necessary).

We've recently published guides on using PowerSync with popular Flutter state management approaches [1], and we mostly agree that sync engines simplify state management to the point where intermediate layers are unecessary. Some really enjoy the structure Riverpod can provide though, and that's why we want to make sure PowerSync works well with those architectures.

[1]: https://docs.powersync.com/client-sdk-references/flutter/sta...

Perhaps they're referring to this famous objection of financial institutions to TLS 1.3, motivated by them not wanting to update their MitM software needed for compliance: https://mailarchive.ietf.org/arch/msg/tls/CzjJB1g0uFypY8UDdr...

TLS1.3 breaks MITM boxes because a client can establish a session key outside of the network with the middle box and continue using it afterwards in the middlebox’s network.