4 ms·

> Sometimes, the tooling is even more important than language features IMO. It makes developers move quicker, find bugs easier and so on. I like the idea of Kot

> Sometimes, the tooling is even more important than language features IMO. It makes developers move quicker, find bugs easier and so on. I like the idea of Kotlin, that it can compile to jvm bytecode, javascript and native. The only thing I'd worry about is Java overtaking it. Do you remember Coffeescript? There was a point in time where it had impressive adoption, and quite a bit of buzz. But then Javascript added features, and all of a sudden the tooling burden associated with Coffeescript just didn't make sense any more. With Oracle's 6 month release schedule, that's a distinct possibility. Especially since Java can no longer rest on its laurels as a language (if Oracle doesn't want it to become Cobol 2).

draw_down 4y ago
ajkjk 4y ago
Wasn't it Typescript that made CoffeeScript obsolete? Not better JS
- tentacleuno 4y ago
  Really, it was a combination of both.
- Betelgeuse90 4y ago
  IIRC the main appeal of CoffeeScript was syntactic sugar like lambda expressions etc that were missing in ECMAScript 5. I think ECMAScript 6 made most of the appeal of CoffeeScript obsolete
  - jgalt212 4y ago
    The availability of lodash made us dump any ideas our shop had about widespread coffeescript use.
  - tinco 4y ago
    When CoffeeScript came out, I vowed never to write plain Javascript again. I kept to that vow for a couple years, but eventually broke it when ECMA 6 came out. Really the only thing that put real technical justification behind CoffeeScript was the double arrow function, and maybe the neat class syntax. Beyond that CoffeeScript is just prettier. Even though I was in charge of choosing the technologies, you got to skate where the puck is going, and the puck was clearly not staying with CoffeeScript. ECMA 6 copied all the good parts out of both CoffeeScript and jQuery, effectively obsoleting both. Modern JavaScript is almost unrecognisably different from what it used to be, and that's a very good thing.
- sergiotapia 4y ago
  You are correct. Typescript killed any momentum coffeescript had.
- smt88 4y ago
  CoffeeScript never became popular in the first place. I stopped seeing it anywhere even before TypeScript caught on.
  - hinkley 4y ago
    I ran into Coffeescript code on GitHub for the first time in years last week. Oh, Coffeescript, I remember that used to be a thing.
  - MajimasEyepatch 4y ago
    It was a thing for a hot minute in the early 2010s, before ES6, TypeScript, and the React/Angular/Vue trifecta came along and solidified what JavaScript would be from ~2015 onwards.
  - treis 4y ago
    It was the default for a while for Rails apps and Wiki tells me GitHub & Dropbox adopted it before moving to Typescript. I think for Rails shops it was popular and there was a brief time where it looked like it might become the thing to do on the front end. But I don't think it ever got the interop with existing JS right. Ultimately, improvements to JS came along and took the wind out of CoffeeScript's sails. Then TypeScript came along and killed whatever interest remained.
- yamtaddle 4y ago
  "Our codebase is in CoffeeScript" tended to draw grimaces for years before Typescript came around. And no, they serve totally different purposes. Coffeescript tried to make JS syntax and variable scoping behavior non-shit, while Typescript adds static typing while changing very little about the core language syntax.
ohgodplsno 4y ago
Kotlin is plenty safe for now. * Android is a massive platform, and Android is basically stuck on JDK8 (or JDK11 with desugaring, wooo). * iOS compatibility-ish. KMM is not ideal and mostly generates ObjC compatible objects (so generics are mostly screwed for Swift and writing iOS code is not ideal, but even being able to define common and enforced contracts is cool. iOS benefiting from projects like SQLDelight is super cool) * Jetbrains hedged their bets, and Kotlin/Multiplatform is a solid option. Coupled with Jetbrains Compose for UIs as well as having the entire Java ecosystem available is very solid. Compilation for so many platforms, directly to native executables is cool. * Java is still very slow to evolve. Kotlin has had data classes for a long time, Java recently added records. Inline classes offer some nice type safety at basically zero costs. Coroutines and structured concurrency are a beautiful way to work, and Project Loom would only build the foundations of that. Context extensions (while terrifying in the potential for spaghetti code they offer) are a useful feature, reified generics have some great potential. Now, Kotlin has its disadvantages too. Compilation times are not that great (hopefully K2 fixes this partly), but it's relatively safe and is kind of more than just a JVM language by now.)
- mbStavola 4y ago
  I agree with everything you said except for "Java is still very slow to evolve." New Java versions are cut every six months since 2017 and since then has added a significant amount of new features, syntactical sugar, APIs, et cetera. Not only that, but they've also have been pretty aggressive IMO in deprecating and removing legacy. Very very different than the Java I remember working in years ago.
  - weego 4y ago
    You're correct of course, but to back up the parents comment, they do have a habit of implementing things other than the low hanging fruit that developers are frustrated not having, leading the drive towards other jvm langs
    - mbStavola 4y ago
      What are some examples of those low hanging fruits?
valenterry 4y ago
Yes that's right. In fact, Kotlin really works well with the IDE. But they didn't spend as much time in creating a language with a good and sound theoretical foundation. This works in the short time but shows its flaws later. Java is a bit better here (but quite slow though). So yeah, I can see Java potentially overtaking Kotlin.
commitpizza 4y ago
This kind of happened to Groovy, but I think Kotlin was the killer in that case.
- JAlexoid 4y ago
  Groovy was too much of a "scripting feel" to it, maybe because the primary project was Gradle. Scala had a massive much more prominent project to rely on - Spark. Kotlin is getting traction because of Android.
  - RhodesianHunter 4y ago
    > Kotlin is getting traction because of Android. Kotlin is seeing major adoption on the server.
zendist 4y ago
I don't know about that comparison. CoffeeScript transpiled to JavaScript- Kotlin doesn't transpile to Java, it compiles to JVM bytecode. So in a sense, from a tooling and compiler perspective, they're orthogonal products, similar (I guess) to C# and F# on the .NET CLR VM.
jillesvangurp 4y ago
Don't forget about WASM as another platform; it's coming as well. An experimental version actually ships with 1.7; it's just a bit unstable and under documented and very much a work in progress. I think Oracle is catching up slower than Kotlin has been evolving in terms of new language features. Most of the stuff they add to Java (including most of the stuff they are talking about adding), Kotlin has been doing for quite some time. Kotlin is pushing out minor releases about every 3-4 months and major ones pretty much every year. Basically, they do 2-3 minor versions in between major ones. The pace is relentless. If anything, Kotlin could use an LTS release because it's actually getting hard to keep up with the ecosystem. A slower pace might be helpful with that. The main issue with frequent releases is that many libraries take weeks or even months to update and don't necessarily work well (or at all) with newer Kotlin versions. I've had repeated issues with e.g. code generation plugins requiring specific version of Kotlin breaking because some other library suddenly requiring something newer. So that then starts blocking a lot of library updates. We've actually put some effort in unblocking some of this for some of the dependencies we have by creating pull requests. But I'm excited about the next 1-2 years. I expect Kotlin native to stabilize and grow beyond just being a thing for IOS. I also expect wasm support will become usable in that time frame. I hope to be able to use it with WASI for edge networking or serverless stuff. And maybe even some command line tools. IMHO Kotlin has potential for data engineering as well. There is actually jupyter support for Kotlin. And some machine learning frameworks. It's becoming a proper full stack language.

draw_down 4y ago

ajkjk 4y ago

Wasn't it Typescript that made CoffeeScript obsolete? Not better JS

tentacleuno 4y ago
Really, it was a combination of both.
Betelgeuse90 4y ago
IIRC the main appeal of CoffeeScript was syntactic sugar like lambda expressions etc that were missing in ECMAScript 5. I think ECMAScript 6 made most of the appeal of CoffeeScript obsolete
- jgalt212 4y ago
  The availability of lodash made us dump any ideas our shop had about widespread coffeescript use.
- tinco 4y ago
  When CoffeeScript came out, I vowed never to write plain Javascript again. I kept to that vow for a couple years, but eventually broke it when ECMA 6 came out. Really the only thing that put real technical justification behind CoffeeScript was the double arrow function, and maybe the neat class syntax. Beyond that CoffeeScript is just prettier. Even though I was in charge of choosing the technologies, you got to skate where the puck is going, and the puck was clearly not staying with CoffeeScript. ECMA 6 copied all the good parts out of both CoffeeScript and jQuery, effectively obsoleting both. Modern JavaScript is almost unrecognisably different from what it used to be, and that's a very good thing.
sergiotapia 4y ago
You are correct. Typescript killed any momentum coffeescript had.
smt88 4y ago
CoffeeScript never became popular in the first place. I stopped seeing it anywhere even before TypeScript caught on.
- hinkley 4y ago
  I ran into Coffeescript code on GitHub for the first time in years last week. Oh, Coffeescript, I remember that used to be a thing.
- MajimasEyepatch 4y ago
  It was a thing for a hot minute in the early 2010s, before ES6, TypeScript, and the React/Angular/Vue trifecta came along and solidified what JavaScript would be from ~2015 onwards.
- treis 4y ago
  It was the default for a while for Rails apps and Wiki tells me GitHub & Dropbox adopted it before moving to Typescript. I think for Rails shops it was popular and there was a brief time where it looked like it might become the thing to do on the front end. But I don't think it ever got the interop with existing JS right. Ultimately, improvements to JS came along and took the wind out of CoffeeScript's sails. Then TypeScript came along and killed whatever interest remained.
yamtaddle 4y ago
"Our codebase is in CoffeeScript" tended to draw grimaces for years before Typescript came around. And no, they serve totally different purposes. Coffeescript tried to make JS syntax and variable scoping behavior non-shit, while Typescript adds static typing while changing very little about the core language syntax.

ohgodplsno 4y ago

Kotlin is plenty safe for now. * Android is a massive platform, and Android is basically stuck on JDK8 (or JDK11 with desugaring, wooo). * iOS compatibility-ish. KMM is not ideal and mostly generates ObjC compatible objects (so generics are mostly screwed for Swift and writing iOS code is not ideal, but even being able to define common and enforced contracts is cool. iOS benefiting from projects like SQLDelight is super cool) * Jetbrains hedged their bets, and Kotlin/Multiplatform is a solid option. Coupled with Jetbrains Compose for UIs as well as having the entire Java ecosystem available is very solid. Compilation for so many platforms, directly to native executables is cool. * Java is still very slow to evolve. Kotlin has had data classes for a long time, Java recently added records. Inline classes offer some nice type safety at basically zero costs. Coroutines and structured concurrency are a beautiful way to work, and Project Loom would only build the foundations of that. Context extensions (while terrifying in the potential for spaghetti code they offer) are a useful feature, reified generics have some great potential. Now, Kotlin has its disadvantages too. Compilation times are not that great (hopefully K2 fixes this partly), but it's relatively safe and is kind of more than just a JVM language by now.)

mbStavola 4y ago
I agree with everything you said except for "Java is still very slow to evolve." New Java versions are cut every six months since 2017 and since then has added a significant amount of new features, syntactical sugar, APIs, et cetera. Not only that, but they've also have been pretty aggressive IMO in deprecating and removing legacy. Very very different than the Java I remember working in years ago.
- weego 4y ago
  You're correct of course, but to back up the parents comment, they do have a habit of implementing things other than the low hanging fruit that developers are frustrated not having, leading the drive towards other jvm langs
  - mbStavola 4y ago
    What are some examples of those low hanging fruits?

valenterry 4y ago

Yes that's right. In fact, Kotlin really works well with the IDE. But they didn't spend as much time in creating a language with a good and sound theoretical foundation. This works in the short time but shows its flaws later. Java is a bit better here (but quite slow though). So yeah, I can see Java potentially overtaking Kotlin.

commitpizza 4y ago

This kind of happened to Groovy, but I think Kotlin was the killer in that case.

JAlexoid 4y ago
Groovy was too much of a "scripting feel" to it, maybe because the primary project was Gradle. Scala had a massive much more prominent project to rely on - Spark. Kotlin is getting traction because of Android.
- RhodesianHunter 4y ago
  > Kotlin is getting traction because of Android. Kotlin is seeing major adoption on the server.

zendist 4y ago

I don't know about that comparison. CoffeeScript transpiled to JavaScript- Kotlin doesn't transpile to Java, it compiles to JVM bytecode. So in a sense, from a tooling and compiler perspective, they're orthogonal products, similar (I guess) to C# and F# on the .NET CLR VM.

jillesvangurp 4y ago

Don't forget about WASM as another platform; it's coming as well. An experimental version actually ships with 1.7; it's just a bit unstable and under documented and very much a work in progress. I think Oracle is catching up slower than Kotlin has been evolving in terms of new language features. Most of the stuff they add to Java (including most of the stuff they are talking about adding), Kotlin has been doing for quite some time. Kotlin is pushing out minor releases about every 3-4 months and major ones pretty much every year. Basically, they do 2-3 minor versions in between major ones. The pace is relentless. If anything, Kotlin could use an LTS release because it's actually getting hard to keep up with the ecosystem. A slower pace might be helpful with that. The main issue with frequent releases is that many libraries take weeks or even months to update and don't necessarily work well (or at all) with newer Kotlin versions. I've had repeated issues with e.g. code generation plugins requiring specific version of Kotlin breaking because some other library suddenly requiring something newer. So that then starts blocking a lot of library updates. We've actually put some effort in unblocking some of this for some of the dependencies we have by creating pull requests. But I'm excited about the next 1-2 years. I expect Kotlin native to stabilize and grow beyond just being a thing for IOS. I also expect wasm support will become usable in that time frame. I hope to be able to use it with WASI for edge networking or serverless stuff. And maybe even some command line tools. IMHO Kotlin has potential for data engineering as well. There is actually jupyter support for Kotlin. And some machine learning frameworks. It's becoming a proper full stack language.