Then the rest of the article explains why this is NOT a good feature in practice.

I don't think it's unworkable either, but this is one of these little thing that Go decided to do different and convinced its fans that this is a great idea and all the other languages where doing it wrong. After a couple of road bumps appeared, instead of admitting there are some advantages to having official package names, we're now told that everybody should just set up their own custom domain with an nginx server or a Go Vanity URLs forwarder to serve traffic for their GitHub-hosted packages.

Kotlin gets this right. On send/receive, you can use trySend or tryReceive if you want to avoid exceptions. Considering Kotlin also has coroutines and structured concurrency, concurrency in Kotlin feels more ergonomic to me than Go. At least if you want to get concurrent code with least amount of bugs and not just least amount of extra keywords.

[1] https://dave.cheney.net/2014/03/19/channel-axioms

XML Schema (just like JSON schema) did not. When we're talking about a "simple format" in terms of security we are talking about parsing footguns like these features, not about complexities that may exist with any wire format such as schema and data validation.

Were there any better formats for simple messages back in 2002?

I would argue that yes.

1. ASN.1 is horribly complex, but PKCS #7 (Cryptographic Message Syntax, a.k.a. CMS) was already established, and it was better than XML Signatures in one regard: it did not try to fuse the signed content with its envelope. But this probably wasn't he best choice.

2. If all you needed is a bag of keys and values, you could easily go with an RFC 822 style header + values format (which worked well for both email protocols and HTML). As a bonus S/MIME was already well established at this point, so you had an obvious way to sign this data.

3. Simple binary formats like XDR (used by NFS) or simple textual formats like LDIF or the RFC 822 header format mentioned above could be freely combined with any existing signature protocol that did not mandate structured data (i.e. every signature protocol in existence before XML Signature came in).

4. An even better approach of course, would have been to say no to fine-grained cryptographic agility[1]. That was a terrible mistake, but it was the default design choice back in 2002, and it's hard to single out OASIS. The JOSE/JWT authors should have known better though. You could have define a couple of ciphersuites/version, and a simple, fixed signature protocol for each version.

5. The best approach would have been to just avoid signatures completely and require TLS, but this wasn't viable back in 2002. Even OAuth 1.0 and OpenID 1.0, which came out several years later, included their own cryptographic signatures, but their schemes were still far simpler than SAML.

I think the key takeaway today is that SAML is no longer necessary today. TLS is not an option for secure web resources. There are no features of SAML that cannot be supported by OAuth or OIDC (only security misfeatures). All IdPs and most products support OIDC. In fact, OIDC is probably more well-supported than SAML.

SAML is only used because of enterprise inertia and self-inflicted FUD. As a professional, we should treat SAML with the the same disdain we've directed we've directed towards Internet Explorer 6. This is an insecure legacy technology that presents a drag on the entire industry.

---

[1] https://www.blockchaincommons.com/musings/musings-agility/

This flow is safe against CSRF, since no authentication data is carried together with the flow. The only other safety issue I can see is using target_link_uri for CSF. The spec clearly mentions that this URL has to be filtered or ignored by the RP.

Instead of treating the (horrible) technical implementation as a feature, it addresses the real user-facing feature: I want to be able to click on a link on my IdP dashboard and be redirected to the app. The login would still be seamless, since you already have an SSO session active with the IdP.

[1] https://openid.net/specs/openid-connect-core-1_0.html#ThirdP...

https://openid.net/specs/openid-connect-core-1_0.html#ThirdP...

OpenID Connect is basically OpenID reimagined on top of OAuth 2.0, with using JWT for the identity data.

The core OpenID Connect spec is still purely a federated identity standard. There are many other standards pushed by the OpenID foundation, but OpenID Connect itself was never meant to be anything more. The main feature differentiator from the OG OpenID is that it's built on top of OAuth, so you can add other features supported by OAuth (like authorization) ad-hoc.

