joe_mwangi

4 ms·

1.
by joe_mwangi 11d ago
Yes.. lol. The biggest argument now is Kotlin having nullness by default in the language. Just check around the comment section. Now java is planning to have them which will further help jvm to optimise for performance. Not sure what the ne
2.
by joe_mwangi 11d ago
Really? I don't thinks so. There is a reason JEP 539 is in preview. There is a reason internal annotations exists in current valhalla jdk prototype and upcoming java 28 such as @jdk.internal.vm.annotation.NullRestricted, @jdk.internal.
3.
by joe_mwangi 11d ago
Once it gets nullness types, hackernews is gonna explode!
4.
by joe_mwangi 11d ago
Typeclasses caught me by surprise. Smart move by the java team.
5.
by joe_mwangi 1mo ago
Also, future specialisation if it is introduced, it will enable the JIT to get enough information to ensure <T> becomes stored in cpu registeres or enable <T[]> to be flattened in memory.
6.
by joe_mwangi 2mo ago
Yeaaah. They are going to introduce approaches for the programmer to decide if tearability is allowed or not. Already there are internal annotations for fields and types to enable it that probably will become a language feature in future.
7.
by joe_mwangi 2mo ago
They are researching to have immutable arrays. Also multifields (stack allocated arrays as fields in value classes). So, there is a possibility.
8.
by joe_mwangi 3mo ago
I've done some tests with current value classes in latest prototype with full optimisation through annotation. Apparently, everything was being compiled to assembly code with no gc calls. It seems this old school ideology of slow java
9.
by joe_mwangi 3mo ago
Also, this will be used for future null-restricted types.
10.
by joe_mwangi 3mo ago
Better late than never.
11.
by joe_mwangi 3mo ago
This time, 30mb.
12.
by joe_mwangi 3mo ago
Yup. By design, value classes will use cpu registers as a 1st priority instead.
13.
by joe_mwangi 3mo ago
Until they implement member patterns. https://openjdk.org/projects/amber/design-notes/patterns/tow...
14.
by joe_mwangi 3mo ago
> yet But up the comment section, someone thinks they won't be there 'in the future'
15.
by joe_mwangi 3mo ago
And I notice, people aren't aware more things are being planned for. For example, the carrier classes being proposed, they will separate state description with state representation and this is where value classes will shine syntactical
16.
by joe_mwangi 3mo ago
And the only syntax change is adding 'value'.
17.
by joe_mwangi 3mo ago
Since they plan to have null-restricted types, then I don't see any issue.
18.
by joe_mwangi 3mo ago
But with null-restricted types, Integer! and int has no difference semantically and representation. They plan to introduce null-restricted types in future.
19.
by joe_mwangi 4mo ago
This is awesome. First step to an interesting direction of the language.
20.
by joe_mwangi 4mo ago
More reasons why java value classes will be a game changer.
21.
by joe_mwangi 4mo ago
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.
22.
by joe_mwangi 4mo ago
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 who
23.
by joe_mwangi 4mo ago
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
24.
by joe_mwangi 4mo ago
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. Hen
25.
by joe_mwangi 5mo ago
Great stuff!!!
26.
by joe_mwangi 5mo 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
27.
by joe_mwangi 5mo ago
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 interestin
28.
by joe_mwangi 5mo ago
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 type
29.
by joe_mwangi 5mo ago
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
30.
by joe_mwangi 5mo ago
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 ne

More ›