24 ms·

I’m skeptical of the value in doing this. There are a mountain of tools like NullAway, ErrorProne, Immutables that make it so much easier to write safe code in

• t-writescode 2y ago
  I, personally, happen to like writing in Kotlin more than Java - with a lot of experience in both (though admittedly, all? the Java I wrote is in the pre-Streams style). I like: * data class Foo(val theImplementationAndStyleOfDataClasses: String) * elvis?.operator?.chaining * the order of variable declaration (type afterward) * how function pointers at the end of a method call can be auto-inserted as the next curly bracket * how you can have fun foo() = returnValue; in one line. * fun `method names that can have spaces - and dashes - in them`() The preceding 3, combined, allow for: @Test fun `much easier testing`() = commonTestSetupWrapper { // the code under test } * val immutable by default While I agree that Kotlin has definitely helped push Java in the right direction; and I agree that it's probably not especially necessary to migrate 10MM lines of Java code to Kotlin, especially since they're fully interoperable, I definitely would prefer writing _new_ code in Kotlin over Java for the for-the-lazy devex improvements, if nothing else. fwiw, my "good at it" programming history follows the lineage in historical order of: * Java (8?? years of it including competition programming) * C# (5+ years) * Python (2016ish to current) * Ruby (3-ish years, lots of Rails) * Kotlin (2-3 years, through current - written over 40k lines of Kotlin in the last year, alone)
  • 0cf8612b2e1e 2y ago
    `method names that can have spaces - and dashes - in them` Eugh, that is a turnoff. Maybe I have programmer Stockholm’s, but at least with a single connected word, I can always double click to select the token. Maybe, I might have wanted dashes at some point, but spaces seem like a step way too far.
    • ditn 2y ago
      Generally these are only used in test methods, which is fine. I've never seen anyone use them outside that.
      • recursive 2y ago
        What benefit do they provide in testing scenarios? I've never written Kotlin, but from an outsider's perspective, it seems like a slim benefit, outweighed by the cost of the mere existence of this syntactical oddity in the language's grammar.
        • t-writescode 2y ago
          When writing tests, you can name the methods more useful things, such as: class MyTestableClass { fun `methodName - when input does not parse to valid regex throw exception`() { } } It's pretty clear what is under test in a situation like that. That's basically the only situation I ever see it used in (and would code-smell the heck out of it if I saw it in other circumstances). People who are familiar with RSpec-style testing are very used to this sort of thing. describe MyTestableClass do context 'input parsing issues' do context 'when not valid regex' do it 'throws exception' do ... end end end end Anecdotally, I've also found that such style naming for tests allows me to write out the desired names for all the tests ahead of time more easily and then implement them. That happens to be my flow.
          • codedokode 2y ago
            I like how tests are made in Python - you don't even need classes, just functions, and use a single assert keyword for everything. Also it's easy to parametrize them using decorators.
            • t-writescode 2y ago
              Parameterized tests are a huge, huge win, yeah. I am a big fan of them and look for how to do them in every test framework I use. RSpec was the weirdest for me; but NUnit and JUnit have been quite easy, and I'm not surprised at all they're easy in Python too (admittedly, I don't remember if I ever wrote them in that language).
  • NIckGeek 2y ago
    fwiw in modern-Java they have data classes: record Foo(String theImplementationAndStyleOfDataClasses) {} The string is final. While sadly there is no elvis operator, the Optional type helps: evlis.map(e->e.operator).map(e->e.chaining) I still strongly dislike working in Java but Java 23 is a long way ahead of the Java 6 I first learnt Java with.
  • ncallaway 2y ago
    I also really like conditionals like switches and ifs returning values.
    • overhead4075 2y ago
      Java 14 introduced switch expressions. https://docs.oracle.com/en/java/javase/17/language/switch-expressions-and-statements.html https://docs.oracle.com/en/java/javase/17/language/switch-ex...
    • bberrry 2y ago
      try statements being expressions is also especially lovely
  • akoboldfrying 2y ago
    Honestly, none of those differences you listed seems especially compelling to me, except possibly for the ?. operator. What would be compelling: Array types that don't hate generics, or generic collection types that don't hate primitive types. Does Kotlin improve on Java at all here? It's such a pain having to remember this bonus complexity when all I want is a consistent way to manage a bunch of things. (I suspect not, as I think the limitations are at the JVM level, but I don't know.)
    • t-writescode 2y ago
      Out of curiosity, what are you wanting that autoboxing doesn't resolve?
      • kjeetgill 2y ago
        Stripping out Maps/Lists with boxed keys and values is the first easy thing to do when perf tuning a piece of code. It's so frequently impactful that it's worth doing immediately without any measurement. You just swap them out with fastutils or trove and call it a day.
      • akoboldfrying 2y ago
        I think you're right, that's probably the best (lowest mental overhead, fewest footguns) way -- always use a List instead of a raw array, and always box primitive types. This also avoids the parallel explosion of Stream types and methods (IntStream, mapToInt(), etc. (and the fact that there's no BooleanStream or ByteStream, etc.)). That said, I tend to get bitten by the fact that == on 2 boxed numeric values is roughly as misleading as possible -- it does reference comparison, but interns small integer values only, so (Integer)42 == (Integer)42, but (Integer)420 != (Integer)420. (So the small values you probably used in your unit tests will appear to work just fine with your broken, ==-using code.) ETA: Deleted a misplaced "new". I also don't love that, e.g., ++x does a heap allocation + deallocation if x is boxed (since boxed types are immutable). But usually I care more about the cycles I spend coming up with correct code than cycles the CPU spends executing it.
    • sjrd 2y ago
  • haspok 2y ago
    > * data class Foo(val theImplementationAndStyleOfDataClasses: String) For the purists there are records now in Java (which can be combined with destructuring / pattern matching - there were significant improvements in this area in the last few JDK releases, and more are coming!). In this regard Java had surpassed Kotlin by some margin. For the enterprise coders, there is the Immutables project (https://immutables.org https://immutables.org) which you can say is Lombok on steroids (but implemented correctly, that is, by generating classes which you can inspect as regular source code, instead of relying on hacking the compiler...). > * elvis?.operator?.chaining This will hopefully be finally resolved by one of the subprojects of project Valhalla, as a prerequisite for value class support (which cannot be null, so...). The others on your list are small and subjective stylistic differences, of course your preference may vary, but should not weigh heavily in any Java vs Kotlin discussion.
    • t-writescode 2y ago
      > pattern matching ... In this regard Java had surpassed Kotlin by some margin. I did just glance at Java's pattern matching; and yeah, it does look like it is a bit more powerful than Kotlin's pattern matching in that it can, at the same time, look for both type and a conditional. That's relatively neat - not something I've personally needed / wanted; but neat just the same :) The JVM is a really nice virtual machine in how it lets us use both of these languages fully interchangeably to pick the one we like more. I'm glad Java has been investing in some of these areas, too. Everyone improves when paradigms and new learnings are distilled.
      • houli 2y ago
        Kotlin 2.1 has added "Guard conditions in when with a subject" as an opt-in feature https://kotlinlang.org/docs/whatsnew21.html#guard-conditions-in-when-with-a-subject https://kotlinlang.org/docs/whatsnew21.html#guard-conditions...
    • unscaled 2y ago
      Java records do not have a copy method (or with clause or whatever equivalent), and there are no keyword arguments. This makes Java records extremely painful to use for any data has more than 3 fields or so. You could use them together with an annotation processor like RecordBuilder (or Immutables or Lombok, but I don't think they support records?), but that's just not pure Java. Annotation processors that generate byte code always come with their own complexity. Kotlin data classes have their own warts (order-based destructuring can be dangerous and the copy() method is a bit hacky) but the overall ergonomics for large value objects are better than Java records at this point.
  • usrusr 2y ago
    When it's "sleeping" code, not as in unused but as in not currently being worked on (no changes in open branches), then it can be quite valuable to have some bulk translation run while the code actually is sleeping, and not at some future time when there'll likely be a whole burst of activity happening in parallel. Repo host products might actually add "transform while sleeping" a possible feature, with their cross-branch knowledge, and perhaps some history mangling for a best effort approach to retaining some of th knowledge available through blame through the conversion. As for Kotlin in general, I agree with your list. I really enjoy the way Kotlin improves the dev experience not so much with audacious new (or "new to a java-like environment", of course I'm looking at you, Scala) concepts but with small trivialities like being able to assign the outcome of an expression chain to a name without polluting that name's scope with intermediates that really don't have any purpose after the result of that chain is assgned. And I don't hold it against Java that it does not follow that path (it focuses on more impactful changes), I would consider it almost out of character if it introduces e.g. .let. The only thing I'm a bit torn about when it comes to Kotlin is wether the "this" variants of scope functions were a good idea. They are certainly part of kotlin, and some "DSLy" styles would really not be the same without them, but if I were to pull what I like about kotlin into other languages I'd probably introduce let and apply (and the this-less run) and skip run/with/apply (assuming that the target language even has a this to run/with/apply on)
  • OtomotO 2y ago
    I used to do Java and Scala. In 2020 I started a new project in Kotlin. I like Kotlin, but what I hate is that in the meantime I migrated all my programming to Neovim and Helix. All programming? No, not Kotlin, because the LSP isn't there and JetBrains clearly has no interest, they want to sell their IDEs. Now don't get me wrong, I have an IntelliJ license since 10 years, even back when I was employed and paid it out of my own pocket. It's not about the price. I would gladly pay for the LSP implementation. But I don't want to use IntelliJ anymore. So a new project on the JVM where I have a say in the stack? Java or maybe Scala. No more Kotlin.
    • bberrry 2y ago
      This is the biggest issue with investing in Kotlin IMHO. The stewards of the language have a conflict of interest in democratizing the tools.
      • wiseowise 2y ago
        Not only that. Their official position is sitting with smug face saying “well, duh, you’re free to roll out your own LSP and IDE implementation”, ignoring the fact that nobody outside of Google and JetBrains cares about Kotlin. And why would they? If the stewards aren’t interested in investing into healthy ecosystem.
    • owlstuffing 2y ago
      IntelliJ CE is free and destroys any LSP in terms of dev productivity. Other than consistency, why would you not use it?
  • fnord123 2y ago
    > how function pointers at the end of a method call can be auto-inserted as the next curly bracket This is one feature I wouldn't mind making it into other languages. It makes so much sense for doing UI stuff.
  • CharlieDigital 2y ago
    I recently started picking up Kotlin and to me it felt like "lesser C#". I'd personally prefer modern C# as it's been outpacing advancements in other major languages for DX, IMO. It is sad that its adoption seems to have boundaries defined either by large ecosystems dependent on the JVM or ideological.
    • t-writescode 2y ago
      Indeed. It's C# that makes me like Kotlin so much. I was trained in Java but used C# in a fully-professional setting for longer. C# as a language make a lot of very smart decisions that Kotlin took into itself when being created and out if it comes a non-Microsoft-owned (which matters for some people), comfortable, powerful language. If I had to switch and use C# as my main work language for a company, I would be perfectly happy to.
• spankalee 2y ago
  As long as they're already writing new code in Kotlin, translating the existing code makes a ton of sense, if they can do it cost effectively (which is sounds like they did). One of the huge problems with a language migration is that you're left with old and new and all the parallel tooling, context switching, and impedance mismatches. There's often a claim that the existing code will be migrated eventually, but IME that doesn't actually happen with large code bases. Then if there's ever a third migration, you're left with three languages in play. It's much better to aim for 100% migration, as close to 100% automated as possible. Then when you're done, you're really done. Maintenance, training, and the next migration will be easier.
• chasil 2y ago
  Is Oracle a factor? Does a Kotlin codebase have more safety from a legal perspective?
  • nradov 2y ago
    The legal issues around Java between Alphabet and Oracle are settled at this point and no longer a risk for third-party software vendors. But it's pretty clear that Android is moving away from Java, so anyone with a strategic commitment to that platform has to plan around that reality.
    • retrodaredevil 2y ago
      It's safe to say that Android is definitely moving away from Java in terms of new language features. I mean, if you want to support older Android versions and use modern Java features or newer parts of standard libraries, you'll usually have to rely on desugaring or making sure you're using classes that are supported in Android. IMO, Android is moving away from modern versions of Java. Java and its underlying standard library will always play a big role in Android development. The way I see it, Kotlin makes a lot of sense for Android development because Kotlin can introduce new things in its standard library that make older versions of Java look ancient. It's not like you can use new Java features in Android, so using Kotlin makes people not care as much about new features of Java that are only available in modern versions of Java.
      • pjmlp 2y ago
        Android folks were forced to acknowledge modern Java, otherwise they would lose access to Maven Central ecosystem, as everyone adopts newer Java versions. Hence ART is updatable via Play Store since Android 12, and is currently on Java 17 LTS.
        • wiseowise 2y ago
          Is it even full Java 17?
• halfmatthalfcat 2y ago
  I would argue it was Scala, not Kotlin, that has contributed to the push to make Java “better”.
  • desiderantes 2y ago
    Scala and Groovy were big pushes for Java 7/8. Their hypes died down after that release.
    • marwis 2y ago
      Where do you see pattern matching in Kotlin?
      • totallykvothe 2y ago
        In its pattern matching feature
        • wiseowise 2y ago
          Kotlin has no pattern matching. Their bootleg ‘when’ with guards is no match (no pun intended) for true pattern matching.
  • jghn 2y ago
    I would argue that Scala drove Kotlin. And over the last 10 years at least, it's been Kotlin driving Java. What I saw happen was Kotlin taking over the mantle of "better java" from Scala, and aiming for an 80/20 type language compared to Scala. And for the most part, it's those 80% that are finding their way into Java.
    • mrudolph22 2y ago
      Many of Kotlin's profound improvements will never find their way into Java because it's 25 years too late to do so. Java improves where it still can, which is the right thing to do. Sometimes Java even manages to improve on Kotlin because now it can learn from Kotlin and other languages. Nevertheless, it's impossible for Java to catch up to Kotlin, which was designed 15 years later with the explicit goal of fixing as many of Java's design mistakes as feasible for a JVM language.
• nradov 2y ago
  Meta operates at such a large scale that the engineering management decision process becomes qualitatively different from smaller organizations. They can justify enormous investments in keeping their code base fresh for small improvements in productivity and quality.
  • benatkin 2y ago
    It isn't fresh though. Java has improved a lot and the benefit of Kotlin is dubious. Maybe it has a more PHP-like feel to it. No accounting for taste at that company.
    • aembleton 2y ago
      > benefit of Kotlin is dubious What's dubious about it. Kotlin has a more comprehensive dx, and has features like extension functions that aren't on the java road map.
• m0zzie 2y ago
  The value in the conversion of existing code in this particular case isn't 100% clear to me either, but I think calling Kotlin a weaker choice than Java at this time is naive, particularly when preceding that with "there are a mountain of tools" that you can bolt on to Java to give it features that are built in to Kotlin. What makes Kotlin such a strong choice for many orgs today is its batteries-included multiplatform capability. We are able to write data models, validation logic, business logic, etc just once and compile to JVM, WASM, and native targets. For orgs with very large codebases and frontend applications (web + iOS + Android) this is an attractive capability because we can have a single codebase for a ton of core functionality, and have each frontend import a library which is native to its own platform. Of course many technologies with this promise have come and gone over the years, but this is the first one with a strong backing that has allowed us to _natively_ interoperate with each target platform. I believe these are all driving factors that have been pushing well known companies, that were previously Java shops, toward Kotlin. If you speak to a broad range of people in the industry you'll find many more orgs moving from Java to Kotlin than from Kotlin back to Java. We can simply get more work done with less code and ship to all our frontend platforms, and unless Java can do the same, I don't see the industry moving in that direction.
  • sebazzz 2y ago
    > What makes Kotlin such a strong choice for many orgs today is its batteries-included multiplatform capability. We are able to write data models, validation logic, business logic, etc just once and compile to JVM, WASM, and native targets. Not familiar with Kotlin but how does that work? Does it come included with a PAL? Because it you want to be platform agnostic, you can't for instance use a Java RegularExpression in your platform agnostic code.
    • rnentjes 2y ago
      The PAL (Platform Abstraction Layer I assume) is just the stdlib that is provided. The stdlib is not the same for all platforms, as can be seen in the documentation. A regex implementation is provided for all platforms, but is not quite the same on all platforms: https://kotlinlang.org/api/core/kotlin-stdlib/kotlin.text/-regex/ https://kotlinlang.org/api/core/kotlin-stdlib/kotlin.text/-r... In shared code you can define interfaces that have to be implemented by any platform you use.
• needlesslygrim 2y ago
  There are, at least in my opinion, many more reasons to use Kotlin than null-safety and data-classes/records, especially on Android (Jetpack Compose).
• utbabya 2y ago
  There are a lot of nice things I enjoyed when I was still working with Kotlin extensively. Null safety, data class, sealed class, exhaustive when, top level functions, object class, higher order function, extension functions etc. They fundamentally change the way dev think, producing safer, lighter and more maintainable code. Contrary to the popular notion of dismissing certain syntax differences as sugar, I consider it one of the most important factors simply because we spend more time reading than writing code. To me Java has always been verbose and dreadful to read, there's something fundamental wrong if you need your IDE generate so much then force to train your eyes to skip over most of them while reading. I find Kotlin to be more elegant and fluent especially with native syntax support of the above features. I can read it at least 25% faster than Java. Perhaps which one is better is personal taste, but I'd maintain syntax is very important, just like natural languages.
• pjmlp 2y ago
  Especially because outside Android, Kotlin Virtual Machine will never happen, it will always be a guest language on the Java ecosystem. Nothing on Kotlin will ever matter on the decisions taken by Oracle, IBM, Amazon, Azul, PTC, Aicas, microEJ, Microsoft, Red-Hat,.... on their JVM/JDK implementations and related tooling.
• graemep 2y ago
  > I’m skeptical of the value in doing this. Its Meta. They have enough money to spare not to need to worry too much about whether there is a good RoI on rewriting some mobile apps. I very much doubt FB's mobile apps are written for any sort of efficiency, (either in engineering or financial terms) - 18,000 classes in the apple one! https://quellish.tumblr.com/post/126712999812/how-on-earth-the-facebook-ios-application-is-so https://quellish.tumblr.com/post/126712999812/how-on-earth-t...
  • einsteinx2 2y ago
    Yeah Facebook was (in)famous for autogenerated code in their apps and frameworks. In fact early on they had to do some hack on Android since they had more classes in their FB app than was supported by the operating system lol. So super inefficient binaries, but I guess more efficient to develop (or I assume that was the idea)?
    • LegNeato 2y ago
      You are getting the details wrong (I was there). This was the single DEX limit, and Google would just bump it in AOSP every time their own apps hit it (as their apps didn't support older OS versions). FB at the time was supporting back to froyo, which had a much lower limit than "modern" apps needed. See this note for more info: https://www.facebook.com/notes/10158791578712200/ https://www.facebook.com/notes/10158791578712200/
      • einsteinx2 2y ago
        Thanks for the clarification! Yeah I only vaguely remember the story from reading about it when it was new, so it’s been a while haha
    • ignoramous 2y ago
      > was supported by the operating system By the Dalvik Virtual Machine (DVM). 65k method limit is what Facebook hit. tbf, DVM was engineered to run on embedded systems with 64MiB RAM (as a replacement for J2ME).
• unscaled 2y ago
  The nice thing about null-safety in Kotlin is that it is built-in and it requires no extra annotations or added tooling. Not having @ProxySingletonAbstractJunkFactoryFactoryBean sprinkled all over your code does it ever so slightly more readable. But if built-in null safety and lower verbosity was all that Kotlin had to offer I doubt it would have won. Kotlin offers a lot more features that Java does and most probably will not offer in the next 10 years: - Extension methods: No more terrible FooUtil or BarHelper classes. - Context parameters (preview feature) - Coroutines (they are not just about concurrency - you can use them to write generators as well[1]). - Keyword arguments: This makes using constructing data classes possible without generating builders, and in general lets you deal with multi-argument methods in a safer and more readable way. It also cuts down the boilerplate of defining 20 different overloads that call each other. - Interface Implementation by delegation: This feature makes it easy and painless to follow the motto "composition over inheritance". Java makes implementation inheritance 50 orders of magnitude easier than composition with manual delegation, so it's pretty natural that the vast majority of Java code- bases overuse inheritance in very bad ways. - Properties: This reduces the need to worry about direct field access causing API breakage in the future, and removes the need for the absolutely massive boilerplate associated with getters and setters in Java. It's true that records remove the need for that, but records only work for purely immutable data classes (and right now they are only practically usable with a small number of fields). - Delegated Properties: Not something I use every day, but it's very useful when I do use it. - Unsigned integers (specifically bytes): Writing any byte-wrangling code in Java is a downright nightmare. - Reified Generics: Java may get something equivalent to that with Project Valhalla, but I'm not sure how comprehensive it would be. - If expression: Java made switch an expression with JEP 361, but if is still a statement. This leads to a lot of bloated and somewhat unsafe code where you have to define a variable before the if and then assign to he variable in each branch. - Expression Bodies for function: This is a very small feature, but it's pretty nice to cut down boilerplate and make functions more readable when you need it. DSL Features ------------ Kotlin is perfect for DSLs thanks to features like: - Closure blocks: Kotlin lets you pass the last closure argument to a function as a block of code inside curly braces that follows the function call. This features lends itself very well to readable DSL. In Java you would need to embed the closure inside the function argument list and add an extra parentheses. This gives you some of (see the next couple of points) the DSL capabilities of Kotlin, but the DSL becomes very hard to read and use when a lot of blocks are involved. There is a good reason why Kotlin DSLs are based on blocks, while Java DSLs are based on the less-flexible fluent interface pattern: block-based DSLs are just too hard to read and write in Java. - Inline functions: Inline functions allow the compiler to perform some optimizations in advance that may be harder for the JIT to do (namely inlining the provided block closures), but the real kicker is that you can use flow control statements (break, continue and return) that affect the calling scope. - Multiple "this" in context. You can have multiple values for this inside a nested scope. The compiler manages to find the right reference for the "this" alias based on your usage, but in case of ambiguity (where the deepest "this" wins), you can disambiguate your choice. This feature sounds overly complex and unnecessary at first, but it allows a lot of power for the Kotlin DSL system. - Closures with this receivers: Using the multiple this values from above, you can have closures that receive their own "this" to introduce DSL methods. Being able to introduce these methods without shadowing the "this" from the parent context is crucial for powerful DSLs. - Infix functions and operator overloading: Needless to say, these features make DSLs even nicer. I've probably skipped a couple of features I can't recall right now, but I hope that it shows that Kotlin is a lot more than just "Java with null-safety and data classes" as some people think. [1] https://kotlinlang.org/docs/sequences.html#from-chunks https://kotlinlang.org/docs/sequences.html#from-chunks
• wiseowise 2y ago
  Say thanks to Google who basically stopped developing stuff with Java in mind.
• npalli 2y ago
  Most important reason for the rebirth of golang (after it's initial dip in early '10s) and wide spread adoption of Kotlin is the ownership of Java by Oracle. It doesn't matter what fine print exists, but everyone knows what kind of a*holes Oracle and Larry Ellison are, they will find a way to squeeze you. Everyone is going to sprint away from Java as soon and as much as possible. For someone like FB, Kotlin being a nicer language is just cherry on the cake.
  • smusamashah 2y ago
    But doesn't Kotlin compile to Java?
    • Cyph0n 2y ago
      No, it compiles to Java bytecode that runs directly on the JVM.
• jillesvangurp 2y ago
  Java did improve over the years. But it still defaults to doing basically everything wrong by default. Parameters are non final, classes are open, things are mutable, etc. It's unsafe by default. And it's hard to fix because it breaks backwards compatibility. Kotlin doesn't have that problem and it has been doing the right thing by default for a long time. It's still getting better. I think on Android the choices are either to start from scratch or to migrate to Kotlin for Facebook. Sticking with Java on Android just makes everything harder. All the new frameworks are Kotlin centric. Most Android developers they'd be hiring would have been using Kotlin for years. Etc. So, I can see why Facebook is making the effort to keep their code base alive and future proof. Android is more Kotlin focused and has been for years. And that's only going to be more the case now that compose multi platform is a thing. Btw, most of the stuff you mention is probably more applicable to server side Java and less to Android. IMHO, Spring + Kotlin is a very nice combo on servers. Very well supported by Spring and they bundle a lot of convenient things for Kotlin. And I don't need any of the tools you mention because it does the right thing by default.
  • Tainnor 2y ago
    > And I don't need any of the tools you mention because it does the right thing by default. I mostly agree with you, but Spring+Kotlin does require the allopen plugin, so it's kind of hacking Kotlin to do the wrong thing (all classes open) in order to support an arguably bad design choice by Spring.
    • bberrry 2y ago
      Can't blame Kotlin for that. And it's a very minor sin frankly.. set-and-forget.
      • Tainnor 2y ago
        I don't blame Kotlin for it, I blame Spring for it.
    • yearolinuxdsktp 2y ago
      all-open plug-in is the only sane way to operate Kotlin.
• fngjdflmdflg 2y ago
  >I think Kotlin helped push Java in the right direction, but at this point it seems like a weaker choice. Nobody wants to use a mountain of tools just to achieve basic feature parity with other languages. Also java syntax is awful.
  • neeleshs 2y ago
    The newer version of Java has much better syntax.
  • irunmyownemail 2y ago
    Personally, I love Java syntax, or did before Java 8. It's still better than Kotlin though. At least it gets the type and name in the correct order.
    • int_19h 2y ago
      What makes it the "correct" order?
      • RedComet 2y ago
        It is probably more that Kotlin's order breaks with the most common ordering, and at the cost of more characters. Not to mention the needless variation that has come along with it (e.g. : vs ->)
        • wiseowise 2y ago
          Arrow is a lambda, just like in Java.
          • RedComet 2y ago
            I'm referring to the burden when changing languages. Swift and Rust use -> for the return type.
            • 2y ago
• eikenberry 2y ago
  How do they compare tooling wise? Kotlin's K2 compiler targets more platforms than the JVM which seems like an advantage.
• datavirtue 2y ago
  I'm trying to unfuck a C# codebase that was converted from Java by some tool. It did an OK job (nevermind the reasons for all this) but no one went through and resolved the problems that don't cause a build failure. These conversions have a blast radius of unknown proportions.
• imtringued 2y ago
  Java is still horrible. Every time I go back to Java it seems like nothing has changed and I say this from the perspective of using a JVM language that is 9 years older than Kotlin.