1. It has the ill-conceived "alg": "none". But this feature made breaking JWT so easy and low stakes, that many libraries have removed this feature completely, or just disabled it by default.

Modern RFCs that mandate JWT use in servers (e.g. RFC 9068) often explicitly forbid this, and the latest BCP for JWT (RFC 8725) recommends that libraries only accept or generate tokens with "none" when the user _explicitly_ requests that. And yet, we're still seeing "alg": "none" vulnerabilities even to this day. I'm not sure if it made sense to support "alg": "none" in the first place, but if we ended up doing that, the RFC should have been much more strict about this.

2. The other issue is mixing up asymmetric and symmetric encryption. You can't embed the HMAC password directly in the user-generated message; but if the library is not built securely, it would just treat the public key itself as the HMAC key when it gets an HMAC alg in the header. This makes forging tokens quite trivial if the library is misconfigured.

JWT is not nearly as bad SAML and its designers learned some important lessons (simpler base format, no canonicalization or embedded signatures), but this is still a design-by-committee standard that didn't properly involve. The full JOSE standard (including JWA) is even worse, but fortunately JWA doesn't get used a lot.

Yes. But keep in mind KLOCs are not easily comparable across languages. Java is notoriously verbose. A 500KLOC codebase in Java would usually be half that size in Rust. If your argument is that large codebases makes life harder for agents, you should go with a less verbose language.

I'm not sure what "manual optimization" means (isn't it a bit of an oxymoron when the agent does it?), but if your agent has the proper tools (e.g. ast-grep, rg, semble) it can deal with large codebases. Would the agent create slop? Yes. But it wouldn't be worse on the slop that humans created on every moderately-sized Java project I've worked on.

> in fact, agent-written code in a low-level language gets pretty slow well below that size

I've never seen this happening. I've seen agents writing suboptimal Rust code (e.g. copies instead of Cow). But while this occassionally happens with Rust, I've never seen an agent optimizing for Java where necessary (e.g. using object pools to avoid GC churn). Java is not magic.

That part i s true.

> with newer Java versions the only real gap with Kotlin is null-safety

But that part isn't. Kotlin has:

- Structured Concurrency: Coming to Java sometime in the future, but it's been in preview for very long now.

- Standalone functions that don't have to live in classes

- Properties

- Property delegation

- Data classes: more powerful than records. Can be used for large DTOs that you can modify with copy(). Java needs something like Lombok to make records more useful.

- Extension methods

- Context parameters

- Operator overloading

- Implementation delegation

- Inline functions (which can receive returning closures and reified types)

- Block syntax (supports `it` for unnamed arguments)

- Sequence abstractions: more powerful and more efficient than Java streams due to the inlining and block syntax.

This is just a partial list, but Kotlin clearly has a lot of things that Java doesn't. If you only personally care about NPEs that's fine, but that's not the only thing.

> And that "team" nowadays may also consist of many AI agents.

And that's the part where the hireability arguments collapse. Sure Claude Code works pretty well with Java. It also works well with Typescript, Python, Go and Rust. It would use types on all of these languages, and run a type checker or LSP on the dynamic ones. And while Java is statically typed, Rust has a stricter type system that prevents some types of runtime bugs that Java's type system won't like data races and forgetting to release a resource.

https://github.com/uber-go/nilaway

Not exactly the same solution as JSpecify, since it doesn't rely on annotations, but it's also more ergonomic.

I'm not comparing this to "null-restricted types", since that's a draft JEP that hasn't made it even into a preview feature. Go also had multiple proposals for explicit nilability in types, and while they probably have less prospect of ever seeing the light of day compared to Project Valhalla, as things currently stand, Go is in the same position as Java: They are both extremely prone to NEPs out-of-the-box and they both have external tooling that can help you avoid them.

Java null checkers have more comprehensive coverage potential compared to Go, but Go is the more ergonomic one here. You don't need a single extra annotation on your code.

