11 ms·

As far as the Java platform (AKA "the JVM") goes, Kotlin is painting itself into a corner. Kotlin was designed in 2009-10, in the Java 7 days, around the time o

• The_rationalist 6y ago
  Replacing current courtoutine implementation to use Loom threads or inline classes to use Valhalla are both implementation details that should not at all change the user facing API and complexity. Your second point somehow stand: exploiting such optimizations will either need a runtime check or to be enabled automatically based on your JVM target specified in your gradle/maven. As for the long term, google devs are heavily contributing to Kotlinc and I hope they will pressure Android architects to replace dalvik with openjdk.
  • alex7o 6y ago
    As good as this sound this is a no go because of oracle/Google lawsuit. So they probably want to move away from java entirely.
    • pjmlp 6y ago
      Which will never happen unless they rebuild all their Java tooling with Kotlin/Native. Or switch to something else like ChromeOS or Fuchsia, both with zero dependencies on anything Java related, including Kotlin.
  • pron 6y ago
    > Replacing current courtoutine implementation to use Loom threads or inline classes to use Valhalla are both implementation details that should not at all change the user facing API and complexity. This is not accurate. Re Loom, the entire Java platform will be built around a "single colour" structure. Kotlin, like C#, is based on a split, two-colour, model. It is true that under the covers it could map both colours onto the same one, but that will mean that Kotlin adds a lot of unnecessary complexity, and possibly make it harder to target multiple platforms (i.e. a lot of Kotlin code that will work well on Java will not work well on Android or JS). Re Valhalla, it will allow multi-component inline types -- that's a user-facing change -- but those won't work on Android, at least not without significant overhead.
    • Nullabillity 6y ago
      > Re Loom, the entire Java platform will be built around a "single colour" structure. Kotlin, like C#, is based on a split, two-colour, model. It is true that under the covers it could map both colours onto the same one, but that will mean that Kotlin adds a lot of unnecessary complexity, and possibly make it harder to target multiple platforms (i.e. a lot of Kotlin code that will work well on Java will not work well on Android or JS). Function colours are a useful modelling tool regardless of whether the underlying platform requires it. That's sort of like saying "everything is eventually just bytes anyway, so types are unnecessary complexity". Of course, there are languages trying flatten everything into a single type. But personally, I'd rather not be programming PHP when there are better options available. > Re Valhalla, it will allow multi-component inline types -- that's a user-facing change -- but those won't work on Android, at least not without significant overhead. Not sure how that's any different from a library's perspective than "this API isn't available on older JVMs, so don't use it if you want to target Android".
• pjmlp 6y ago
  I think JetBrains thinks too much of themselves, fueled with Google wind, they are now trying to turn Kotlin into a platform of their own, and as proven by Kotlin/Native, their expertise is really just making IDEs. Too many recurring memories from Borland of yore with Delphi, when I see how JetBrains is trying to push Kotlin.
  • eklavya 6y ago
    I think that's harsh. Why shouldn't they try building a platform if they want? Who should they ask first? Disclaimer: I have never used Kotlin. I use Scala.
    • pjmlp 6y ago
      All the best for them, as long as the community takes the attitude to appreciate JVM and Java for giving birth to Kotlin, instead of bashing Java as if Kotlin could stand on its own.
      • valenterry 6y ago
        But Kotlin is just a much better language. Not sure if you can call that "bashing".
        • pjmlp 6y ago
          Which is worthless without the wealth of the Java ecosystem, but apparently Java is a very bad language.
          • elbear 6y ago
            Can't the Java ecosystem be valuable and Java the language be bad at the same time?
            • royjacobs 6y ago
              It could, but Java the language definitely isn't bad. Sure, it's verbose, but it's pretty simple to grok overall. I agree with pjmlp (and I don't even work for Oracle!). I think that once Java has caught up with pattern matching syntax, data classes, fully integrated Loom and Valhalla etc there really isn't a need for Kotlin on the server-side anymore. For Native or frontend stuff it's definitely always going to have to play catch-up and try to shoehorn wildly different semantics into the same language somehow. So I guess it'll end up as a niche language on Android, ultimately. Not necessarily a bad place to be, though!
• The_Colonel 6y ago
  > Kotlin will have to choose to either give up on low-overhead abstractions, give up on some of its platforms, give up on giving access to full platform capabilities It can be just reasonable mix of all of this. > if Kotlin's inline types will make use of Valhalla, then they won't work on Android, at least not without much overhead. Looks to me like a valid strategy.
  • pron 6y ago
    Oh, I'm sure they'll do something reasonable, but whatever it is, it either significantly scales back the goals or it turns Kotlin from a "there's nothing to lose" proposition to a "there are new tradeoffs and added risks to consider" proposition.
    • thu2111 6y ago
      Assuming Android doesn't support Valhalla at all, I suspect they'll just introduce an Android specific backend in which inline classes with >1 member are compile errors. The language is already slightly different between platform targets anyway so it's no big leap.
