Java sealed classes and exhaustive pattern matching (neilmadden.blog)

In some cases you want "default" handling, in other cases it's a runtime detection of a code issue. E.g. you could add a "fallback" case which is the same as "default" yet if your code doesn't exhaustively handle all sealed class cases won't compile. This would still create a fallback, if your sealed class is widened later on, but still allow you to error out if it's already the case right now.

That is a false dichotomy. Some enumerations have reasons to likely change in the future, others (most) either have no such thing or their changing would be so impactful to the system it needs to be signaled loudly.

That’s really no different than any other type information.

> It's always a tradeoff and you can also always fork or propose your own improved version of the concept

You are the person asserting that the concept as defined is incorrect.

There are just too many ways to use Scala, and everyone thinks they're doing it "idiomatically".

I disagree for an obvious reason: only a small minority of Java developers know Kotlin. When we want to see if the median developer is ready for some ML feature, we certainly look at other languages, but Kotlin doesn't matter beyond its size (which is not inconsiderable, but is also nowhere near the largest Java competitor that's quick to adopt features).

> Of course, java has had the advantage of enhancing the jvm while adding the features, where Kotlin had to work around the jvm in some cases (like green threads vs coroutines).

And C# could have done the same as Java but instead did what Kotlin did (or, rather, Kotlin did what C# had done), and we looked at both and said: we don't want that. That's why I'm saying that the "catching up" narrative doesn't hold up to any scrutiny.

Obviously, Java has been a huge innovator in optimising compilers, garbage collection, and low-overhead telemetry — areas where it's ahead of virtually everyone else — and focusing innovation on the runtime rather than the language has been one of James Gosling's stated goals since the beginning. So catching up is also silly when talking about a technological leader.

> But I feel it's wrong to downplay Kotlin's role in modernizing things on the jvm.

I'm neither downplaying nor overplaying it. As one of the Java architects, I'm telling you what it is. And "modernising things" on the Java Platform ecosystem is quite a different thing from influencing Java language features.

When we discuss other languages, and we discuss all of them, the ones that are discussed more are either the bigger ones or the more novel ones. Kotlin has shown some novelty, especially around its design of generics and of nullability types, but these happen to be two areas where we have actually not (yet?) made changes.

> Heck, if it weren't for kotlin as a temporary stopgap, I'd probably would've left the jvm while the features were still lacking in java.

That may be true, but it's irrelevant to what we're discussing. If anything, if Kotlin had served as a significant enough stopgap for those developers who prefer richer languages, it would have helped us not to adopt certain features or to adopt them more slowly.

I'm not saying Kotlin hasn't had a positive influence on the platform and, indeed, it may have helped especially in those years when Java stagnated, but it didn't push Java toward adopting more ML features.

I said "strategy" not "feature". That adopting a feature that a less successful language had invented or adopted is not the same as adopting the strategy of a less successful language was precisely my point about buying a sofa not being the same as "catching up" to a hoarder.

I said "we shouldn't be a hoarder", not "we shouldn't get a sofa".

> Now you're suddenly saying "we're aware that a non-tiny minority of developers prefer richer languages, and so we accommodate them, too" and "oh yes, we've been thinking of these features since 1991".

But Java started adopting ML features over twenty years ago. Where do you think we got generics from? The discussion about lambdas and generics between Gosling and Joy, even predating Java's release are Java lore (https://archive.computerhistory.org/resources/access/text/20...).

> Than whatever your ever-changing definition is. Java, thankfully, is no longer a small/smaller language, and is rapidly adopting actual useful features, including those from lesser products.

My definition isn't ever-changing, it's just relative. Being a relatively small language means, at the same time, not adopting the strategy of richer languages and adding select features but at a slower pace. This was Gosling's "a wolf in sheep's clothing" strategy since the very start: a very innovative, fast-moving runtime (where most of the benefits to the software's end user are hidden) wrapped in a non-threatening, conservative language. Conservative doesn't mean frozen and relatively small doesn't mean never-growing, but they do mean not adopting relatively rich fast-changing language strategy either. Our strategy has worked well for us, and yes, I still think it's silly to suggest we should change it because languages that aren't doing as well have a different strategy.

Even Java's GC and JIT came from Lisp and Smalltalk, but not the strategy (which was Gosling's point that these helpful features were part of thretening products).

It's the trivial cases that are compile time. The interesting templating is done with input that isn't defined within the source, and those can't be run entirely at compile time.

> And you automatically get things like safe SQL queries with parameter binding instead of injection vulnerabilities.

That's been solved for decades with parameterized queries (binding variables), and doesn't require interpolation in any way (at least not in the context we're using it here, but probably not at all in most DB drivers and engines). In fact, I would go so far as to say if someone is trying to use string interpolation instead of parameterized queries to avoid SQL injection, they've fundamentally misunderstood the problem and are trying to solve it at the wrong layer.

Also, if the string interpolation for the query is done at compile time, what type of content known at compile time is something that we'd be worried about SQL injection being in?

It is so good, that JetBrains themselves rather use Rust or C++ for native code libraries on their IDEs, and not officially supported on the Android NDK.