6 ms·

The golden age of Kotlin and its uncertain future

48 points by philonoist 3y ago

phendrenad2 3y ago
To me, Kotlin is so similar to Java that it might just survive in the way that Elixir and Erlang coexist.
- nsonha 3y ago
  yes, even years ago before 1.0, Kotlin blended in with existing Java code pretty well, it's not that big a learning curve and adds a really nice std lib on top of Java. So I don't really relate to the framing that it competes with modern Java.
dehrmann 3y ago
The future is very certain. Mainline Java has been cherry picking the best features from these languages after there's sufficient traction and the issues have already surfaced. Since the tooling has to support both Java and some other contender, Java always gets first-class support. Using any of the alternative JVM languages (except maybe Clojure) gives you better syntax, somewhat better abstractions for a few years, and worse tooling. And syntax is overrated. Java might be verbose, but it's well-understood, and it's not actually what slows development.
- voidfunc 3y ago
  This. I love the Kotlin language but Java had just caught up and the things that made Kotlin super exciting several years ago are less exciting now as Java advanced. Also I looked back at Kotlin recently and things have gotten way more complex than I remember around 1.0. Kotlin needed to succeed on the native front to live beyond Java. It didn't and that puts it in a perilous long-term spot.
  - MrBuddyCasino 3y ago
    The one major thing Kotlin still has going for it is null safety, and IMO it eclipses every other „nice“ feature. But Java will get this too, and then I‘m not sure I can justify using it. Oh and I wish Java would support „it“ in lambdas, very useful.
    - cryptos 3y ago
      Java will not have the same level of null safety as Kotlin. Instead Types can be explicitly marked as "not null", so the default is still that every reference type can be null.
      - MrBuddyCasino 3y ago
        Yes unfortunately, but I mostly miss null safety in domain classes, not in the stdlib. It remains to be seen if this is "good enough" or not.
    - brabel 3y ago
      Will Java have null-safety?? Can you link to that, I haven't heard anything at all about this.
      - MrBuddyCasino 3y ago
        See "Use of null-restricted types" which is part of Project Valhalla[0], the proposed syntax is the opposite of Kotlin, where everything is non-null by default but can be made nullable by adding a "?", eg "val s: String? = null". The Java version instead looks like this, where you add an exclamation mark to mark it as non-nullable: class Cursor { private Point! position; } [0] https://bugs.openjdk.org/browse/JDK-8251554 https://bugs.openjdk.org/browse/JDK-8251554
        brabel 3y ago
        Ok, but notice that's not about making Java null-safe in any sense. It's about making "value types" (which will be introduced by Project Valhalla) possibly non-null, mostly for optimization purposes (though it should also benefit programmers reason about value types if they can't be null). As mentioned in the relevant JEP[1]: "A null-restricted type is a reference type expressed with the name of a value class followed by the ! symbol." Goals: "Allow a value class to "opt in" to the automatic creation of an appropriate default value used to initialize fields and arrays that don't store null." Non-goals: "It is not a goal to support null-restricted types for identity classes or classes that do not provide a default value." So, I don't see how that's in any way going to threaten Kotlin's position as a null-safe language - Java will almost certainly always have "unsafe" `null`, removing it from Java seems simply impossible at this point (notice that Dart managed to do it, but it had a much, much smaller ecosystem than Java, and even then, it required multiple years of migration of every single Dart package in Pub - and the ones that were unmaintained were simply abandoned and no longer work with the latest versions of Dart which is fully null-safe). [1] https://openjdk.org/jeps/8316779 https://openjdk.org/jeps/8316779
- pharmakom 3y ago
  Syntax may be overrated but expressiveness is not.
- pkphilip 3y ago
  Yep, all true. These days Java isn't slow to develop on at all. There are plenty of very good frameworks where you can get going with developing a web app or rest service in next to no time with far better tooling support, sophistication etc. .NET is a serious contender though. Node isn't really on the same ballpark in terms of maturity.
  - ShadowBanThis01 3y ago
    Not to mention that Node isn't a language, and Deno is cleaner.
    - pkphilip 3y ago
      I was referring to Java as a platform rather than just as a language. .NET isn't a language either
      - ShadowBanThis01 3y ago
        Indeed, but I only wanted to include so much pedantry!
  - DeathArrow 3y ago
    >.NET is a serious contender though. It the other way around. Java has barely caught up with C#. C# team is typically introducing more features, faster.
    - royjacobs 3y ago
      I'm not sure language design should be a race to see who can add the most features, though. I prefer Java's more thoughtful approach to introducing new features.
      - keithnz 3y ago
        in what way do you think it's more thoughtful than C#?
- hitekker 3y ago
  > Java might be verbose, but it's well-understood, and it's not actually what slows development. I think you're onto something. Maybe some Java-by-default workplaces lack technically interesting problems that engineers want to solve, so those engineers instead overfocus on the frictions of the parts they can control. Maybe those engineers desire expressiveness in their working programming language to compensate for the restrictions on the rest of their work. Just a hunch though.
  - deleted 3y ago
    [deleted]
  - throwaway13623 3y ago
    I think you may have a point. At mature companies, they have largely solved the product market fit and uses a stable stack that just works. I have worked worked for such companies, and developers jumped at the chance to use the latest (untested) technologies for greenfield projects if they had the chance. In my startup we also use a "boring" stack, but the problems we solve are innovative and motivation in itself. The developers work closely with customers and can see the impact that the product has. They are no longer working in a Jira-factory and while they are still interested in technology they also find motivation in the product itself.
- esafak 3y ago
  Kotlin has great tooling, and Java library compatibility, so why wouldn't you use it? When you work in Kotlin, you give the masses of Java programmers the ability to contribute and a licence to check their EnterpriseGradeFizzBuzzSolutionStrategyFactory mentality at the door. Do Java projects in industry even use the new stuff? Also, you can use virtual threads with coroutines.
  - happymellon 3y ago
    I'm allowed to use Streams but var isn't because it makes GitHub PRs difficult to parse. We got to upgrade from Java 8 to Java 17 in 2023.
    - throwaway13623 3y ago
      I've worked in "enterprise" and have a different experience. The enterprise projects that I was working on switched to Java 8 in 2015. There were some legacy services that remained on 5 or 6 for a while, but they were mostly in "maintenance" mode and nobody wanted to spend time on them. I have over two decades of experience and there has always been room for trying out the "new" technologies and keeping up with the latest best practices, even in enterprise. I know that not everyone has this experience, but there are actually a lot that happens outside slow big American legacy companies... In my current startup we use the latest JVM and have a mix of Java and Kotlin. It works really well and we have never experienced any problems with development speed that was related to code or language syntax. JVM + Spring boot + Postgres may be the "boring" choice, but it has enabled us to focus on getting things done and focusing on the product. It didn't take long for juniors to be productive in our stack either. Spring itself looks a bit scary at first sight, but once you learned the basic philosophy you have less issues than a Node project in my experience. I know that my experience may not match your experience, so I recognize that I can't make a generic statement. It's just a bit frustrating to see similar statements made by people with bad experiences. - Not all Java development happens in enterprise. There is a thriving eco system of small to middle sized companies and startups using Java - Not all enterprises are the same. I've actually noticed a shift to the other extreme, where enterprise uses the latest technologies to attract new employees. Nobody who has a choice wants to work with factory patterns on an old version of Java - Old Java patterns like factories and extreme use of inheritance is out of fashion. There is of course a lag like in any trends, but remember that Java is so widely used so you will always find companies that are slow to adopt, or have legacy software that is in maintenance mode.
- gleenn 3y ago
  Clojure is such a joy to use. I get the maturity of the Java ecosystem and the immutability, functional style, and concision of a lisp. If performance really matters, and Clojure does perform well, you can always dive into stuff with all the Java tooling and interop is extremely easy. I really wish more people picked it up.
  - cryptos 3y ago
    I feel no desire to use dynamic typing again, as nice as Clojure might otherwise be. While Kotlin is not strictly immutable, it is much better in this regard than Java. Collections are immutable by default in Kotlin (or more precisely you get an immutable view defined by the respective interface) and that is quite useful in practice.
- switch007 3y ago
  Will they cherry pick Kotlin’s null safety…?
  - cryptos 3y ago
    No, they will allow to mark types as explicitly not null (the other way around). The default in Java will still be that everything can be null.
- sho 3y ago
  > syntax is overrated Speak for yourself there good buddy. It's pretty important to me! But I do agree with your broader point. From one perspective, Kotlin has been a great success if we define its mission as a test-bed and laboratory for improving Java proper. Unfortunately, while it has arguably succeeded in that mission, in doing so it might unavoidably fail in another mission, which is to thrive as an independent language. I'd liken it to yarn and npm. Yarn was a huge success.. at forcing npm to massively improve and thus basically rendering itself irrelevant. A bittersweet success, but a success nonetheless.. I wonder if there's a term for this kind of self-sacrificial project which makes the world better for having existed but doesn't survive the process..
dave4420 3y ago
Scala isn’t dead. I’m job hunting right now, and seeing plenty of Scala jobs. Not as many as Node+TS+React, but what do you expect?
- guytv 3y ago
  "Scala isn't dead" reminded me of this one "No no he's not dead, he's, he's restin'!": https://www.youtube.com/watch?v=vZw35VUBdzo https://www.youtube.com/watch?v=vZw35VUBdzo
- threeseed 3y ago
  It also benefits from being one of the only full-stack languages. Scala.js has excellent front-end frameworks like Slinky React [1], Laminar [2] and Scala has industry-leading concurrency libraries like ZIO [3]. I've yet to find anything that comes close for end to end web apps. [1] https://slinky.dev https://slinky.dev [2] https://laminar.dev https://laminar.dev [3] https://zio.dev https://zio.dev
- DeathArrow 3y ago
  >Scala isn’t dead. Scala isn't dead. It went to play between the stars with Pearl and Ruby.
- 62951413 3y ago
  If you subtract Spark/Flink-related ones not really. Plenty only in comparison with Kotlin backend roles (i.e. non-existent in the Bay Area). It's very disappointing to me personally but it is what it is.
r1jsheth 3y ago
one thing i definitely liked about kotlin was reduced verbosity. otherwise all the other points, you made me ponder a bit. let's see where kotlin goes.
kmonsen 3y ago
Maybe in the backend but for mobile (android) kotlin is still a thing and will be for a long time.
FlyingSnake 3y ago
There are two problems Kotlin faces; Kotlin the project/product and Kotlin the language. While this article touches Kotlin as a Product, it’s very thin on the Language aspect. Here’s an old post discussing the real troubles Kotlin Lang might face due to the inevitable divergence of Java/JVM. https://np.reddit.com/r/java/comments/ndwz92/can_i_get_some_reasons_to_use_java_instead_of/gyd5yi5/ https://np.reddit.com/r/java/comments/ndwz92/can_i_get_some_...
- nealliu 3y ago
  Make sure you read the reply a few comments down from the original post, it invalidates much of the op.
  - FlyingSnake 3y ago
    True, the old article had some nice rebuttals. I wonder how many of these predictions came out to be true so far.
ShadowBanThis01 3y ago
"FAANG has first-class support and commitments to Java" Nobody told Apple that.
- Dig1t 3y ago
  Apple has an incredible amount of Java running server side, and they maintain their own JVM/tooling. Support on Mac is admittedly not the best though.
cryptos 3y ago
> Null was always a pitfall in Java. It has slightly improved with the controversial Optional type. It’s also why I suggest that everyone use only wrapper types everywhere, instead of primitives, unless they can prove with a JMH test that a primitive provides enough of a performance benefit. That doesn't make sense at all! Why should one do it without a need? To have NullPointerException with "primitive" types, too? > Kotlin ecosystem is severely lacking compared to Java. FAANG has first-class support and commitments to Java, like providing JDK with multi-year support commitments. It is not really needed to provide JDKs or something else especially for Kotlin, because Kotlin basically just uses the JVM (at least if you use the JVM as a target). > To this day, there are significantly fewer Kotlin developers than Java developers. Yes, that is probably true. Although almost every Android developer should know Kotlin these days and there are quite a few them. But even if a developer doesn't know Kotlin at all, it is relatively easy for a Java developer to learn it. In my experience it a takes a few days to a few weeks to be at least as productive as with Java (even not all Kotlin features are learnt in this time). > Lack of progress: Compared to Java lately (e.g., records two years ago, pattern matching, and VT release this year), Kotlin has been stagnating in delivering the big features that would bring us (Infobip) value over alternatives. Here, I agree. Some years ago I was super excited about Kotlin and couldn't wait for a new release. These days new releases are mostly boring. Maybe the most important stuff is simply done, but then there are enough interesting ideas to improve it (real pattern matching, meta programming, union types, ...). But JetBrains and Google decided that it is more important to improve the fundamental infrastructure first and decided to create a new, faster compiler (K2). As boring at it is feature-wise, I think it is a wise decision, because every project would benefit from it. The plan is to add new features, once the compiler is ready.
ShadowBanThis01 3y ago
Does the "pattern matching" referred to here work like JavaScript's "destructuring?" It's the thing where you can call a function with an object, but the function's parameters extract one or more of the object's members directly without mentioning the object's class, so it'll take anything that has appropriately named members.
- nsonha 3y ago
  no, pattern matching is more like destructuring AS CONDITIONS (eg: if object has this structure) of switch blocks. While destructuring is simply sugar for assignment, pattern matching is more complex. I don't know about Java but in some languages you can customize the pattern so that it is not neccessarily in the actual shape of the object. In some languages applying pattern matching at the top level of the function is the equivalence of overloading.
  - ShadowBanThis01 3y ago
    Thanks! Intuitively this sounds like it enables what at one time would have been called bad programming (widespread reliance on RTTI), but on the other hand a lot of rules have turned out to be arbitrary.
- DeathArrow 3y ago
  I think they've partly implemented C# version of pattern matching.
wiseowise 3y ago
What a low quality article. Language is more just a set of features. Anyone who tried both Java and Kotlin for reasonable amount of time will understand that. Regardless of how many features Java adopts from Kotlin or other modern language it will still remain shackled by billions of lines of legacy code and boilerplate consequently. The only one who might like the article is self-conscious Java developer who wants to feel good by bashing on competing language. Wish it wasn’t morning so I could elaborate on every point. Might reply later to this comment.
jillesvangurp 3y ago
The future is always a bit uncertain. But Kotlin's future actually looks pretty good to me. This article looks like the author is not really clued in to the massive amount of progress and change happening especially in the last year. There's nothing wrong with being a bit old an conservative and stuck in your Java ways. Been there done that and trying to be better than that now. But this article is just a bit overly dismissive and poorly argued. I'm biased of course having used Kotlin extensively for the last six years and having made the switch from Java. From my perspective It's simply a much better Java. And I have 25 years experience with that, mostly server side. And the way I'm using it, it's also a better Typescript for me. If you have trouble parsing that last bit, I'm using kotlin-js to develop frontend code. It's actually really nice for that even though not many people do this. Well worth a look if you are getting tired of dealing with Javascript's idiosyncrasies (which typescript inherits) and a bit jealous of what all the cool kids doing mobile applications are using. Which would be using fancy Kotlin and Swift UI frameworks mainly. Kotlin-js being nice to use should not be that surprising because of course a lot of Android developers use and love it and a lot of the libraries and practices port over very well to the web if you use kotlin-js. E.g. I use dependency injection (koin); which as it turns out is equally useful and nice to have in a browser as it is on Android and in Spring or other places. There are a few changes happening this year with Kotlin that are exciting for Kotlin users and interesting for people not yet using it: - Kotlin native is stabilizing. It now works well on IOs, Android, Linux, Windows, and MacOS. It's not "just another jvm language" anymore. The multiplatform library ecosystem is really starting to thrive. Lots of growth there. Especially in the last year. And I maintain a few myself. - The web assembly compiler is now available in an alpha version and browser support for garbage collection in WASM just rolled out in Firefox and Chrome a few months ago. This is required by Kotlin's wasm support as it does not bundle its own garbage collector. Safari should follow soon/eventually. This means you can now use kotlin-wasm in a browser without having to fiddle with feature flags in your browser. Multiplatform library support for this is still a bit a work in progress but most kotlin multi platform libraries should start having wasm targets in the next few months. Wasm works in servers and on servers, lambda functions, and edge networking. So, first class Kotlin support for wasm is a big deal and the whole kotlin multi platform library ecosystem is coming along. - Kotlin 2.0 is in Beta currently and should release in a few months (spring?). Kotlin native and wasm support and that are all happening at the same time and come on the tail end of a years long effort to re-engineer the compiler and IDE toolchain. Work on Kotlin 2.0 actually started about three or so years ago and it has included a gradual rewrite of the compiler through the 1.6-1.9 releases. - Building on all this is Compose multiplatform, which brings Google's Jetpack Compose to other platforms. That's currently stable for a few platforms, in alpha versions on others (like IOS and web). That's something that should stabilize towards the end of the year. We'll have a cross platform, natively compiling UI framework that is usable across web (wasm), IOS (native), Android (native) and the three Desktop platforms (jvm, for now). So, that could end up being a nice alternative to things like flutter and react-native. Or indeed to packaging up web applications as PWAs or using things like electron. It might not be everybody's cup of tea but that's a lot of progress that came together in the last year. I use other languages besides Kotlin. So, I can appreciate other languages as well. But Kotlin is just really nice.
bobm_kite9 3y ago
I'd love to see Java adopt Kotlin's more advanced type system: Proper support of nullable/non-nullable types, better generics and no primitives. Not sure how they could get there but that would be amazing. Also Kotlin has a pretty good JavaScript and Native support story now.
cetu86 3y ago
While the author dislikes extension functions in kotlin they enable one feature that Java doesn't have: With them you can create domain specific languages within kotlin that are quite ergonomic. - Jetbrains has built a nice reactive js wrapper with them. - The gradle configuration is written in a kotlin dsl. They can be used to specify configuration and add meta information and thus replace Java annotations. That is my kotlin "killer" feature because I personally don't like annotations. Java's language design has always been "pedagogical" (or patronizing) to not give the developer to much power to create to much abstractions and complexity. So it's not just its age but also this philosophy that has made Java a rather inelegant language ( compared with e.g. kotlin)
dingi 3y ago
As I see, the only purpose of Kotlin is a be test bed for novel features to JVM based languages. And eventually Java is going to integrate those features better than Kotlin. And Kotlin's advantages are gone like that. To be honest, I have never seen Kotlin used in environments other than Android. The day Google decides to move Android development to another language will be the day Kotlin dies. Or becomes a zombie.
- DeathArrow 3y ago
  >And eventually Java is going to integrate those features better than Kotlin Kotlin has better syntax and is less verbose. That matters for a lot of developers. Kotlin deals with null in a better way. Kotlin has better types.
- throwaway13623 3y ago
  > I have never seen Kotlin used in environments other than Android I have seen several companies that use Kotlin as a backend language (often with Spring). I personally don't find the differences enough to bother switching from Java, but I also don't mind working with Kotlin in existing projects.
nbittich 3y ago
I agree, I remember learning Ceylon few years ago in the metro while going at work, now it is probably one of the rarest programming language that we can say for sure it's dead (has been archived few years ago iirc).
stefs 3y ago
in my opinion, modern java's language ergonimics are good but kotlin is still far better. i didn't write much plain java in long time since having to adopt kotlin. i love the integrated null safety / handling at a syntax level with the ? operator; optional felt clunky in comparison. lambdas plus everthing's an expression allows for concise, readable code. and i love the scope functions. i agree that extension methods may have turned out to be a footgun, but i feel like it hasn't been a huge issue in the field. it's doubtful java is able to integrate most of those ideas in a way that feels as natural. i don't understand why the author chose to ignore android, it's an elephant in this room. as long as android doesn't drop kotlin for something else as the lingua franca of the platform it's got certain guarantees.
- willtemperley 3y ago
  Absolutely, while Kotlin is a first class citizen in Android, it isn't going away. Neither is Scala because there are plenty of developers who like bleeding-edge and experimental language features. Personally I don't use it anymore as really don't need things like implicit parameters, but props to each and every early adopter of language features that help Java evolve. Thanks to Kotlin and Scala, Java can now be very pleasant to code in.
mustermannBB 3y ago
My only issue with Kotlin is Kotlin's over reliance on JetBrain products and being so tightly tied to a company which priority it is to of course sell their IDE. To be fair, one of course use the free community edition but still you kinda need a JetBrain product to ensure you getting the most out the language. With language servers these days, that feels like it is going the opposite direction.

48 points by philonoist 3y ago

phendrenad2 3y ago

To me, Kotlin is so similar to Java that it might just survive in the way that Elixir and Erlang coexist.

nsonha 3y ago
yes, even years ago before 1.0, Kotlin blended in with existing Java code pretty well, it's not that big a learning curve and adds a really nice std lib on top of Java. So I don't really relate to the framing that it competes with modern Java.

dehrmann 3y ago

The future is very certain. Mainline Java has been cherry picking the best features from these languages after there's sufficient traction and the issues have already surfaced. Since the tooling has to support both Java and some other contender, Java always gets first-class support. Using any of the alternative JVM languages (except maybe Clojure) gives you better syntax, somewhat better abstractions for a few years, and worse tooling. And syntax is overrated. Java might be verbose, but it's well-understood, and it's not actually what slows development.

voidfunc 3y ago
This. I love the Kotlin language but Java had just caught up and the things that made Kotlin super exciting several years ago are less exciting now as Java advanced. Also I looked back at Kotlin recently and things have gotten way more complex than I remember around 1.0. Kotlin needed to succeed on the native front to live beyond Java. It didn't and that puts it in a perilous long-term spot.
- MrBuddyCasino 3y ago
  The one major thing Kotlin still has going for it is null safety, and IMO it eclipses every other „nice“ feature. But Java will get this too, and then I‘m not sure I can justify using it. Oh and I wish Java would support „it“ in lambdas, very useful.
  - cryptos 3y ago
    Java will not have the same level of null safety as Kotlin. Instead Types can be explicitly marked as "not null", so the default is still that every reference type can be null.
    - MrBuddyCasino 3y ago
      Yes unfortunately, but I mostly miss null safety in domain classes, not in the stdlib. It remains to be seen if this is "good enough" or not.
  - brabel 3y ago
    Will Java have null-safety?? Can you link to that, I haven't heard anything at all about this.
    - MrBuddyCasino 3y ago
      See "Use of null-restricted types" which is part of Project Valhalla[0], the proposed syntax is the opposite of Kotlin, where everything is non-null by default but can be made nullable by adding a "?", eg "val s: String? = null". The Java version instead looks like this, where you add an exclamation mark to mark it as non-nullable: class Cursor { private Point! position; } [0] https://bugs.openjdk.org/browse/JDK-8251554 https://bugs.openjdk.org/browse/JDK-8251554
      - brabel 3y ago
        Ok, but notice that's not about making Java null-safe in any sense. It's about making "value types" (which will be introduced by Project Valhalla) possibly non-null, mostly for optimization purposes (though it should also benefit programmers reason about value types if they can't be null). As mentioned in the relevant JEP[1]: "A null-restricted type is a reference type expressed with the name of a value class followed by the ! symbol." Goals: "Allow a value class to "opt in" to the automatic creation of an appropriate default value used to initialize fields and arrays that don't store null." Non-goals: "It is not a goal to support null-restricted types for identity classes or classes that do not provide a default value." So, I don't see how that's in any way going to threaten Kotlin's position as a null-safe language - Java will almost certainly always have "unsafe" `null`, removing it from Java seems simply impossible at this point (notice that Dart managed to do it, but it had a much, much smaller ecosystem than Java, and even then, it required multiple years of migration of every single Dart package in Pub - and the ones that were unmaintained were simply abandoned and no longer work with the latest versions of Dart which is fully null-safe). [1] https://openjdk.org/jeps/8316779 https://openjdk.org/jeps/8316779
pharmakom 3y ago
Syntax may be overrated but expressiveness is not.
pkphilip 3y ago
Yep, all true. These days Java isn't slow to develop on at all. There are plenty of very good frameworks where you can get going with developing a web app or rest service in next to no time with far better tooling support, sophistication etc. .NET is a serious contender though. Node isn't really on the same ballpark in terms of maturity.
- ShadowBanThis01 3y ago
  Not to mention that Node isn't a language, and Deno is cleaner.
  - pkphilip 3y ago
    I was referring to Java as a platform rather than just as a language. .NET isn't a language either
    - ShadowBanThis01 3y ago
      Indeed, but I only wanted to include so much pedantry!
- DeathArrow 3y ago
  >.NET is a serious contender though. It the other way around. Java has barely caught up with C#. C# team is typically introducing more features, faster.
  - royjacobs 3y ago
    I'm not sure language design should be a race to see who can add the most features, though. I prefer Java's more thoughtful approach to introducing new features.
    - keithnz 3y ago
      in what way do you think it's more thoughtful than C#?
hitekker 3y ago
> Java might be verbose, but it's well-understood, and it's not actually what slows development. I think you're onto something. Maybe some Java-by-default workplaces lack technically interesting problems that engineers want to solve, so those engineers instead overfocus on the frictions of the parts they can control. Maybe those engineers desire expressiveness in their working programming language to compensate for the restrictions on the rest of their work. Just a hunch though.
- deleted 3y ago
  [deleted]
- throwaway13623 3y ago
  I think you may have a point. At mature companies, they have largely solved the product market fit and uses a stable stack that just works. I have worked worked for such companies, and developers jumped at the chance to use the latest (untested) technologies for greenfield projects if they had the chance. In my startup we also use a "boring" stack, but the problems we solve are innovative and motivation in itself. The developers work closely with customers and can see the impact that the product has. They are no longer working in a Jira-factory and while they are still interested in technology they also find motivation in the product itself.
esafak 3y ago
Kotlin has great tooling, and Java library compatibility, so why wouldn't you use it? When you work in Kotlin, you give the masses of Java programmers the ability to contribute and a licence to check their EnterpriseGradeFizzBuzzSolutionStrategyFactory mentality at the door. Do Java projects in industry even use the new stuff? Also, you can use virtual threads with coroutines.
- happymellon 3y ago
  I'm allowed to use Streams but var isn't because it makes GitHub PRs difficult to parse. We got to upgrade from Java 8 to Java 17 in 2023.
  - throwaway13623 3y ago
    I've worked in "enterprise" and have a different experience. The enterprise projects that I was working on switched to Java 8 in 2015. There were some legacy services that remained on 5 or 6 for a while, but they were mostly in "maintenance" mode and nobody wanted to spend time on them. I have over two decades of experience and there has always been room for trying out the "new" technologies and keeping up with the latest best practices, even in enterprise. I know that not everyone has this experience, but there are actually a lot that happens outside slow big American legacy companies... In my current startup we use the latest JVM and have a mix of Java and Kotlin. It works really well and we have never experienced any problems with development speed that was related to code or language syntax. JVM + Spring boot + Postgres may be the "boring" choice, but it has enabled us to focus on getting things done and focusing on the product. It didn't take long for juniors to be productive in our stack either. Spring itself looks a bit scary at first sight, but once you learned the basic philosophy you have less issues than a Node project in my experience. I know that my experience may not match your experience, so I recognize that I can't make a generic statement. It's just a bit frustrating to see similar statements made by people with bad experiences. - Not all Java development happens in enterprise. There is a thriving eco system of small to middle sized companies and startups using Java - Not all enterprises are the same. I've actually noticed a shift to the other extreme, where enterprise uses the latest technologies to attract new employees. Nobody who has a choice wants to work with factory patterns on an old version of Java - Old Java patterns like factories and extreme use of inheritance is out of fashion. There is of course a lag like in any trends, but remember that Java is so widely used so you will always find companies that are slow to adopt, or have legacy software that is in maintenance mode.
gleenn 3y ago
Clojure is such a joy to use. I get the maturity of the Java ecosystem and the immutability, functional style, and concision of a lisp. If performance really matters, and Clojure does perform well, you can always dive into stuff with all the Java tooling and interop is extremely easy. I really wish more people picked it up.
- cryptos 3y ago
  I feel no desire to use dynamic typing again, as nice as Clojure might otherwise be. While Kotlin is not strictly immutable, it is much better in this regard than Java. Collections are immutable by default in Kotlin (or more precisely you get an immutable view defined by the respective interface) and that is quite useful in practice.
switch007 3y ago
Will they cherry pick Kotlin’s null safety…?
- cryptos 3y ago
  No, they will allow to mark types as explicitly not null (the other way around). The default in Java will still be that everything can be null.
sho 3y ago
> syntax is overrated Speak for yourself there good buddy. It's pretty important to me! But I do agree with your broader point. From one perspective, Kotlin has been a great success if we define its mission as a test-bed and laboratory for improving Java proper. Unfortunately, while it has arguably succeeded in that mission, in doing so it might unavoidably fail in another mission, which is to thrive as an independent language. I'd liken it to yarn and npm. Yarn was a huge success.. at forcing npm to massively improve and thus basically rendering itself irrelevant. A bittersweet success, but a success nonetheless.. I wonder if there's a term for this kind of self-sacrificial project which makes the world better for having existed but doesn't survive the process..

dave4420 3y ago

Scala isn’t dead. I’m job hunting right now, and seeing plenty of Scala jobs. Not as many as Node+TS+React, but what do you expect?

guytv 3y ago
"Scala isn't dead" reminded me of this one "No no he's not dead, he's, he's restin'!": https://www.youtube.com/watch?v=vZw35VUBdzo https://www.youtube.com/watch?v=vZw35VUBdzo
threeseed 3y ago
It also benefits from being one of the only full-stack languages. Scala.js has excellent front-end frameworks like Slinky React [1], Laminar [2] and Scala has industry-leading concurrency libraries like ZIO [3]. I've yet to find anything that comes close for end to end web apps. [1] https://slinky.dev https://slinky.dev [2] https://laminar.dev https://laminar.dev [3] https://zio.dev https://zio.dev
DeathArrow 3y ago
>Scala isn’t dead. Scala isn't dead. It went to play between the stars with Pearl and Ruby.
62951413 3y ago
If you subtract Spark/Flink-related ones not really. Plenty only in comparison with Kotlin backend roles (i.e. non-existent in the Bay Area). It's very disappointing to me personally but it is what it is.

r1jsheth 3y ago

one thing i definitely liked about kotlin was reduced verbosity. otherwise all the other points, you made me ponder a bit. let's see where kotlin goes.

kmonsen 3y ago

Maybe in the backend but for mobile (android) kotlin is still a thing and will be for a long time.

FlyingSnake 3y ago

There are two problems Kotlin faces; Kotlin the project/product and Kotlin the language. While this article touches Kotlin as a Product, it’s very thin on the Language aspect. Here’s an old post discussing the real troubles Kotlin Lang might face due to the inevitable divergence of Java/JVM. https://np.reddit.com/r/java/comments/ndwz92/can_i_get_some_reasons_to_use_java_instead_of/gyd5yi5/ https://np.reddit.com/r/java/comments/ndwz92/can_i_get_some_...

nealliu 3y ago
Make sure you read the reply a few comments down from the original post, it invalidates much of the op.
- FlyingSnake 3y ago
  True, the old article had some nice rebuttals. I wonder how many of these predictions came out to be true so far.

ShadowBanThis01 3y ago

"FAANG has first-class support and commitments to Java" Nobody told Apple that.

Dig1t 3y ago
Apple has an incredible amount of Java running server side, and they maintain their own JVM/tooling. Support on Mac is admittedly not the best though.

cryptos 3y ago

> Null was always a pitfall in Java. It has slightly improved with the controversial Optional type. It’s also why I suggest that everyone use only wrapper types everywhere, instead of primitives, unless they can prove with a JMH test that a primitive provides enough of a performance benefit. That doesn't make sense at all! Why should one do it without a need? To have NullPointerException with "primitive" types, too? > Kotlin ecosystem is severely lacking compared to Java. FAANG has first-class support and commitments to Java, like providing JDK with multi-year support commitments. It is not really needed to provide JDKs or something else especially for Kotlin, because Kotlin basically just uses the JVM (at least if you use the JVM as a target). > To this day, there are significantly fewer Kotlin developers than Java developers. Yes, that is probably true. Although almost every Android developer should know Kotlin these days and there are quite a few them. But even if a developer doesn't know Kotlin at all, it is relatively easy for a Java developer to learn it. In my experience it a takes a few days to a few weeks to be at least as productive as with Java (even not all Kotlin features are learnt in this time). > Lack of progress: Compared to Java lately (e.g., records two years ago, pattern matching, and VT release this year), Kotlin has been stagnating in delivering the big features that would bring us (Infobip) value over alternatives. Here, I agree. Some years ago I was super excited about Kotlin and couldn't wait for a new release. These days new releases are mostly boring. Maybe the most important stuff is simply done, but then there are enough interesting ideas to improve it (real pattern matching, meta programming, union types, ...). But JetBrains and Google decided that it is more important to improve the fundamental infrastructure first and decided to create a new, faster compiler (K2). As boring at it is feature-wise, I think it is a wise decision, because every project would benefit from it. The plan is to add new features, once the compiler is ready.

ShadowBanThis01 3y ago

Does the "pattern matching" referred to here work like JavaScript's "destructuring?" It's the thing where you can call a function with an object, but the function's parameters extract one or more of the object's members directly without mentioning the object's class, so it'll take anything that has appropriately named members.

nsonha 3y ago
no, pattern matching is more like destructuring AS CONDITIONS (eg: if object has this structure) of switch blocks. While destructuring is simply sugar for assignment, pattern matching is more complex. I don't know about Java but in some languages you can customize the pattern so that it is not neccessarily in the actual shape of the object. In some languages applying pattern matching at the top level of the function is the equivalence of overloading.
- ShadowBanThis01 3y ago
  Thanks! Intuitively this sounds like it enables what at one time would have been called bad programming (widespread reliance on RTTI), but on the other hand a lot of rules have turned out to be arbitrary.
DeathArrow 3y ago
I think they've partly implemented C# version of pattern matching.

wiseowise 3y ago

What a low quality article. Language is more just a set of features. Anyone who tried both Java and Kotlin for reasonable amount of time will understand that. Regardless of how many features Java adopts from Kotlin or other modern language it will still remain shackled by billions of lines of legacy code and boilerplate consequently. The only one who might like the article is self-conscious Java developer who wants to feel good by bashing on competing language. Wish it wasn’t morning so I could elaborate on every point. Might reply later to this comment.

jillesvangurp 3y ago

The future is always a bit uncertain. But Kotlin's future actually looks pretty good to me. This article looks like the author is not really clued in to the massive amount of progress and change happening especially in the last year. There's nothing wrong with being a bit old an conservative and stuck in your Java ways. Been there done that and trying to be better than that now. But this article is just a bit overly dismissive and poorly argued. I'm biased of course having used Kotlin extensively for the last six years and having made the switch from Java. From my perspective It's simply a much better Java. And I have 25 years experience with that, mostly server side. And the way I'm using it, it's also a better Typescript for me. If you have trouble parsing that last bit, I'm using kotlin-js to develop frontend code. It's actually really nice for that even though not many people do this. Well worth a look if you are getting tired of dealing with Javascript's idiosyncrasies (which typescript inherits) and a bit jealous of what all the cool kids doing mobile applications are using. Which would be using fancy Kotlin and Swift UI frameworks mainly. Kotlin-js being nice to use should not be that surprising because of course a lot of Android developers use and love it and a lot of the libraries and practices port over very well to the web if you use kotlin-js. E.g. I use dependency injection (koin); which as it turns out is equally useful and nice to have in a browser as it is on Android and in Spring or other places. There are a few changes happening this year with Kotlin that are exciting for Kotlin users and interesting for people not yet using it: - Kotlin native is stabilizing. It now works well on IOs, Android, Linux, Windows, and MacOS. It's not "just another jvm language" anymore. The multiplatform library ecosystem is really starting to thrive. Lots of growth there. Especially in the last year. And I maintain a few myself. - The web assembly compiler is now available in an alpha version and browser support for garbage collection in WASM just rolled out in Firefox and Chrome a few months ago. This is required by Kotlin's wasm support as it does not bundle its own garbage collector. Safari should follow soon/eventually. This means you can now use kotlin-wasm in a browser without having to fiddle with feature flags in your browser. Multiplatform library support for this is still a bit a work in progress but most kotlin multi platform libraries should start having wasm targets in the next few months. Wasm works in servers and on servers, lambda functions, and edge networking. So, first class Kotlin support for wasm is a big deal and the whole kotlin multi platform library ecosystem is coming along. - Kotlin 2.0 is in Beta currently and should release in a few months (spring?). Kotlin native and wasm support and that are all happening at the same time and come on the tail end of a years long effort to re-engineer the compiler and IDE toolchain. Work on Kotlin 2.0 actually started about three or so years ago and it has included a gradual rewrite of the compiler through the 1.6-1.9 releases. - Building on all this is Compose multiplatform, which brings Google's Jetpack Compose to other platforms. That's currently stable for a few platforms, in alpha versions on others (like IOS and web). That's something that should stabilize towards the end of the year. We'll have a cross platform, natively compiling UI framework that is usable across web (wasm), IOS (native), Android (native) and the three Desktop platforms (jvm, for now). So, that could end up being a nice alternative to things like flutter and react-native. Or indeed to packaging up web applications as PWAs or using things like electron. It might not be everybody's cup of tea but that's a lot of progress that came together in the last year. I use other languages besides Kotlin. So, I can appreciate other languages as well. But Kotlin is just really nice.

bobm_kite9 3y ago

I'd love to see Java adopt Kotlin's more advanced type system: Proper support of nullable/non-nullable types, better generics and no primitives. Not sure how they could get there but that would be amazing. Also Kotlin has a pretty good JavaScript and Native support story now.

cetu86 3y ago

While the author dislikes extension functions in kotlin they enable one feature that Java doesn't have: With them you can create domain specific languages within kotlin that are quite ergonomic. - Jetbrains has built a nice reactive js wrapper with them. - The gradle configuration is written in a kotlin dsl. They can be used to specify configuration and add meta information and thus replace Java annotations. That is my kotlin "killer" feature because I personally don't like annotations. Java's language design has always been "pedagogical" (or patronizing) to not give the developer to much power to create to much abstractions and complexity. So it's not just its age but also this philosophy that has made Java a rather inelegant language ( compared with e.g. kotlin)

dingi 3y ago

As I see, the only purpose of Kotlin is a be test bed for novel features to JVM based languages. And eventually Java is going to integrate those features better than Kotlin. And Kotlin's advantages are gone like that. To be honest, I have never seen Kotlin used in environments other than Android. The day Google decides to move Android development to another language will be the day Kotlin dies. Or becomes a zombie.

DeathArrow 3y ago
>And eventually Java is going to integrate those features better than Kotlin Kotlin has better syntax and is less verbose. That matters for a lot of developers. Kotlin deals with null in a better way. Kotlin has better types.
throwaway13623 3y ago
> I have never seen Kotlin used in environments other than Android I have seen several companies that use Kotlin as a backend language (often with Spring). I personally don't find the differences enough to bother switching from Java, but I also don't mind working with Kotlin in existing projects.

nbittich 3y ago

I agree, I remember learning Ceylon few years ago in the metro while going at work, now it is probably one of the rarest programming language that we can say for sure it's dead (has been archived few years ago iirc).

stefs 3y ago

in my opinion, modern java's language ergonimics are good but kotlin is still far better. i didn't write much plain java in long time since having to adopt kotlin. i love the integrated null safety / handling at a syntax level with the ? operator; optional felt clunky in comparison. lambdas plus everthing's an expression allows for concise, readable code. and i love the scope functions. i agree that extension methods may have turned out to be a footgun, but i feel like it hasn't been a huge issue in the field. it's doubtful java is able to integrate most of those ideas in a way that feels as natural. i don't understand why the author chose to ignore android, it's an elephant in this room. as long as android doesn't drop kotlin for something else as the lingua franca of the platform it's got certain guarantees.

willtemperley 3y ago
Absolutely, while Kotlin is a first class citizen in Android, it isn't going away. Neither is Scala because there are plenty of developers who like bleeding-edge and experimental language features. Personally I don't use it anymore as really don't need things like implicit parameters, but props to each and every early adopter of language features that help Java evolve. Thanks to Kotlin and Scala, Java can now be very pleasant to code in.

mustermannBB 3y ago

My only issue with Kotlin is Kotlin's over reliance on JetBrain products and being so tightly tied to a company which priority it is to of course sell their IDE. To be fair, one of course use the free community edition but still you kinda need a JetBrain product to ensure you getting the most out the language. With language servers these days, that feels like it is going the opposite direction.