CoffeeScript was not only a great idea but also successful beyond its adoption. It influenced and inspired many features that JavaScript later incorporated, such as arrow functions and destructuring assignments.
Over time, JavaScript evolved to the point where the few quality of life improvements offered by CoffeeScript no longer justified learning an entirely new syntax.
I sometimes wonder if Kotlin will end up on the same trajectory. Java has added a lot of pretty good features since Kotlin first came on the scene, and the gap has narrowed considerably. The one thing enormous thing that Kotlin has that cannot be replicated easily in Java is null safety. But lately, most of the other features in Kotlin either make me long for something more powerful like Scala or shrug and just fall back to Java.
Admittedly, I don't do much Android development, and that was a big driver of Kotlin's adoption early on. So maybe it has more of a foothold there than on the server.
It will, because that is the fate of every guest language since the dawn of times.
The "systems" language of the platform, evolves with the platform, is designed alongside the platform.
The guest languages might be better than the platform's "systems" language, on the day of the release, eventually it is bound to diverge with its own library ecosystem built on top (because "ugh" we're not using the platform libraries directly), its own IDE tooling, its additional debugging layer due to platform interop, its own abstractions not native to the platform,.....
Eventually it naturally diverges as the platform takes incompatible decisions,...
C and C++ on UNIX, JavaScript and anything compiles to JS, Java vs Groovy/Scala/Clojure/Kotlin/jTCL/Beanshell/jython/...., C# vs VB.NET/F#/C++/CLI/IronPython/IronRuby,...
The guest languages that are survive, are those that move beyond the platform that gave them birth and create a platform of their own.
In Kotlin's case that is definitely Android, because Android team is doing everything at their disposal to make Java a 2nd class language on Android, rewriting Jetpack libraries in Kotlin, requiring Kotlin for Compose, showing off Kotlin code samples against Java 8 examples(!), I bet they only starting updating Java support, because Android was starting to lose too many Java libraries as the Java ecosystem adopts new versions.
Still, Android 15 being released one year later from Java 21 LTS, is still catching up with Java 17 LTS, introduced in Android 13 and not yet fully implemented, kind of proves the point of them not being in a hurry for proper Java support on the platform.
And beyond this, there’s very much a world where a few key people don’t discover Jeremy Ashkenas’ work - much of which, between CoffeeScript and Backbone, was the excitement that you could make JS feel agile - at the right time in their careers to push the industry in the direction where frontend developers become frontend engineers. We owe so much to these stepping stones.
Well, yeah that was expressly known about CoffeeScript. It pushed JS to the future and was expected to be not useful whenever JS gained more features, but that would take a long time. And some of the syntax features weren't adopted, which meant CoffeeScript seems like a different thing from JS but it wasn't intended to be a departure or permanent.
But JS moved faster and babel was made and eventually we could use JS-future even when browsers hadn't updated yet and CoffeeScript wasn't needed. But it was pretty easy to translate it to JS, commit that and keep rolling. CS was great at the time.
Over time, JavaScript evolved to the point where the few quality of life improvements offered by CoffeeScript no longer justified learning an entirely new syntax.