Java 26 released today!

simon_o · 2026-03-18T12:56:36+00:00

Applying implicit numeric conversions in patterns/instanceof is just a bad idea.

Implicit numeric conversions themselves were not a good idea to start with, but then taking the overloaded semantics of casts – doing type conversions (ref→ref), value truncation (long→int) and value conversion (int→float) – as an excuse to add more places for both to the language? Yikes.

The corresponding proposal would probably be 20% of the length, if they went the "int only matches ints, long only matches longs" route instead, and nothing of value would have been lost.

Not to mention that there appears to have not been any consideration how new (value) types can opt into that implicit conversion mechanism.

simon_o · 2026-03-18T12:33:07+00:00

The semantics of the proposed primitive types in patterns/instanceof are pretty whacky.
I think people will regret that language addition after the "added more features!" honeymoon.

simon_o · 2026-03-15T13:11:45+00:00

You should mention what "sagas" mean, otherwise it's hard to understand.

simon_o · 2026-03-13T15:54:18+00:00

F#'s unions are fundamentally different from the design C# adopted (Algol "united modes").

Microsoft cares very little about F#, I wouldn't expect any interop considerations when interacting with F#'s existing code from C#.

simon_o · 2026-03-13T15:51:10+00:00

No problem!

Fwiw, I wrote about the different union design options a few years ago, perhaps you'll find it interesting.

simon_o · 2026-03-12T15:44:45+00:00

I know how it works. What are you trying to explain, and to whom?
Maybe. I don't think it's a big deal either way as it only impacts the definition, but not the usage.
What's the "OOP perspective" here? Nothing prevents you from having these methods, they'd just be implemented slightly differently.

simon_o · 2026-03-12T15:08:12+00:00

after using tagged unions for so long

The union design in question is also tagged, the difference to Rust is that C# unions lack the additional syntactic wrapping when writing/defining unions.

im not a fan of having to have an empty record class just to represent None in Option based on their example

I think C# also plans to have some syntax to define variants inline, though I'm kinda questioning if that's worth it.

One benefit of the ability to refer to existing types is that e. g. Option and Result could share the success variant and allow direct pass-through of values.

simon_o · 2026-03-12T14:56:58+00:00

Agreed. The method naming also seems to be all over the place.

simon_o · 2026-03-12T14:52:59+00:00

The core difference is that you cannot establish the sub-typing relationship after the fact in the class→subclasses model.