I get it why this seems like a less drastic change, but this saddens me. Kotlin solves more issues with the type system (smart casts, reified types, immutability by default), without sacrificing readability. Unless I can see a solution in Java that makes dealing with NPEs as easier for lazy developers as ignoring them, I don't consider it a solved issue.

I also don't see the case for stability. Yes, if you're still on JDK 8, it would probably chug on for a couple of years. But we were talking about greenfield projects and newer JDK go EOL much faster. If you want patches, you'll have to run your app to a newer JDK, which may break a couple of things. Rust (within the same edition) or Go (within the same major version) break less than that.

As far as runtime compatibility goes, Rust and Go apps ship with the runtime. This can be better or worse for you, depending on what is your upgrade story, but I don't see a clear winner here. What I would give to Java over Rust is that you will have far fewer dependencies to take care of if you need to upgrade. But the same goes for Go.

For observability, I feel that with Rust you have a bit less that you need to observe (no GC to worry about). Tokio tracing is great, but observability requires a bit more effort. The go observability story is far worse. So Java probably has an edge here, but not something that ever felt like a game changer. My impression is that for most of the enterprise shops that love Java, observability means collecting unstructured log files through NFS and trying to find a needle in the haystack with primitive tools, but I've been out of touch with this world for a couple of years.

Productivity is something that is dead if you are AI-heavy. Sure, many shops are still wary about AI, and I totally get why, but this is a battle that's already been lost. Without AI, I would say I was about 3 to 4 times more productive in Rust than I was in Java, but ramping up that productivity took at least 1 year of practice. It's not time most companies are willing to spend. With AI, this doesn't matter anymore, for better or worse.

I'm not arguing that Java is not chosen often for greenfield projects. It's clearly extremely popular in many circles, especially outside startups and big tech. But I think the reason Java is chosen have little to do with the reasons you've mentioned above and more with organizational preferences.

I'm not sure what kind of tools you mean, but unless you're looking for something that just works exactly the way EJBs do for some mysterious reasons, I don't see why you can't do most "enterprisey" things with Rust or Go. Or Python or TypeScript for that matter.

Which Java famously does not have.

> Rust is too low-level for typical enterprise app where requirements changes twice a day. You end up spending time and tokens fighting with borrow checker.

In my experience, you do not spend tokens fighting with the borrow checker anymore, newer models are smarter. But it might not be ideal for a lot of CRUD applications.

> C# is MS product, which is no-go for some folks.

This is 2026, it's not 1996 anymore. .Net works on Linux and Microsoft is as friendly towards open source and open standards as a Big Tech company can be.

If anything, it was Oracle which more recently sued another company for using a JDK alternative. And this was a lawsuit that, if accepted, could have put the entire idea of API compatibility in danger and deal a severe blow to the Open Source movement.

Anyone who is morally bothered by MS but is unfazed by this is probably just mentally stuck in the 1990s.

> Kotlin probably would be the answer.

I love Kotlin, but I'm afraid that's not the case. The conservative organizations that choose Java out of inertia, would keep choosing Java over Kotlin, even if Kotlin is a better JVM language which is facing no downside.

For anyone who doesn't need to be on the JVM or work with JVM tooling, Kotlin doesn't cut it. It doesn't have null pointer dereference problem in theory... Only it does in practice if you're using any Java API that may return null (all these bang-decorated "Platform types"). Generic type erasure can only be overcome in inline functions with reified types. And building and deploying artifacts without docker is still a mess.

I found Kotlin extremely publishing for Java shops in the past, and I've converted multiple departments totaling over hundreds of employees to use Kotlin. But that was before AI. The rationale was simple: Java is an entrenched language that leads to bloated code, slow development cycles and way too many avoidable bugs in productions. Kotlin solves some if these issues, and it's very easy to learn for a Java engineer, while still letting you keep all of your tools and libraries. And as a language (putting ecosystem aside), I find it better than either Go or Typescript, and far more ergonomic than Rust[1].