• rzwitserloot 6y ago
  As a simple example of this problem: In java7, the concept of 'I want to typecheck this expression, and if it is of the type I want, I want to do things to it based on that fact' was unwieldy in java: -- JAVA 7 CHECK-AND-USE -- if (x instanceof String) { String y = (String) x; y.toLowerCase(); } kotlin decided to address that: -- KOTLIN CHECK-AND-USE -- if (x is String) { x.toLowerCase() } within the 'if', x 'updates its type' automatically. Note that if java were to copy this, method dispatch depends on the compile-time type of the arguments, so if java were to apply this behaviour to its instanceof operator, that would break backwards compatibility (existing java code would mean something else just because you updated java versions). The obvious thing happened: Oracle / the JCP rejected this outright. Hence, it doesn't work that way in java and never will. But this problem WAS tackled by java, and in a much different way: Java has generalized this concept as pattern matching and went all in on that. -- ACTUAL FUTURE-JAVA -- // preview feature in 14, will be in 15. if (x instanceof String y) { y.toLowerCase(); } // -OR-- if (!(x instanceof String y)) throw new IllegalArgumentException(); y.toLowerCase(); and, taking pattern matching to the next level: // will likely be preview in 15 or 16. // Given: value class Point {int x, y; } if (p instanceof Point(x, y)) { // you can use x and y (both int) here } Which goes much further than kotlin and is quite different. So now kotlin has 3 options and they are all bad: 1. Also adopt this syntax. But now there are 2 different ways to do the same thing, so kotlin is now the language that feels like a jumbled mess that needs cleaning up, with pointless style debates and an increased learning curve for no good reason. 2. Ditch their existing syntax and adopt this syntax. That means kotlin breaks their own backwards compatibility, and everybody needs to either accept they can never update their kotlin, or they need to find all spots in their codebase that uses the old construct and update it. 3. Don't adopt this, and be in the situation that java has _more_ language features that kotlin. Or adopt pattern matching differently, at which point the idea that it's 'easy' to switch from java to kotlin starts taking a hit... and likely kotlin's design will start to feel jumbled because features are spliced on ad-hoc and mostly informed by dueling concerns.
  • ImprobableTruth 6y ago
    Why wouldn't they just extend their existing syntax? i.e. something like if (p is Point(x,y)){ //p : Point, x: int, y: int } or hell, adopt any other pattern matching syntax. "Either they adopt the java syntax or are missing features" seems like a false dilemma to me.
• soulnothing 6y ago
  I've been using Kotlin for a long time for backend/server dev personally and professionally. I've been feeling this more and more recently. I've said a couple times to my colleagues I've backed the wrong horse. I had been making strong use of multi platform features. The end goal had been to easily move a piece over to a native image for server less if need be. Or output SDKs for Java script libraries. As an example I'm working on a multi platform micro-orm. But due to lack of cohesive reflection. I have to store the class package name in a map to reflect the type on all three platforms. As to the note about inline types and Valhalla. Or loom for that matter. I have a feeling that will be buried as a compiler option. That needs to be amended in a build file. I have had to do this with JS, native, and a JVM I'm finding that multi platform out side of mobile and JVM. Are not well polished. Additionally you're carrying a lot of baggage over from the JVM. In regards to it's type limitations and memory management. At the same time it's very impressive to easily target all three platforms. But it's a very difficult task. Combine this with the few back-end places I've seen using Kotlin for the back end. Limit the features that can be used. To the end that the next Java version can primarily satisfy their needs. I've seen more effort coercing developers not to use sealed classes, null coalescing, co-routines etc. That could just be avoided by staying on Java. I think it's a good language. It feels like a commonality of a number of the best practices. I've been able to migrate python, ruby, and typescript devs to a ktor setup and have them productive in a week or two. Gradle for all it's warts, I think is a pretty good build system. There is a rich eco-system of existing libraries. It has good performance, easy type semantics to grasp without getting in the user's ways. I feel like it's Typescript with a better build system (opinionated), and light pattern matching. The biggest API stability issue I've had is Gradle. I've carried projects from 0.11 to 1.4 with just nominal code base changes, but big build file changes. The biggest focus is mobile, followed by Spring back-end. I have been very critical of Spring in my prior posts. There is a road map of Ktor, their in house web frame work coming soon. I'm curious to see where the language goes next. I'm finishing up one project in Kotlin but am eyeing Rust as a possible replacement
  • nobleach 6y ago
    I like your take on Kotlin being Typescript with a better build system. I often show our Kotlin devs our Typescript apps and say, "see, it's very close... we just add semicolons". Many of them are former Java devs, so they're used to blindly believing, "JavaScript == bad". (yes, everyone can see what I did there) I like showing that it can actually be quite good in some ways. For high performance db crunching, I strongly prefer Kotlin. But for pure network services, REST request to sending files via SFTP, Typescript is really nice.
