I'm not referring to some specific changes. It's just there are many type operators already and still not enough to express JavaScript.

In the earlier versions of TypeScript, I often stuck with something natural in JavaScript but cannot express the same thing with type annotations - It's like opening a pandora box, once some advanced type operators have been introduced, whenever I played with them I would quickly found more type operators to be desired.

And so it did. Things were getting better over years, there were a lot more type operators, mapped types, the infer keyword, etc. I feel it points to a direction: There is still a lot of existing JavaScript functions' type depend on the input which cannot be well-typed. For example, there are functions similar printf in most languages, or return type T when 0 is passed otherwise return type U. To satisfy those cases, we'll basically reinvent a whole new programming language in the type system - if the new language happens to be JavaScript itself it would be similar to other dependent type systems.

[edit, not quite what GP was referring to, but] At the minute, via [depending on context] a combination of generics/conditional types, unions/literals, type constructors, and [more recently] string templating you can get close in certain circumstances. It tends to be very fiddly though, and [IME] it's quite easy to cause TS to stop narrowing types properly. Someone else with more experience may be able to weight in -- despite using it for a few years I'd not really bothered to exercise some of the more expressive parts of the system until string templating experiments started popping up last year.

This issue thread on the TS repo may be of interest:

https://github.com/microsoft/TypeScript/issues/33014

The days I spent chasing implicits are still lost to me forever.

I always felt like implicits were a weaker design in the language, glad to see they put some more thought behind it.

Scala is one of the smallest typed languages in terms of syntax.

See slide 13: https://www.slideshare.net/Odersky/preparing-for-scala-3#13

With scala 3, syntax has been simplified even more, e.g.:

No more braces necessary. Top level declarations. Extension Methods.

That's an interesting take, as someone that's used Scala for a while I feel like there actually isn't that much syntax.

I guess my perception is warped :-)

There's some weird history there. For most of the project's existence, Scala 3 was known as Dotty. It was basically a research project, and it was recognized from the beginning that it was a different language than Scala, largely due to the type system semantics...the goal being a formally defined, fully sound type system (Scala had some edge cases that made it not sound, even if it was more sound than most languages).

However, the language resembled Scala, was created by the same person, had some cool capabilities that a lot of Scala users longed for, and it was a chance to "start over" with some of the more questionable design decisions that had been made previously, so there was a lot of questions and pressure to make it Scala 3.

So it was decided to no longer treat Dotty as a second language, but rather to find a path to migrate the existing Scala ecosystem to this new language. This transitioned the project from a relatively slow-paced research language into a full fledged and funded project with an urge for engineering not just tool and ecosystem compatibility, but also bytecode compatibility with Scala.

So for most of those 8 years, there was no objective but to create a better language than Scala. Then very rapidly (maybe the last two years), it went from "this is a completely new language" to "these language ideas will be incorporated into Scala 3", to "this will actually become Scala 3 and we're working on a transition path".

And from the perspective of someone who was aware of Dotty and a regular user of Scala, that felt like an extremely fast transition. Especially for a language that took years to make much smaller changes in the past (2.10->2.11->2.12 felt like an eternity).

It is.

Scala does not use semver. The last major release was 2.13.0, not 2.0.0. That's a bit confusing I guess.

What that means is, they haven't just added some features, they redesigned/rewrote to language from ground up to simplify it and make formally sound. I actually don't know any other language that does that (though I'm sure there are others, maybe Haskell is one of them).

In addition, a lot of features are very impactful and unprecedented, such as match types. To me, for a mainstream language (even though a smaller one), it certainly feels fast pasted.

I'm familiar with VS code and have a set up that I'm familiar with (shortcuts & settings) and I've only briefly looked at IntelliJ, so I'm not qualified to answer this question. What is the reason you're using IntelliJ rather than VS code?

Worksheets are a simple concept: you write lines of code in them, and the IDE runs the code automatically as you type, and displays the return value of each line. If you're familiar with the concept of Jupyter notebooks, it's a bit like that.

I tend to not view it as a replacement for an ordinary code file, but as a replacement for a REPL session. It has several advantages:

* Keeping track of your previous commands in a file is much more convenient than keeping track of it in your input history of the REPL.

* You can keep re-editing previous lines easily, and you can see the output of all lines.

* There is no hidden state (unlike a REPL). Everything is run from scratch every time.

* It's easier to define helper functions than in a REPL.

* It's easier to turn a worksheet into a unit test than it is to turn a REPL session into a unit test.

That said, it's also possible to start writing a module in a worksheet, and then turn it into an ordinary code file later.

Worksheets aren't perfect yet; I can think of many improvements, but they're already very useful to me. I think the end game will be to merge the concept of worksheet, unit test, debugger, printf debugging, and ordinary code file into one system, like Sean McDirmid's usable live programming research work (which in my opinion remains one of the most underrated research projects).

https://www.youtube.com/watch?v=01Xyoh-G6DE

The Scala/vscode story is pretty good now. [0]

[0] https://scalameta.org/metals/

It does work quite well with Scala 3.

I grinned a bit looking at that blog post and seeing how the highlighting of contributor names is completely messed up, presumably because of a bad regex.

Feels ironic, since Scala has a very advanced type system that would prevent such bugs, but the page contains the most classic issue of not handling non-ascii characters properly :)

I was waiting for this comment. Every single thread about Scala has someone pushing this narrative that Kotlin is the real arbiter of change when it really has been Scala the entire time pushing boundaries on the JVM.

Kotlin is great and if you want a cleaner Java experience, by all means use it but Scala is real champion in pushing many, many things into the mainstream.

Java has not picked up a single feature from Kotlin yet (maybe nullability types someday?), and, in fact, opted for very different ones (e.g. contrast records vs. data classes, virtual threads vs. syntactic couroutines), although I guess Scala has provided some inspiration for some features, as Java's are closer to Scala's than to Kotlin's. ML is probably the biggest influence, with some Haskell flavour. But I find it amusing that people think that Java is trying to compete with other languages on the Java platform, no matter how small, rather than with bigger, more relevant competitors.

Scala was probably the major factor here. However, the fact that Kotlin picked up these features from Scala (or at least inspired it) also proves that they are mature/stable and this has always been important for Java - so Kotlin did have an impact as well.

It doesn't matter "who did the trick". It is well known that Java was influenced by ideas in other programming languages from the beginning. And also other languages - including Scala and Kotlin - are similar in this respect... So yes: Kotlin influenced Java and Java influenced Kotlin. Let's compare final products with final products and not "how did we get there"...

Kotlin doesn't sound like a good language to bet on since most suitable(for jvm) features it has will be integrated by Java now that it has picked up pace.

I guess it only has decent marketshare because of google's android support(they are throwing stuff on the wall to move away from Oracle IP i guess) and Jetbrains being very popular among java devs.

Both are guest languages, Java owns the platform.

What did the trick are the other programming languages that can stand on their own as platforms.

How so? Kotlin doesn't even have proper pattern matching.

It could also be transitive: Scala inspired Kotlin and then Kotlin did the trick, I hope they could share the credit :)

> I like to refer to it as Haskell with an extra chromosome: slow, hard to comprehend, and incredibly strong.

that's a weird and offensive thing to say

It has one advantage compared to Haskell though: as a Java/Kotlin (or even Python or javascript) developer, you can start with it an be productive immediately. You can then slowly absorb new concepts until you are pretty much ready to write full-fledged Haskell.

That's why some call it Haskellator. :)

This also means that many codebases have different styles though, whereas in Haskell you have one style (FP).

Slow from a performance perspective, or to read and write code?

Or a lot less money :)