joe_mwangi

Born on August 13, 2025•90 Karma

About Submitted Comments Favorites

joe_mwangi•

2 days ago

•on: Where Is the JVM Tax?

More reasons why java value classes will be a game changer.

joe_mwangi•

3 days ago

•on: .NET (OK, C#) finally gets union types

Java’s planned approach is more like typeclass-style interfaces than unrestricted operator overloading. Types opt into core-defined operator contracts, rather than every library inventing arbitrary meanings for symbols.

joe_mwangi•

3 days ago

•on: .NET (OK, C#) finally gets union types

Damn. You're old school. Java’s answer is virtual threads, not async/await. The idea is that most server-side IO can stay in direct style enabling blocking-looking code, cheap virtual threads underneath. So you don’t split the whole codebase into sync vs async functions just to avoid blocking OS threads. CompletableFuture and reactive APIs still exist, but Loom reduces the need to use them as the default application model. You can now launch millions of virtual threads to do IO.

joe_mwangi•

3 days ago

•on: .NET (OK, C#) finally gets union types

Notice you point out features that were easy to add during the beginning where there was no concern of backward compatibility? Now that java is porting value classes to mainline and we might have them soon, and planned operator overloading through type class, I believe java approach is making careful design choices that are semantically sound, rather than adding features that create edge cases such as boxing invariants in unions like C#.

mrsmrtss•

3 days ago

So you try to say that Java gets to be more semantically sound by making bad choices early on? That does not make sense. Those choices are very difficult fix today and many of them can't be fixed. Say what you want but semantically more sound Java won't be. And the boxing with C# unions can and will be addressed later, this was a deliberate choice by the team to bring unions earlier.

lostmsu•

3 days ago

> and many of them can't be fixed... And the boxing with C# unions can and will be addressed later

No, they won't. C# already got itself into a corner with 32 bit arrays and 32 bit spans. And if unions are introduced as reference only that will never be fixed due to binary compatibility requirement.

longor1996•

2 days ago

The new C# unions are not reference-only. The attribute/interface allows implementing custom union types by writing `TryGetValue`-methods instead of a single `object? Value {get;}`. The compiler handles this transparently.

joe_mwangi•

7 days ago

•on: Java: Rethink Domain Primitives with Valhalla

Value types will be optionally null. What java will introduce to the tooling is narrowing of nullness types. Hence Foo! <: Foo? <: Foo. This will assist in enabling safe domains or scope in code that are null-restricted with ease. Hence we can model around such a type system rule.

joe_mwangi•

15 days ago

•on: Library for fast mapping of Java records to native...

Great stuff!!!

joe_mwangi•

15 days ago

•on: Library for fast mapping of Java records to native...

I'm actually planning to resurrect a dead raytracer project (https://github.com/mambastudio/MambaTracer) that has a GPU backend. And possible develop a future 2D API (a lot of work I know). There is an interesting world in multipurpose programming of GPUs, and it took me a while to realise prefix sum is the “hello world” in that area. As a matter of fact, most GPU code without efficient GPU prefix sum, don’t perform well for specific algorithms that might require some scan data, and that’s where CUDA dominates, which has an amazing implementation, and not in other areas such as OpenCL. The raytracer I was making, I encountered a bug that took me I think a month to deduce after some frustration, based on a discovery of my rudimentary struct implementation (through classes and annotation – which I totally agree with you they are a bit annoying) had an misalignment layout which made me rethink, something is wrong with my model approach. So, I needed to solve data and layout representation between java and native code, to be simple, concise, with little headache. If you notice the TypedMemory, the idea is to ensure a user can implement their own libraries with data models without depending on it, and thus becomes a simple plug. Unfortunately, @size will make your code have it as a dependency. Hopefully one day we have multifields as stack allocated arrays (https://web.archive.org/web/20251101203905/https://cr.openjd...) , hence maybe have value `record(char c, float[3] array) {}`

joe_mwangi•

15 days ago

•on: Library for fast mapping of Java records to native...

It's a long roadmap, but this is their ultimate objective. Once java has value classes, future carrier classes and member patterns, that's when we shall see some very huge interest for java in ML. Also, they plan to introduce typeclasses in which it will be convenient to introduce operator overloading, and collection/array literals etc syntax. The idea is to unify the types in java, and then enable much stronger semantics to ensure data oriented programming becomes ergonomic in java.

whizzter•

15 days ago

Valuetypes has been on the roadmap forever, meanwhile they put in the effort and bought out greenthreads out of retirement as virtual threads.

Even if they started properly on valuetypes today, it's probably still a 10 year slog to get the ecosystem to follow.

wood_spirit•

15 days ago

FWIW virtual threads are great this time around. That’s something whose time has come generally.

But yeah for me Java took a big leap forward when it got lambda but there hasn’t been another big leap since. Still so many obvious features and sugar to add to file off the sharp edges and remnants of enterpriseness.

elric•

15 days ago

Value types are a work in progress. It won't be (another) 10 years. Give it a few more releases.

joe_mwangi•

15 days ago

Yup. They started transferring to the main line, but will require many tests to know if they have any issues. https://github.com/openjdk/jdk/pull/31120

joe_mwangi•

16 days ago

•on: Library for fast mapping of Java records to native...

I have not used SBE but looking at it, my understanding is that it starts from an explicit schema, typically XML, and generates encoder/decoder flyweights over a binary buffer. That gives much more control to the user in terms of field order (very important), sizes. Here, TypedMemory takes a different starting point in which the Java record shape is the schema, and the library derives the FFM MemoryLayout/accessors from that. I think the difference is schema/codegen/protocol orientation vs Java-type/FFM/in memorylayout orientation.

joe_mwangi•

16 days ago

•on: Library for fast mapping of Java records to native...

Interesting approach. I think Project Babylon did the same thing https://github.com/openjdk/babylon/blob/code-reflection/hat/...

I had tested it and it's quite fast. Actually, you don't need to generate any bytecode on the fly. Problem is when you deal with array as fields, implementation becomes difficult. You can revisit if interested to come back to such an implementation one day.