• avasthe 6y ago
  ^this is an oracle employee speaking Everyone else puts a disclaimer on HN. You Oracle people are not special. Edit: I know I am getting severely downvoted for this. But there are some Oracle shills around here.
  • Spivak 6y ago
    I mean an Oracle employee talking bad about their own company in the subtext is kinda the opposite of shilling.
    • ragnese 6y ago
      I didn't downvote either comment, but I do appreciate the person who called out the individual's affiliation. In the current era of so much astroturfing, I feel like it's good manners to indicate when you make a comment that you are an interested party.
    • vlovich123 6y ago
      What negative subtext did you pick up on? I didn't catch any.
  • apta 6y ago
    He's the lead of project Loom, so he knows a thing or two on what he's talking about ;-)
  • blablabla123 6y ago
    I think this doesn't change his argument. Probably people naturally want to work at places where peers share similar opinions
  • dcgudeman 6y ago
    Well oracle employee or not they are making some interesting points. I would appreciate more discussion on the content of their post rather than just disqualifying it outright based on their employment.
  • oscargrouch 6y ago
• dpezely 6y ago
  Off-topic with respect to Kotlin but relevant to the Java platform: From your perspective, what are Clojure's prospects for contemporary and future alignment with the JVM? After all, Rich Hickey built the core in 2006-07. Looking at his graph[0] of code introduction and retention in his HOPL-IV paper[1] might imply that either he's that good at the core abstractions or possibly the language could suffer a similar set of limitations as commented about Kotlin above. [0] https://download.clojure.org/papers/clojure-hopl-iv-final.pdf https://download.clojure.org/papers/clojure-hopl-iv-final.pd... p26 [1] https://clojure.org/about/history https://clojure.org/about/history
  • pron 6y ago
    I think Clojure has a very different design philosophy and very different goals. Specifically, its abstractions do add overhead -- be it due to immutability or lack of typing -- and that's perfectly in line with its goals. As such, it flies higher above the Java platform than the Java language or Kotlin, and is less sensitive to changes in the underlying platform, as it doesn't try to always closely reflect its capabilities.
  • deleted 6y ago
    [deleted]
• Matthias247 6y ago
  I think you might be right. But isn't this just the general risk of dealing with a "stagnated language/tooling"? Either you wait for it to go out of sleep mode and catch up. This might never happen, and is thereby a risk. Or you fork off to your new system which attempts to fix the issues you observed. This might require a serious investment. And maybe it's not useful in the future, since the original tool might catch up and most of the people will stick with it. So now you evaluate the 2 options in terms of risk and short/mid/long-term benefits as usual. And I think the Kotlin designers and all users which jumped onto the platform made a sensible choice. I really love the idea behind loom - but it's still not generally available. Kotlin coroutines are, and imho solved sane concurrency for mainstream users. If I would have to write a massively concurrent application on the JVM about 1-2years ago, Kotlin could certainly have been my way to go. In 1-2 years it might be Java+Loom. Last but not least I would like to point out that Kotlin is extremely well designed. Imho it's coroutine system is the best in industry right now. It's extremely configurable, and the inclusion of structured concurrency right from the start to encourage good designs makes a lot of sense! I would not be suprised if Kotlins designers already have decent plans on "what do we do if Java integrates Valhalla/Loom/etc"? And I think it's pure existence pushes the standards, and has a positive impact on the design of Java and other languages.
  • pron 6y ago
    > And I think the Kotlin designers and all users which jumped onto the platform made a sensible choice. Oh, absolutely! And don't get me wrong, I think Kotlin was the right thing to do ten years ago -- Java was not in a great shape back then (in fact, Sun drastically cut investment in the core platform) -- and maybe even five years ago. I also think it was very well designed -- very much in the "Java spirit" -- although I think it's taken things a bit too far recently for my taste. > Imho it's coroutine system is the best in industry right now. I think that coroutines for a platform that's already designed around multi-threading are a bad idea altogether (this goes for C# as well) unless the language has some very specific constraints, like C++/Rust. Some might disagree, but I don't think those would be people who've had experience with Erlang or Go (although those platforms, like all platforms -- including Java, of course -- have their own problems). Nevertheless, for quite a few it's certainly better than nothing. > I would not be suprised if Kotlins designers already have decent plans on "what do we do if Java integrates Valhalla/Loom/etc"? I'm sure they do, and I'm sure their solutions would be great, but they'll need to sacrifice some of their goals. In any event, it is no longer the "there's nothing to lose" proposition it used to be. > And I think it's pure existence pushes the standards, and has a positive impact on the design of Java and other languages. Maybe, although Java (the language) has so far taken little if anything from Kotlin (most of the inspiration to recent work has come from ML, and even Scala to some degree). If there is one Kotlin feature that I think might ultimately make its way to the Java language it would probably be nullability types; I think that that's its most impactful contribution to the design of other languages, too. What mostly pushed Java forward in recent years is the increased investment by Oracle, and competition from other platforms. If I were to pick a positive impact Kotlin has already had on the Java language, it is perhaps demonstrating that there is appetite among programmers in more conservative languages (as opposed to Scala and Haskell programmers) for new language features beyond lambdas.