But all of these arguments die with AI. Rust is just as ergonomic as any other popular language today if you're using an agent, and the fact that an engineer spent their lifetime writing Spring Boot programs in Java you don't have time to let them learn a new stack from scratch doesn't matter anymore.

Sure, there are many companies where letting AI write the code is still not acceptable, but most of these workplaces will accept AI agents sooner than they accept Kotlin.

I feel a bit sad since I like many ideas about Kotlin (especially how amenable it is for making DSLs) but we've lost that opportunity

--

[1] Unless you have to write highly concurrent code without any data races.

They used a closed list of 3 vendors in prioritized order, and got 429ed out of two of them, while the third one stopped serving the mode.

This is less of a problem if you're running an agent locally and routing your problem to OpenRouter - you can pin to one or two models for consistency and just switch models when something goes bad. But the article is specifically about production traffic.

But Unix pipelines are not simple too. They have a couple of nitty-gritty details that often come out and bite you.

1. They can only stream raw bytes, so all the programs that deal with lists like sort and uniq have to separate items using a delimiter (usually newline). If you want to process data with that delimiter in it, you're in for a ride. And if you want to write a custom tool, you have to do all the splitting yourselves (luckily it's so common most programming language will provide a ready-made facility for you to do that). This is New Jersey approach again: "I'll make my code (the OS, the shell) easier to write, and in return make life harder for my users (the tool writers)".

2. Error are hidden by default in shell. Nowadays you can explicitly change this behavior, but you have to remember to do `set -o pipefail` and I don't think it was always there.

3. There is no data typing at all. Everything is binary or text. Nowadays a lot of programs just output JSON, and the users (if they even stay inside the shell) almost always reach for jq to parse it. But jq is not a Unix philosophy program: it's an entire streaming functional programing that can do quite a lot. But even jq gets hairy when you have to do a bigger query or transformation. In that case users often reach out to Python or another language and just move the business logic there.

I think this fits well with what the article is trying to say: Unix pipes are pretty easy (small) to implement on your own (compare that to something like Nushell's pipes). But the moment you to do something that's a little different than the happy path it was built for, you need to go for another tool (jq) that has its own built-in pipe and small programming language, because Unix pipes won't cut it. And for more complex (hehe) things, you'll have to reach for a larger (and simpler) tool: a full-fledged programming language.

I laud what TRON tried to do, but I don't think they had it right. They made the encoding too complex (especially for the 1990s) while Unicode offered a single Basic Multilingual Plane. Unicode quickly got complex too (mostly due to the mistake of adopting UCS2 and then repurposing that as UTF16 and adding surrogates, and later getting a little bit over the top with combining emojis), but TRON was complex in other ways. If you mixed both Chinese and Japanese in a single documents, you had a multiple encodings to care about and control characters to switch between them. Suddenly, the character encoding is not stateless anymore. You can say the same about Unicode, but the statefulness of UTF-8 or UTF-16 is local and easily recoverable. Same goes for the statefulness combining diacritics, and bidirectional markers (which are rarely used) only affect the display. TRON code plane switches, as far as I understand, mean that even a simple text search or regex search would stop working and need to be completely redesigned, since it now has to be aware of which language we're reading right now! That's a big break, as you say.

> It also had a lot more characters. Unicode dropped some of the older or rare characters, meaning some people can't write their last name with the correct character on a computer with Unicode.

Only if they're very old and born before or during the war or its not their legal name. The Japanese government restricts the Kanji that can be used in names to Jōyō kanji (regular use kanji) and Jinmeiyō kanji (personal name kanji). Together they add up to roughly 3000 kanji. The list was back in 1991 when Unicode 1.0 was released, but it did include all of them, and many more, as did previous Japanese standards that predated TRON like JIS X 0208. I feel like the "people can't write their name" was always a bit of cope. Japan is still the country of "the nail that sticks out gets hammered". If your name falls outside of the legally allowed list of Kanji, you'll suffer even if you're running BTRON.

[1] https://en.wikipedia.org/wiki/Han_unification#Examples_of_la...