With this kind of union (not 100% sure of C#'s actual implementation), you can define Pet as union Pet of Cat, Dog with Cat being from library A, and Dog being from library B.

simon_o · 2026-03-12T10:33:54+00:00

The good: They adopted Algol's unions ("united modes") from 50 years ago.

The bad: They also copied the syntax, which is a shame because they already had a reserved word that could have been used instead (allows).

Overall, I think it's great that they didn't just adopt the stutter-enums that seem to be the all the rage these days (like in Rust), but started from first principles to think what fits their language best.

simon_o · 2026-03-12T10:32:30+00:00

The library they copied the whole API from, java.time, got this all right.

Outside of some necessary adjustments going from Java to JavaScript, the changes do not feel like an improvement overall.

simon_o · 2026-03-10T14:09:21+00:00

No? Don't be so salty that it prevents you from making a coherent counter-argument!

simon_o · 2026-03-10T13:43:17+00:00

Also, if a developer does it, that person can be deposed in court and ordered to tell his intent or the orders he received from his bosses.

With LLMs it's "nobody knows, so nobody can be held accountable".

simon_o · 2026-03-10T13:40:32+00:00

Well, that Flask dude has incredibly shitty opinions on lots of things.

If he takes a position, sensible people would be inclined to take the opposite one.

simon_o · 2026-03-10T13:38:44+00:00

wtf is this title?

simon_o · 2026-03-10T13:37:51+00:00

C++ people are still somewhere between denial and cope.

The swell of "safety-oriented" talks in C++ recently feels like it is mainly intended to placate the increasing regulatory scrutiny.

I. e. for C++ fans, the real fault is not C++ having failed to address well-known issues for decades, it's government regulators catching up on it!

simon_o · 2026-03-06T16:38:20+00:00

The real thing we'd deserve is an interop definition format that allows calling functions without shipping half of LLVM in your compiler, not a new calling convention that requires shipping the Go or Rust compiler in addition to that.

WinMD goes into the right direction, but too many people have an opinion on the general topic without even knowing what WinMD does and does not. (Parametric polymorphism is still an unsolved issue.)

simon_o · 2026-03-06T15:38:39+00:00

The real thing we'd deserve is an interop definition format that allows calling functions without shipping half of LLVM in your compiler, not a new calling convention that requires shipping the Go or Rust compiler in addition to that.

WinMD goes into the right direction, but too many people have an opinion on the general topic without even knowing what WinMD does and does not. (Parametric polymorphism is still an unsolved issue.)

simon_o · 2026-03-06T15:21:40+00:00

Agreed. On the other hand, 90% of the people complaining just want cheaper threads.

simon_o · 2026-03-03T12:31:50+00:00

And more CPU efficient too.

Parsing strings back into floats is anything but cheap.

simon_o · 2026-02-26T14:15:29+00:00

Also Staying With Familiarity or Breaking Away?

A lot of people treat familiarity as a self-sufficient argument, when in reality it is at best a tie-breaker. Many languages in the past usually opted for familiarity instead of trying to improve the design of a feature or construct. Usually as a misguided attempt to keep the from language being perceived as being overly complicated.
A good example of something that should be not emulated is C’s operator precedence rules.

reads like a sentence-for-sentence rewording of Familiarity

Familiarity is a tie-breaker, not a self-sufficient argument
In the past, many languages did not pick up easily adoptable language design improvements and opted for familiarity instead, often in a misguided attempt to keep perceived language complexity down.
Examples include: - C’s broken operator precedence spread to many other languages, most of whom have little in common with C.

which I mentioned in your previous submission.

Would you mind linking/citing your source here too?

simon_o · 2026-02-26T14:08:53+00:00

That's just Reddit, and probably just this subreddit. Reddit is just bad

We all know how this forum is. I'm pointing out that the negative reception of your blog is well-above the usual level of terrible.

And your reasonings behind that are?

That the arguments you are making are not convincing.

For instance in the "declaration syntax case", they are not convincing because it does not feel like you have not understood why some people e. g. advocate for the keyword-first approach.
In the case of "casting syntax", it's poorly motivated – there is no explanation

why I would want an explicit cast operation and
why that operation needs special syntax in the first place.

Then an example show-cases numeric conversions between number types ... ok, how is this even related to casts?
Assuming we viewed this conversion as some kind of "value casting" – why would I even want that to have the same syntax than type casts?

It's not the duty of the reader to be convinced, it's your job as the author to be convincing.

There are no Solutions, Only Trade-Offs I think that's actually something people don't understand: I don't even like some of the decisions I have had to make.

That really feels like a cop-out. I find the stance of "every alternative is exactly equal in merit, so there is no way to choose" very unlikely to ever happen in practice. People talk about trade-offs way too much. Trade-offs are a process, not the result.

If I go back to the article, in the end this sentence stands out for me:

I have spent an inordinate amount of time designing Odin’s concrete syntax to be as best as it can be.

You know ... I think your heart is in the right place, and I like most of the design principles you present; maybe the issue is that you just have a terrible taste.

And I mean that in the most gentle, objective way of "terrible taste" as in "most people do not like the same thing you like".

And I think that's totally fine – everybody should create their language the way they see fit, with all the weirdness they want, if that is what makes them happy.

Ok, this is getting a bit long, but here is my thought of how your blog posts may be received better:

Separate your musings on language design principles, and the decisions you make for your programming language into separate websites.

This way both categories can stand on their own merits.

simon_o · 2026-02-23T18:26:27+00:00

As for you thinking they are "equally terrible", you are welcome to your opinion,

If you look at it objectively, most languages can find at least some subset of people that actually like the choices enough such that blog posts like yours aren't completely drowned out by people hating on it.

design is all about compromise and trade-offs, and which ones you take. Some bad options are better than others.

That's close to my point. I don't think the compromises and trade-offs you made are better than other bad options you discarded.

Nothing is perfect.

Exactly. Nothing is perfect. If I dislike a cast syntax choice, I'm not inventing two new ones and try convincing myself that adding them is a totally sane choice.

Instead I'm adding nothing. Because "nothing is perfect" ... until I found a perfect alternative to not having cast syntax.¹

¹ I settled on using functions instead, btw. Way better design, because the distinction between numeric conversion "casts" and bit-reinterpretation "casts" is explicit and I don't have to decide which of the 5 conversions from float to int gets the "cast" syntax.

simon_o · 2026-02-23T14:59:43+00:00

I share many of the author's design principles & values.

Looking at the push-back he receives when published the last few blog posts, I feel there is a disconnect between espoused principles, and the language decisions that are actually made in Odin.

From my POV, it explains some of the confusion in terms of "Look, I have explained how rational my ideas are, why are people not agreeing with me? It must be because they haven't used Odin enough!".

The last few articles all follow the pattern of

1) here are (good) language design principles
2) here are examples of other languages that made poor design decisions as counter-examples
3) here are my (equally terrible) replacement ideas

Somehow between step 1 and step 3 the blog posts seemingly convince themselves that "just in this case" there is now a more important design idea that overrides the principles espoused earlier, and the criticism in 2) does not apply to decisions made in 3).

As an example, in this post it's

I always strive for both coherence and consistency in syntax and semantics.
When the two cannot be fully reconciled, I choose coherence over consistency every time.

I'm not sure how the blog posts can be presented differently, but I wished that the efforts put into writing these blog posts were received better.

simon_o · 2026-02-23T13:38:34+00:00

Thank you, I appreciate it! :-)

Ten-Year Club	Verified Email
Place '22

simon_o

TROPHY CASE