19 ms·

From zero to 10M lines of Kotlin

309 points by binkHN 4y ago

deleted 4y ago
[deleted]
dinvlad 4y ago
It's too bad other IDEs (like VSCode) have only a primitive support for it. That means Kotlin is only ever usable with an IntelliJ license, and forces one to use this particular IDE.
commitpizza 4y ago
One thing that Kotlin got going for it is the tooling. I mean, the creator of Kotlin creates some of the best programming tools out there so I'd imagine (without actual experience of Kotlin) that it has great tooling. Sometimes, the tooling is even more important than language features IMO. It makes developers move quicker, find bugs easier and so on. I like the idea of Kotlin, that it can compile to jvm bytecode, javascript and native. So in essence, I can use the same language everywhere in the true meaning of the word.
- kramerger 4y ago
  Obviously kotlin has great tooling, coming from an IDE company. But I think the main strength of Kotlin is it being so damn developer-friendly compared to Java and Scala.
  - commitpizza 4y ago
    Do you know of any good backend web frameworks for Kotlin? I would wish for something like FastAPI for python. Kotlin may actually be a great fit for a service I want to build and I hadn't really thought of it as an option until now.
    - arein3 4y ago
      Spring Web MVC
    - danieldisu 4y ago
      Micronaut, http4k
    - xwowsersx 4y ago
      Ktor https://ktor.io/ https://ktor.io/
    - malsanton 4y ago
      Javalin https://javalin.io/ https://javalin.io/
    - piaste 4y ago
      If you want something old and battle-tested, Spring Boot works just fine in Kotlin. I found the extreme OO design kinda off-putting, but once I got over it I had a great time with it. KTor [0] is the 'native' web framework for Kotlin, and there's also a full-stack framework built around it that just hit version 1.0, KWeb [1]. [0] https://ktor.io https://ktor.io [1] https://kweb.io https://kweb.io
      - commitpizza 4y ago
        Well I care more about simplicity and easy to develop in rather than battle-tested. Something like the Javalin or http4k would probably suit me the best. Of course, I have checked Ktor before, but I don't know if I particularly fancy the way they are structuring stuff. My main issue with the java ecosystem is that it's way to enterprisy for my taste. Everything is so unnecessary complex and hard to reason about, but I will take a good hard look at Kotlin before making my decision. The thing is that I am really interested in the native compilation that Kotlin offers that would be very beneficial for me and the only reason behind picking Python otherwise would be that it is a nice language and already installed on the linux environments it will run in. Basically I will have a big api and drop (preferrably) a single binary to some machines that will talk to the api. These machines will generally be outside of my control. I have looked a bit on Rust but it seems a bit too low level and hard to work with. I have looked at Deno because it can compile down to a binary but using javascript for this project seems like a bad choice. So I chose Python at first because it seemed easy to get going with, had great tooling and is already installed in the environments I will be dropping a script in.
  - halfmatthalfcat 4y ago
    There's been a lot of work in Scala land to improve tooling, see Mill as an SBT replacement.
  - barrenko 4y ago
    If only Kotlin had Scala's frameworks.
- nordsieck 4y ago
  > Sometimes, the tooling is even more important than language features IMO. It makes developers move quicker, find bugs easier and so on. I like the idea of Kotlin, that it can compile to jvm bytecode, javascript and native. The only thing I'd worry about is Java overtaking it. Do you remember Coffeescript? There was a point in time where it had impressive adoption, and quite a bit of buzz. But then Javascript added features, and all of a sudden the tooling burden associated with Coffeescript just didn't make sense any more. With Oracle's 6 month release schedule, that's a distinct possibility. Especially since Java can no longer rest on its laurels as a language (if Oracle doesn't want it to become Cobol 2).
  - draw_down 4y ago
  - ajkjk 4y ago
    Wasn't it Typescript that made CoffeeScript obsolete? Not better JS
    - tentacleuno 4y ago
      Really, it was a combination of both.
    - Betelgeuse90 4y ago
      IIRC the main appeal of CoffeeScript was syntactic sugar like lambda expressions etc that were missing in ECMAScript 5. I think ECMAScript 6 made most of the appeal of CoffeeScript obsolete
      - jgalt212 4y ago
        The availability of lodash made us dump any ideas our shop had about widespread coffeescript use.
      - tinco 4y ago
        When CoffeeScript came out, I vowed never to write plain Javascript again. I kept to that vow for a couple years, but eventually broke it when ECMA 6 came out. Really the only thing that put real technical justification behind CoffeeScript was the double arrow function, and maybe the neat class syntax. Beyond that CoffeeScript is just prettier. Even though I was in charge of choosing the technologies, you got to skate where the puck is going, and the puck was clearly not staying with CoffeeScript. ECMA 6 copied all the good parts out of both CoffeeScript and jQuery, effectively obsoleting both. Modern JavaScript is almost unrecognisably different from what it used to be, and that's a very good thing.
- barbariangrunge 4y ago
  The biggest advantage of a statically typed language over a dynamic one is the tooling. Refactoring statically typed code, after working with JavaScript for a few years, feels like magic because the tools just make it work
- dima_vm 4y ago
  As for me the greatest appeal of Kotlin is that it doesn't need its own tooling that bad, it feels like just syntactic sugar over Java. Both Scala and Kotlin can reuse Java tools, but with Scala it's awkward (and some tricky generics simply don't compile with Scala). E.g. if I need to parse something, I search for "how to parse that in Java", not "... in Kotlin".
  - hocuspocus 4y ago
    > and some tricky generics simply don't compile with Scala What? Do you have any example that wasn't fixed years ago? Any non-trivial Scala app will consume dozens if not hundreds of Java libraries, without any issue.
    - dima_vm 4y ago
      I filed an issue for Scala in 2009, that was answered like "sorry, this particular Java code cannot be used in Scala". In 2012 it still wasn't fixed. I cannot find the issue now, but I remember I was trying to use gae-mapreduce-java library (built on top of Hadoop interfaces). It couldn't compile with Scala.
      - hocuspocus 4y ago
        That's eons ago in Scala world. If you can, give it another try. I would assume such a bug was fixed in Scala 2.x given the prevalence of the language in the hadoop ecosystem and big data frameworks. Moreover Scala 3, was the opportunity to fix many previously-unfixable corner cases.
- deleted 4y ago
  [deleted]
- SpaghettiCthulu 4y ago
  Have you ever actually tried kotlin native? Compiling a "Hello World" program takes at least 5 seconds. That's absolutely absurd.
- JAlexoid 4y ago
  > Sometimes, the tooling is even more important than language features IMO. That would be always. Tooling makes or breaks pretty much every language. Language itself is just a syntax that you write in.
voganmother42 4y ago
“In recent years, Kotlin has become a popular language for Android development. So it only makes sense that we would shift our Android development at Meta to Kotlin as we work to make our development workflows more efficient.” I like Kotlin, but this was pretty funny to me: I imagined walking into a meeting and trying to tell colleagues we needed to move to X because it was popular, then yeet out the ole “efficient”, mic drop & moonwalk out
- washywashy 4y ago
  Happens so much more often than you think. Have actually seen it with the exact same language (Java->kotlin) on an existing service. I don’t really recall any valid reasons being given for the switch (better support for concurrency etc). I think often times managers allow this bc they don’t want certain engineers to get bored and leave, which is odd to me since who knows why/when they will leave and they won’t take the services with them.
- deleted 4y ago
  [deleted]
- hdjjhhvvhga 4y ago
  It happens all the time. I remember when AWS wall all the rage my boss came up and told me we need to use S3. Why? "Because everybody is using it!" I tried to reason, I did a cost analysis - all for no avail. The same boss a few years later: "Why are we paying so much for storage?!" He apparently forgot he insisted on it in the first place.
  - einpoklum 4y ago
    I'm 100% sure there's a Dilbert strip with exactly this scenario.
- belmont_sup 4y ago
  I read it more as they now have kotlin and want to simplify new project decisions to just kotlin. I find this similar to how rust is being added to the Linux kernel.
justplay 4y ago
I thought that they were using react native. Isn't that true now?
- rapsey 4y ago
  No the entire app is not react native. Only parts of it.
- david_allison 4y ago
  The native modules still need to be written against Android (these are typically either Java or Kotlin, plus maybe some native code).
DeathArrow 4y ago
Ye still use good ol' PHP on yer backend?
- moreira 4y ago
  According to them[0], Facebook's primary languages are C++, Java, and Python, and they're even embracing Rust now. In general, teams have the freedom to choose what languages and technologies they want to use. (quoting from the linked video) They might've started with PHP, but even that stopped being a thing once they switched to Hack, their home-grown language, ~10 years ago. [0]: https://engineering.fb.com/2021/04/29/developer-tools/rust/ https://engineering.fb.com/2021/04/29/developer-tools/rust/
  - hu3 4y ago
    Not quite. According to a more recent article, Facebook's PHP, Hack, is still a primary language: > For business logic and relatively stateless applications, the Hack ecosystem has the highest level of automation and support at Meta and is the recommended language. On a related note, their Rust usage has grown significantly: > For performance-sensitive back-end services, we encourage C++ and Rust. Rust is a new addition to this list. There’s a rapidly increasing Rust footprint in our products and services, and we’re committing to Rust long-term and welcome early adopters. For CLI tools, we recommend Rust. This is a new recommendation for this year. https://engineering.fb.com/2022/07/27/developer-tools/programming-languages-endorsed-for-server-side-use-at-meta https://engineering.fb.com/2022/07/27/developer-tools/progra...
- deleted 4y ago
  [deleted]
david_allison 4y ago
One of the things they don't mention is that J2K makes you pick between: * A conversion in 1 commit: complicating/breaking the 'follow' behaviour of 'git blame' * A conversion in 2 commits: the first 'rename' commit doesn't compile, complicating/breaking 'git bisect' I hacked up a script which makes the 'rename' commit compile (when I was working with a ~100KLOC Kotlin conversion). This may be useful for others: * https://github.com/ankidroid/Anki-Android/blob/937a6560913ec383ab71a6a1b704b815b5ad88a8/AnkiDroid/kotlinMigration.gradle https://github.com/ankidroid/Anki-Android/blob/937a6560913ec... * https://github.com/ankidroid/Anki-Android/blob/937a6560913ec383ab71a6a1b704b815b5ad88a8/tools/migrate.sh https://github.com/ankidroid/Anki-Android/blob/937a6560913ec...
fn1 4y ago
Off-topic, but how the Facebook, Messenger or Instagram-app need a million lines of code is absolutely beyond me. I had a few encounters with facebook's opensource code (mostly around react-native) and it is generally subpar in my opinion.
- tantalor 4y ago
  This happens with "everything" apps that have hundreds of features you have never seen, each serving a tiny fraction of the userbase who somehow stumbles on them and justifying the PM/eng resources to keep them chugging along, or abandoned and left to rot until these migrations come along.
- mkl95 4y ago
  My guess is that it's an extreme case of Conway's law, with many teams that produce mountains of code hidden behind some API. Not to mention codebases provided by external firms, which could amount to a large % of all those KLOC. I'm interested in how they avoid "Roman empire syndrome", as in owning more software than they can maintain while actively expanding it.
  - barbariangrunge 4y ago
    Rome held on to its land for a while. More like napoleon or Alexander syndrome
- deleted 4y ago
  [deleted]
- aeyes 4y ago
  Facebook is primarily a message and photo sharing application but it also has group boards, dating, live video streaming, a marketplace, browser games and probably more features. Then there are all the features for targeted ads, tracking, payment and so on. All of this is available almost all around the world. How do you implement these features for more than a billion active users in less than a million lines of code? Even 100 million sounds like a low estimate. Why does the Linux kernel have more than 30 million lines of code? You could ask if these features make sense. But in the end it is their business decision to make.
melling 4y ago
“Shorter code: Kotlin’s modern design makes its code shorter.” How much shorter? How large would the code be in pure Java?
- belmont_sup 4y ago
  What’s pure Java?
- david_allison 4y ago
  Expect a 10-30% reduction with J2K, maybe another 5% once manual refactorings are made.
- strulovich 4y ago
  We actually made this number public in the post. It just appears laters around the conclusions sections. > On average, we’ve seen a reduction of 11 percent in the number of lines of code from this migration.
  - melling 4y ago
    I was hoping for more but 11% is still significant. So that’s an extra million lines of code that didn’t need to be debugged.
    - krzyk 4y ago
      I wonder how much of this could be reduced if they used records in Java.
    - kaba0 4y ago
      An extra million lines of {, @NotNull, .stream(), .toList(). Hardly any code that would actually have bugs.
      - strulovich 4y ago
        We have a consistent braces style, so the lines that are removed are rarely those. A lot of the saves come from `?.` replacing null check chains. Many more from the shorter constructor and field initialization syntax (you can get a bunch of things in one short statement). A bunch more from usage of standard library lambda taking functions (`first`, `single`, etc.). Some more just comes from shorter lines due to less explicit types. These are all more some guesses due to conversions I've seen, and not the result of accurate analysis. We also use very little Java streams. A combination of Java 8 arriving late to Android code, and the preference to avoid extra allocations and inefficiencies streams can cause for shorter lists.
naikrovek 4y ago
can someone explain how Meta's code is so large? the tradeoff for high level languages is supposed to be that you gain a lot of expressivity (requiring fewer lines for a developer to express their intent) and you lose performance because of the multiple layers of abstraction required. 10 million lines of code for an Android app, or family of apps, feels like the tradeoff has definitely not born fruit. operating systems written in Assembly have far fewer lines of code than this.
- TillE 4y ago
  Whoa. At first I didn't blink at 10M lines of code, but you're right they're talking strictly about Android. You have to factor in Instagram and WhatsApp, but still...that's a lot of code.
  - naikrovek 4y ago
    it really is. a sibling comment of yours points out some info posted by a former Uber engineer about why, and even considering that, 10 million lines seems extremely high. Windows XP is smaller than the Facebook app for Android...
- david_allison 4y ago
  Past discussion on why Uber's app is so big, many of the points are relevant: https://news.ycombinator.com/item?id=25376346 https://news.ycombinator.com/item?id=25376346
  - jrvarela56 4y ago
    This comment is a gem. Every HNer who has thought 'why do they need 100 engineers, I could do that in a weekend' should go read this now.
    - criddell 4y ago
      > why do they need 100 engineers You're off by an order of magnitude. Hundreds of developers? Sure. But Uber has thousands of developers.
Kukumber 4y ago
If i were to do JVM related stuff, it'd use Kotlin without hesitation That language, just like with Swift and Haxe, they remind me of the good old Flash/ActionScript 3, i loved that language so much It's imo the best form of a programming language one can come up with, very easy to learn, read and write I wish kotlin-native story was better, it's a shit show, super slow to compile, and they decided to go with Gradle... it is on the same level of confusion and bloat as CMake, a pure mistake
einpoklum 4y ago
deleted 4y ago
[deleted]
peter_retief 4y ago
Good idea, I learnt Kolin to avoid having to use Java for android development. Only for one app it was still worth it
denismurphy 4y ago
That app needs to go on diet. iOS 310.6 MB Android 367.7 MB
- Macha 4y ago
  How much is kotlin vs high res assets or shipping every experiment to turn them on/off with feature flags? I suspect the language contribution is actually pretty minimal
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]
seanalltogether 4y ago
I've found that migrating all your trunk code (data and infrastructure classes) to kotlin is the biggest win, and you can leave your old leafs (fragments and view models) in java if you want do a low risk migration. If a view isn't broken, you don't need to fix it, but getting nullability annotations in your data models and REST commands is a huge win for newer views and business logic going forward.
strulovich 4y ago
Hi HN! I’m the author of this post. I’d be happy to answer questions here on this subject!
- johnwheeler 4y ago
  I know it’s not the NYT, but just curious how it feels to wake up and see your work on the front page of HN
  - strulovich 4y ago
    It’s pretty nice. :) This post is the (pretty short) summary of a lot of work which took us a long time to do. So it’s nice to get any kind of validation. Personally I read HN a lot and it’s my main source for interesting articles nowadays. So that makes me appreciate HN upvotes even more.
    - deleted 4y ago
      [deleted]
      - throwaway123f 4y ago
  - pantulis 4y ago
    For us hackers, it's better than the NYT!
    - AnimalMuppet 4y ago
      Yeah. NYT reporters don't show up here to answer our questions.
- hu3 4y ago
  1) Is that a mono repo? 2) If not, how many LOC is the largest Kotlin repo? 3) How do you tackle challenges of large codebases like language servers/synthax highlighting crawling to a halt in IDEs?
hardware2win 4y ago
~~Microsoft's Java~~ Jetbrains' C#
- deleted 4y ago
  [deleted]
dr_faustus 4y ago
I'm currently working on a project which has both Java and Kotlin and I really have to say that I like working on the Java parts much better than on the Kotlin parts. I find coroutines a really strange and leaky abstraction (and the prevalence of suspend methods in libraries which you have to wrap all the time just to call them synchronously is really annoying). With streams and the var keyword, Java is also not that much more verbose anymore than Kotlin and the code completion, error detection and refactoring capabilities are much better in Java. In Java I can also be sure that if I directly access a property on a class, there will be no side effects or expensive operation while if I use a getter, there might (and I dont have to write them either due to code generation or Lombok). So the parts where Java is still more verbose actually add clarity (and again, due to the IDE, you rarely have to type any of it): I dont really get why I would leave out the explicit types in the source code, only to be added again as non-editable, weirdly positioned text by the IDE (which is not there if just wanna have a quick look at the code on GitHub).
- krzyk 4y ago
  And with records you mostly don't need Lombok (unless you really like builders and can't wait for withers in Java).
  - bdangubic 4y ago
    Records not being extend(able) is the reason why Lombok is still mostly needed...
    - kaba0 4y ago
      Why would you need extend over implements? I found sealed interfaces with records really cool.
  - vbezhenar 4y ago
    JPA requires mutable classes. Records ergonomics is terrible if you want to replace data classes with records, even if immutable is OK. You need to write builders. You can't really write code like new Person(id, null, null, null, lastName, firstName, null, null, null, null, null, null, null, age); Withers can help with that, but they're not even in any kind of experimental shape right now, so we have many years to wait for it. Right now records are only fine for very simple use-cases like Point(x, y). Or if you want to write or generate builders. But at this time you don't really save anything, if you can generate a builder, you can generate a class as well.
nu11ptr 4y ago
Every time I think I maintain large code bases I just need to remember that someone else has a LOT bigger one. Wow, that is a LOT of Kotlin code.
fiejvs72iwbev 4y ago
I am pretty sure, people who build Facebook or Messenger apps for Android does not use the app. If you use Facebook or Messenger for more than 10 minutes, you would find at least 2 very fundamentally wrong bugs. I would have fired most of the developer if I were the CEO of Facebook. They are not competent to work at Facebook
- deleted 4y ago
  [deleted]
gavinray 4y ago
I wanted to post that ktfmt, the FB Kotlin formatter, is much less well-known than ktlint. IMO, it produces the most (subjectively) readable code, and is the only one that doesn't leave room for you to inject personal style in certain places. (ktlint will let you get away with one of several ways of formatting code, so long as it falls within some guidelines, which can lead to inconsistent formatting). It's a superior formatting tool IMO. https://github.com/facebook/ktfmt https://github.com/facebook/ktfmt
- deleted 4y ago
  [deleted]
- BoorishBears 4y ago
  I had it act generally "weird" when adding it to our codebase and ripped it out. Sometimes it'd hang for several minutes, memory usage would spike from time to time. Didn't have time to bother debugging when ktlint just worked immediately.
  - strulovich 4y ago
    When was that? IS that a big codebase? I fixed a memory leak issue a few months ago that would have a big effect when running over hundreds of files at once.
    - BoorishBears 4y ago
      More than a few months ago, and a fairly large codebase (~1000 files). I might give it another try for some personal projects since I did like the anti-bikeshedding angle with respect to configuration, but yeah linting can be a hard sell once build performance starts to suffer for it
      - strulovich 4y ago
        Most likely this fix would make a big difference then: https://github.com/facebook/ktfmt/commit/6ea9e8f461853c32177f3a3bc0d2ae4ea5718452 https://github.com/facebook/ktfmt/commit/6ea9e8f461853c32177...
bmc7505 4y ago
Having used Kotlin on and off for the better part of a decade, the one thing I can say is that their editor support is unrivaled by any other language today. While Kotlin's build tools leave much to be desired (looking at you, Gradle), their focus on building a "toolable" language was the right thing to lean into. You can add all the fancy type system features you want, but if the IDE does not understand them, convincing users is going to be a hard sell. Whenever I try to get into another language today, the lack of language-aware editing tools are my main source of frustration - specifically, I expect navigation, refactoring and completion to work flawlessly. I know of no other programming language that puts as much effort into context- and structure-aware refactoring - if another language does one day replace Kotlin, it will need to offer a comparable editing experience.
- srcreigh 4y ago
  Have you used TypeScript? Not only is it better type system than Kotlin, it has great IDE support in VSCode, AND there’s a language server so you can get IDE support in Emacs/vim.
- purplerabbit 4y ago
  Have you tried TypeScript? My impression having used it in both JetBrains and VSCode is that it achieves basically what you're describing. I similarly get irritated using anything else now.
  - randy909 4y ago
    I've used both and Kotlin was a better overall experience for me. TypeScript has weird typing problems far more often due to the underlying runtime being dynamically typed.
    - purplerabbit 4y ago
      What problems in particular have you run into? Genuinely curious.
      - 4y ago
davidatbu 4y ago
I'll bring up the Kotlin LSP[0] every time I see Kotlin on HN because I really hope the LSP takes off (which would make it viable to use Kotlin with a non-IntelliJ editor). Kotlin as a language looks really cool, but I don't want to give up terminal-based, modal editing (which I'd have to in order to use IntelliJ). Along those lines, I once tried diving into using Gradle outside IntelliJ, and I couldn't find any good resources to help with that. If folks have hints/links-to-blog-posts with regards to that as well, that'd be great! [0] https://github.com/fwcd/kotlin-language-server#this-repository-needs-your-help https://github.com/fwcd/kotlin-language-server#this-reposito...
- valenterry 4y ago
  I think the LSP for Scala works really well. It's not Kotlin, but you might want to try it out.
  - davidatbu 4y ago
    Thanks for the tip! I keep reading on HN and elsewhere that Scala's feature-full-ness encourages complex/unmaintainable code, but I gotta check out myself.
    - valenterry 4y ago
      Totally the opposite - I think that's really from Scala's first versions of so. But Scala has a steep learning curve for the advanced techniques and the compile times can be very annoying when using those. And if you don't use the advanced techniques, you might as well pick Kotlin or Java instead.
      - davidatbu 4y ago
        Thanks. My interest is piqued now for sure.
- LinXitoW 4y ago
  I'm sure you're aware it exists, but the Vim plugin for IntelliJ is actually good enough, imho. Might be worth a try.
auraham 4y ago
The only thing that prevents me from using it is the license that shows up during installation. Has anyone read the license? The same applies to Dart (Flutter).
yotamoron 4y ago
How come we are reading content from this horrible corporation?
mpweiher 4y ago
Interesting that they were able to quantify the reduction in source code length very precisely (11%), but when it came to the regression in build times ... nada ... just talk about how they plan to mitigate the issue.
- peheje 4y ago
  Same thought. We can only speculate but I'm guessing the compile time is much worse.
- strulovich 4y ago
  We don't have numbers around this because the numbers are actually really hard to make sense of. This probably sounds a bit weird, and it surprised me at first. Unfortunately measuring build times is extremely noisy: different people build different things. They do so at different times. On top of it we have incremental builds (so only some part, depending on the modularity and some external and in-house optimizations, gets rebuilt). The incremental builds depend on cached artifacts that need to be downloaded, and many more complications. The result is that if you look at the graphs the values jump up and down based on time, days, moods, network, and many more causes, plenty of which we have no idea what they are. I have not yet seen a successful attempt at cleaning this data up so that some number would be worth publishing. We could try building some toy example that we separated. But that won't be useful to guide our work on build times, nor do I think that it will be valuable to share with the community.
  - mpweiher 4y ago
    > the numbers are actually really hard to make sense of. 1. Then how do you know builds are slower? 2. How will you know that the things you are doing to improve build times are working? > jump up and down based on time, days, moods, network, and many more causes, plenty of which we have no idea what they are. 3. Performance being highly inconsistent is actually a (significant) performance problem itself and worthy of reporting, analysing and quantifying. (ranges, averages etc.) > not yet seen a successful attempt at cleaning this data up so that some number would be worth publishing. 4. Not sure why you think they need to be "cleaned". Again, numbers being all over the place is likely an important data point in itself, an even if it isn't the raw data would be valuable. > We could try building some toy example that we separated. Why? Just do a clean build on a local machine. Report real and user+system time. (man time). Repeat.
latenightcoding 4y ago
I'm interested in exploring Kotlin for backend development. But, most Kotlin projects, articles and anecdotes center around mobile apps. I imagine companies hiring Kotlin developers would mostly get applications from people with mobile dev experience
- fhd2 4y ago
  Maybe it's the wrong circles? Pretty much all the Kotlin developers I know (like four) do backend work.
- jillesvangurp 4y ago
  There's very mature and widely used Kotlin support for Spring Boot. They've been actively supporting Kotlin for years and it's a well documented and well supported option in that space. Same for many other Java frameworks (e.g. Quarkus, Vertx, etc.). The reason is that it's so easy to integrate just about any Java framework from Kotlin and make it nicer by adding a few extension functions, turning builder soup into more readable Kotlin DSLs, getting rid of all the getter/setter madness or silly hacks like Lombok. I've converted a fair bit of Java code to Kotlin. You almost always end up with better code. Certainly less of it. The notion of Kotlin being a mobile only thing emerged out of the happy accident that the need to get rid of Java was simply felt so deeply in Android that developers were all over Kotlin even before it was released properly. Backend developers waited a bit longer. As a drop in replacement for Java it made a lot of sense there. Google at the time had the whole platform stuck on Java 1.6 while they were engaging with Oracle in the courts. So a lot of the nice stuff in 1.7 an d 1.8 was not usable and forget about all the stuff that was added to Java and still is being added. Most of that you could get with Kotlin right then and there. So, people jumped on it. For the same reason, people have been using Kotlin with Spring since about the same time. Google and Spring made it official around the same time as well with Google outright labeling it as the preferred language for Android (while not cutting off Java) and Spring just adding an enormous amount of Kotlin specific features and extensions starting with Spring 5 and Spring Boot 2. At this point both have documentation for both Java and Kotlin. There are really no downsides to using Kotlin on the server. You can do everything you could do with Java and you gain access to a lot of easier to use stuff than the Java equivalent. I've been using it since before Spring supported any of Kotlin. Worked fine then and it only got better since. The language alone is worth switching and once Spring started actively supporting it, it only got better. I write asynchronous co-routine code with Spring by default. Mostly it just looks exactly like synchronous code. The only way you can tell is that my controller functions are suspend functions. Spring takes care of the rest. That makes everything easier: more readable logic, error handling, etc.
cies 4y ago
We're transitioning to Kotlin. And our main problem with it is slow compilation. With only Java is was <2mins and we're touching 10mins now. I'm not sure what exactly the problem is as we still have to investigate. Our use of Kotlinx.html (which we absolutely LOVE as HTML templating tech) seems to be a part of the problem, but we have not gone to the bottom of it yet. Nothing against the language, everyone on the team loves it (when Java is what we consider normal). The extra type safety we get out-of-the-box or have put some effort into (using KFunction all over the place) is really paying off.
hit8run 4y ago
Delete Facebook.
jdhzzz 4y ago
why does navigating to this document, open a new tab, close the old tab. The result being there is no history that the "back" button (FireFox here) can get to. Seems like a lot of trouble to go to just to annoy me.
- ahahahahah 4y ago
  More likely a big in Firefox... But sure just imagine it's whatever nefarious thing you want.
tannhaeuser 4y ago
What's the story with Android and iOS cross development using Kotlin? Any major benefit over Java (which used to be a thing at least in the days of j2objc)?
- JamesSwift 4y ago
  KMM (kotlin multiplatform mobile) just hit Beta status. Its a really unique value proposition compared to other cross platform options in that it doesnt run via a VM (either Javascript or e.g. Mono for Xamarin). It compiles to native LLVM on ios, and as such you can write your UI natively if you want. I was holding off on KMM before, but I've started looking lately and its extremely promising. There is still a lot of ecosystem that needs to be built out (e.g. you need to find cross platform / pure kotlin implementations of URI or Color), but it is shaping up to be the leader in the space IMO.
  - kaba0 4y ago
    Why would anyone use it if you can’t take advantage of the vast Java ecosystem? Why would I choose it over Graal for example, which has much bigger backing, stable and is language-agnostic.
    - JamesSwift 4y ago
      You can take advantage of Java in the next layer up, but you lose out on sharing that portion of code/logic then. There are actually 3 layers in play for each platform: The pure kotlin shared layer, the "native" kotlin shared layer, and the native-native layer. That second layer (the native kotlin shared layer) is platform-specific kotlin. So on JVM platforms thats the normal Kotlin you are used to, and as such it has access to Java. On iOS that second layer is Kotlin/Native, and you actually have access to native _bindings_ to the native layer (i.e. I can call into UIKit, but in Kotlin code). If you put your "native" code in the second layer instead of the native-native layer (which on iOS is Swift/objective-c), then you can move that into the innermost layer if/when it makes sense over time, and the frontend is none the wiser. Here is a good visual and explanation (the rest of the presentation is a good overview as well, but I think this slide is the best part of the video): https://youtu.be/2yd6rVJdICU?t=1749 https://youtu.be/2yd6rVJdICU?t=1749 EDIT: I should also note that nothing prevents you from creating "glue" bindings in the pure kotlin layer using either expect/actual or an interface, and then reifying that using some JVM thing in the second layer, and writing the other platforms more from scratch to fulfill the contract.

309 points by binkHN 4y ago

deleted 4y ago

[deleted]

It's too bad other IDEs (like VSCode) have only a primitive support for it. That means Kotlin is only ever usable with an IntelliJ license, and forces one to use this particular IDE.

commitpizza 4y ago

One thing that Kotlin got going for it is the tooling. I mean, the creator of Kotlin creates some of the best programming tools out there so I'd imagine (without actual experience of Kotlin) that it has great tooling. Sometimes, the tooling is even more important than language features IMO. It makes developers move quicker, find bugs easier and so on. I like the idea of Kotlin, that it can compile to jvm bytecode, javascript and native. So in essence, I can use the same language everywhere in the true meaning of the word.

kramerger 4y ago
Obviously kotlin has great tooling, coming from an IDE company. But I think the main strength of Kotlin is it being so damn developer-friendly compared to Java and Scala.
- commitpizza 4y ago
  Do you know of any good backend web frameworks for Kotlin? I would wish for something like FastAPI for python. Kotlin may actually be a great fit for a service I want to build and I hadn't really thought of it as an option until now.
  - arein3 4y ago
    Spring Web MVC
  - danieldisu 4y ago
    Micronaut, http4k
  - xwowsersx 4y ago
    Ktor https://ktor.io/ https://ktor.io/
  - malsanton 4y ago
    Javalin https://javalin.io/ https://javalin.io/
  - piaste 4y ago
    If you want something old and battle-tested, Spring Boot works just fine in Kotlin. I found the extreme OO design kinda off-putting, but once I got over it I had a great time with it. KTor [0] is the 'native' web framework for Kotlin, and there's also a full-stack framework built around it that just hit version 1.0, KWeb [1]. [0] https://ktor.io https://ktor.io [1] https://kweb.io https://kweb.io
    - commitpizza 4y ago
      Well I care more about simplicity and easy to develop in rather than battle-tested. Something like the Javalin or http4k would probably suit me the best. Of course, I have checked Ktor before, but I don't know if I particularly fancy the way they are structuring stuff. My main issue with the java ecosystem is that it's way to enterprisy for my taste. Everything is so unnecessary complex and hard to reason about, but I will take a good hard look at Kotlin before making my decision. The thing is that I am really interested in the native compilation that Kotlin offers that would be very beneficial for me and the only reason behind picking Python otherwise would be that it is a nice language and already installed on the linux environments it will run in. Basically I will have a big api and drop (preferrably) a single binary to some machines that will talk to the api. These machines will generally be outside of my control. I have looked a bit on Rust but it seems a bit too low level and hard to work with. I have looked at Deno because it can compile down to a binary but using javascript for this project seems like a bad choice. So I chose Python at first because it seemed easy to get going with, had great tooling and is already installed in the environments I will be dropping a script in.
- halfmatthalfcat 4y ago
  There's been a lot of work in Scala land to improve tooling, see Mill as an SBT replacement.
- barrenko 4y ago
  If only Kotlin had Scala's frameworks.
nordsieck 4y ago
> Sometimes, the tooling is even more important than language features IMO. It makes developers move quicker, find bugs easier and so on. I like the idea of Kotlin, that it can compile to jvm bytecode, javascript and native. The only thing I'd worry about is Java overtaking it. Do you remember Coffeescript? There was a point in time where it had impressive adoption, and quite a bit of buzz. But then Javascript added features, and all of a sudden the tooling burden associated with Coffeescript just didn't make sense any more. With Oracle's 6 month release schedule, that's a distinct possibility. Especially since Java can no longer rest on its laurels as a language (if Oracle doesn't want it to become Cobol 2).
- draw_down 4y ago
- ajkjk 4y ago
  Wasn't it Typescript that made CoffeeScript obsolete? Not better JS
  - tentacleuno 4y ago
    Really, it was a combination of both.
  - Betelgeuse90 4y ago
    IIRC the main appeal of CoffeeScript was syntactic sugar like lambda expressions etc that were missing in ECMAScript 5. I think ECMAScript 6 made most of the appeal of CoffeeScript obsolete
    - jgalt212 4y ago
      The availability of lodash made us dump any ideas our shop had about widespread coffeescript use.
    - tinco 4y ago
      When CoffeeScript came out, I vowed never to write plain Javascript again. I kept to that vow for a couple years, but eventually broke it when ECMA 6 came out. Really the only thing that put real technical justification behind CoffeeScript was the double arrow function, and maybe the neat class syntax. Beyond that CoffeeScript is just prettier. Even though I was in charge of choosing the technologies, you got to skate where the puck is going, and the puck was clearly not staying with CoffeeScript. ECMA 6 copied all the good parts out of both CoffeeScript and jQuery, effectively obsoleting both. Modern JavaScript is almost unrecognisably different from what it used to be, and that's a very good thing.
barbariangrunge 4y ago
The biggest advantage of a statically typed language over a dynamic one is the tooling. Refactoring statically typed code, after working with JavaScript for a few years, feels like magic because the tools just make it work
dima_vm 4y ago
As for me the greatest appeal of Kotlin is that it doesn't need its own tooling that bad, it feels like just syntactic sugar over Java. Both Scala and Kotlin can reuse Java tools, but with Scala it's awkward (and some tricky generics simply don't compile with Scala). E.g. if I need to parse something, I search for "how to parse that in Java", not "... in Kotlin".
- hocuspocus 4y ago
  > and some tricky generics simply don't compile with Scala What? Do you have any example that wasn't fixed years ago? Any non-trivial Scala app will consume dozens if not hundreds of Java libraries, without any issue.
  - dima_vm 4y ago
    I filed an issue for Scala in 2009, that was answered like "sorry, this particular Java code cannot be used in Scala". In 2012 it still wasn't fixed. I cannot find the issue now, but I remember I was trying to use gae-mapreduce-java library (built on top of Hadoop interfaces). It couldn't compile with Scala.
    - hocuspocus 4y ago
      That's eons ago in Scala world. If you can, give it another try. I would assume such a bug was fixed in Scala 2.x given the prevalence of the language in the hadoop ecosystem and big data frameworks. Moreover Scala 3, was the opportunity to fix many previously-unfixable corner cases.
deleted 4y ago
[deleted]
SpaghettiCthulu 4y ago
Have you ever actually tried kotlin native? Compiling a "Hello World" program takes at least 5 seconds. That's absolutely absurd.
JAlexoid 4y ago
> Sometimes, the tooling is even more important than language features IMO. That would be always. Tooling makes or breaks pretty much every language. Language itself is just a syntax that you write in.

voganmother42 4y ago

“In recent years, Kotlin has become a popular language for Android development. So it only makes sense that we would shift our Android development at Meta to Kotlin as we work to make our development workflows more efficient.” I like Kotlin, but this was pretty funny to me: I imagined walking into a meeting and trying to tell colleagues we needed to move to X because it was popular, then yeet out the ole “efficient”, mic drop & moonwalk out

washywashy 4y ago
Happens so much more often than you think. Have actually seen it with the exact same language (Java->kotlin) on an existing service. I don’t really recall any valid reasons being given for the switch (better support for concurrency etc). I think often times managers allow this bc they don’t want certain engineers to get bored and leave, which is odd to me since who knows why/when they will leave and they won’t take the services with them.
deleted 4y ago
[deleted]
hdjjhhvvhga 4y ago
It happens all the time. I remember when AWS wall all the rage my boss came up and told me we need to use S3. Why? "Because everybody is using it!" I tried to reason, I did a cost analysis - all for no avail. The same boss a few years later: "Why are we paying so much for storage?!" He apparently forgot he insisted on it in the first place.
- einpoklum 4y ago
  I'm 100% sure there's a Dilbert strip with exactly this scenario.
belmont_sup 4y ago
I read it more as they now have kotlin and want to simplify new project decisions to just kotlin. I find this similar to how rust is being added to the Linux kernel.

justplay 4y ago

I thought that they were using react native. Isn't that true now?

rapsey 4y ago
No the entire app is not react native. Only parts of it.
david_allison 4y ago
The native modules still need to be written against Android (these are typically either Java or Kotlin, plus maybe some native code).

DeathArrow 4y ago

Ye still use good ol' PHP on yer backend?

moreira 4y ago
According to them[0], Facebook's primary languages are C++, Java, and Python, and they're even embracing Rust now. In general, teams have the freedom to choose what languages and technologies they want to use. (quoting from the linked video) They might've started with PHP, but even that stopped being a thing once they switched to Hack, their home-grown language, ~10 years ago. [0]: https://engineering.fb.com/2021/04/29/developer-tools/rust/ https://engineering.fb.com/2021/04/29/developer-tools/rust/
- hu3 4y ago
  Not quite. According to a more recent article, Facebook's PHP, Hack, is still a primary language: > For business logic and relatively stateless applications, the Hack ecosystem has the highest level of automation and support at Meta and is the recommended language. On a related note, their Rust usage has grown significantly: > For performance-sensitive back-end services, we encourage C++ and Rust. Rust is a new addition to this list. There’s a rapidly increasing Rust footprint in our products and services, and we’re committing to Rust long-term and welcome early adopters. For CLI tools, we recommend Rust. This is a new recommendation for this year. https://engineering.fb.com/2022/07/27/developer-tools/programming-languages-endorsed-for-server-side-use-at-meta https://engineering.fb.com/2022/07/27/developer-tools/progra...
deleted 4y ago
[deleted]

david_allison 4y ago

One of the things they don't mention is that J2K makes you pick between: * A conversion in 1 commit: complicating/breaking the 'follow' behaviour of 'git blame' * A conversion in 2 commits: the first 'rename' commit doesn't compile, complicating/breaking 'git bisect' I hacked up a script which makes the 'rename' commit compile (when I was working with a ~100KLOC Kotlin conversion). This may be useful for others: * https://github.com/ankidroid/Anki-Android/blob/937a6560913ec383ab71a6a1b704b815b5ad88a8/AnkiDroid/kotlinMigration.gradle https://github.com/ankidroid/Anki-Android/blob/937a6560913ec... * https://github.com/ankidroid/Anki-Android/blob/937a6560913ec383ab71a6a1b704b815b5ad88a8/tools/migrate.sh https://github.com/ankidroid/Anki-Android/blob/937a6560913ec...

fn1 4y ago

Off-topic, but how the Facebook, Messenger or Instagram-app need a million lines of code is absolutely beyond me. I had a few encounters with facebook's opensource code (mostly around react-native) and it is generally subpar in my opinion.

tantalor 4y ago
This happens with "everything" apps that have hundreds of features you have never seen, each serving a tiny fraction of the userbase who somehow stumbles on them and justifying the PM/eng resources to keep them chugging along, or abandoned and left to rot until these migrations come along.
mkl95 4y ago
My guess is that it's an extreme case of Conway's law, with many teams that produce mountains of code hidden behind some API. Not to mention codebases provided by external firms, which could amount to a large % of all those KLOC. I'm interested in how they avoid "Roman empire syndrome", as in owning more software than they can maintain while actively expanding it.
- barbariangrunge 4y ago
  Rome held on to its land for a while. More like napoleon or Alexander syndrome
deleted 4y ago
[deleted]
aeyes 4y ago
Facebook is primarily a message and photo sharing application but it also has group boards, dating, live video streaming, a marketplace, browser games and probably more features. Then there are all the features for targeted ads, tracking, payment and so on. All of this is available almost all around the world. How do you implement these features for more than a billion active users in less than a million lines of code? Even 100 million sounds like a low estimate. Why does the Linux kernel have more than 30 million lines of code? You could ask if these features make sense. But in the end it is their business decision to make.

melling 4y ago

“Shorter code: Kotlin’s modern design makes its code shorter.” How much shorter? How large would the code be in pure Java?

belmont_sup 4y ago
What’s pure Java?
david_allison 4y ago
Expect a 10-30% reduction with J2K, maybe another 5% once manual refactorings are made.
strulovich 4y ago
We actually made this number public in the post. It just appears laters around the conclusions sections. > On average, we’ve seen a reduction of 11 percent in the number of lines of code from this migration.
- melling 4y ago
  I was hoping for more but 11% is still significant. So that’s an extra million lines of code that didn’t need to be debugged.
  - krzyk 4y ago
    I wonder how much of this could be reduced if they used records in Java.
  - kaba0 4y ago
    An extra million lines of {, @NotNull, .stream(), .toList(). Hardly any code that would actually have bugs.
    - strulovich 4y ago
      We have a consistent braces style, so the lines that are removed are rarely those. A lot of the saves come from `?.` replacing null check chains. Many more from the shorter constructor and field initialization syntax (you can get a bunch of things in one short statement). A bunch more from usage of standard library lambda taking functions (`first`, `single`, etc.). Some more just comes from shorter lines due to less explicit types. These are all more some guesses due to conversions I've seen, and not the result of accurate analysis. We also use very little Java streams. A combination of Java 8 arriving late to Android code, and the preference to avoid extra allocations and inefficiencies streams can cause for shorter lists.

naikrovek 4y ago

can someone explain how Meta's code is so large? the tradeoff for high level languages is supposed to be that you gain a lot of expressivity (requiring fewer lines for a developer to express their intent) and you lose performance because of the multiple layers of abstraction required. 10 million lines of code for an Android app, or family of apps, feels like the tradeoff has definitely not born fruit. operating systems written in Assembly have far fewer lines of code than this.

TillE 4y ago
Whoa. At first I didn't blink at 10M lines of code, but you're right they're talking strictly about Android. You have to factor in Instagram and WhatsApp, but still...that's a lot of code.
- naikrovek 4y ago
  it really is. a sibling comment of yours points out some info posted by a former Uber engineer about why, and even considering that, 10 million lines seems extremely high. Windows XP is smaller than the Facebook app for Android...
david_allison 4y ago
Past discussion on why Uber's app is so big, many of the points are relevant: https://news.ycombinator.com/item?id=25376346 https://news.ycombinator.com/item?id=25376346
- jrvarela56 4y ago
  This comment is a gem. Every HNer who has thought 'why do they need 100 engineers, I could do that in a weekend' should go read this now.
  - criddell 4y ago
    > why do they need 100 engineers You're off by an order of magnitude. Hundreds of developers? Sure. But Uber has thousands of developers.

Kukumber 4y ago

If i were to do JVM related stuff, it'd use Kotlin without hesitation That language, just like with Swift and Haxe, they remind me of the good old Flash/ActionScript 3, i loved that language so much It's imo the best form of a programming language one can come up with, very easy to learn, read and write I wish kotlin-native story was better, it's a shit show, super slow to compile, and they decided to go with Gradle... it is on the same level of confusion and bloat as CMake, a pure mistake

einpoklum 4y ago

deleted 4y ago

[deleted]

peter_retief 4y ago

Good idea, I learnt Kolin to avoid having to use Java for android development. Only for one app it was still worth it

denismurphy 4y ago

That app needs to go on diet. iOS 310.6 MB Android 367.7 MB

Macha 4y ago
How much is kotlin vs high res assets or shipping every experiment to turn them on/off with feature flags? I suspect the language contribution is actually pretty minimal
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]

seanalltogether 4y ago

I've found that migrating all your trunk code (data and infrastructure classes) to kotlin is the biggest win, and you can leave your old leafs (fragments and view models) in java if you want do a low risk migration. If a view isn't broken, you don't need to fix it, but getting nullability annotations in your data models and REST commands is a huge win for newer views and business logic going forward.

strulovich 4y ago

Hi HN! I’m the author of this post. I’d be happy to answer questions here on this subject!

johnwheeler 4y ago
I know it’s not the NYT, but just curious how it feels to wake up and see your work on the front page of HN
- strulovich 4y ago
  It’s pretty nice. :) This post is the (pretty short) summary of a lot of work which took us a long time to do. So it’s nice to get any kind of validation. Personally I read HN a lot and it’s my main source for interesting articles nowadays. So that makes me appreciate HN upvotes even more.
  - deleted 4y ago
    [deleted]
    - throwaway123f 4y ago
- pantulis 4y ago
  For us hackers, it's better than the NYT!
  - AnimalMuppet 4y ago
    Yeah. NYT reporters don't show up here to answer our questions.
hu3 4y ago
1) Is that a mono repo? 2) If not, how many LOC is the largest Kotlin repo? 3) How do you tackle challenges of large codebases like language servers/synthax highlighting crawling to a halt in IDEs?

hardware2win 4y ago

~~Microsoft's Java~~ Jetbrains' C#

deleted 4y ago
[deleted]

dr_faustus 4y ago

I'm currently working on a project which has both Java and Kotlin and I really have to say that I like working on the Java parts much better than on the Kotlin parts. I find coroutines a really strange and leaky abstraction (and the prevalence of suspend methods in libraries which you have to wrap all the time just to call them synchronously is really annoying). With streams and the var keyword, Java is also not that much more verbose anymore than Kotlin and the code completion, error detection and refactoring capabilities are much better in Java. In Java I can also be sure that if I directly access a property on a class, there will be no side effects or expensive operation while if I use a getter, there might (and I dont have to write them either due to code generation or Lombok). So the parts where Java is still more verbose actually add clarity (and again, due to the IDE, you rarely have to type any of it): I dont really get why I would leave out the explicit types in the source code, only to be added again as non-editable, weirdly positioned text by the IDE (which is not there if just wanna have a quick look at the code on GitHub).

krzyk 4y ago
And with records you mostly don't need Lombok (unless you really like builders and can't wait for withers in Java).
- bdangubic 4y ago
  Records not being extend(able) is the reason why Lombok is still mostly needed...
  - kaba0 4y ago
    Why would you need extend over implements? I found sealed interfaces with records really cool.
- vbezhenar 4y ago
  JPA requires mutable classes. Records ergonomics is terrible if you want to replace data classes with records, even if immutable is OK. You need to write builders. You can't really write code like new Person(id, null, null, null, lastName, firstName, null, null, null, null, null, null, null, age); Withers can help with that, but they're not even in any kind of experimental shape right now, so we have many years to wait for it. Right now records are only fine for very simple use-cases like Point(x, y). Or if you want to write or generate builders. But at this time you don't really save anything, if you can generate a builder, you can generate a class as well.

nu11ptr 4y ago

Every time I think I maintain large code bases I just need to remember that someone else has a LOT bigger one. Wow, that is a LOT of Kotlin code.

fiejvs72iwbev 4y ago

I am pretty sure, people who build Facebook or Messenger apps for Android does not use the app. If you use Facebook or Messenger for more than 10 minutes, you would find at least 2 very fundamentally wrong bugs. I would have fired most of the developer if I were the CEO of Facebook. They are not competent to work at Facebook

deleted 4y ago
[deleted]

gavinray 4y ago

I wanted to post that ktfmt, the FB Kotlin formatter, is much less well-known than ktlint. IMO, it produces the most (subjectively) readable code, and is the only one that doesn't leave room for you to inject personal style in certain places. (ktlint will let you get away with one of several ways of formatting code, so long as it falls within some guidelines, which can lead to inconsistent formatting). It's a superior formatting tool IMO. https://github.com/facebook/ktfmt https://github.com/facebook/ktfmt

deleted 4y ago
[deleted]
BoorishBears 4y ago
I had it act generally "weird" when adding it to our codebase and ripped it out. Sometimes it'd hang for several minutes, memory usage would spike from time to time. Didn't have time to bother debugging when ktlint just worked immediately.
- strulovich 4y ago
  When was that? IS that a big codebase? I fixed a memory leak issue a few months ago that would have a big effect when running over hundreds of files at once.
  - BoorishBears 4y ago
    More than a few months ago, and a fairly large codebase (~1000 files). I might give it another try for some personal projects since I did like the anti-bikeshedding angle with respect to configuration, but yeah linting can be a hard sell once build performance starts to suffer for it
    - strulovich 4y ago
      Most likely this fix would make a big difference then: https://github.com/facebook/ktfmt/commit/6ea9e8f461853c32177f3a3bc0d2ae4ea5718452 https://github.com/facebook/ktfmt/commit/6ea9e8f461853c32177...

bmc7505 4y ago

Having used Kotlin on and off for the better part of a decade, the one thing I can say is that their editor support is unrivaled by any other language today. While Kotlin's build tools leave much to be desired (looking at you, Gradle), their focus on building a "toolable" language was the right thing to lean into. You can add all the fancy type system features you want, but if the IDE does not understand them, convincing users is going to be a hard sell. Whenever I try to get into another language today, the lack of language-aware editing tools are my main source of frustration - specifically, I expect navigation, refactoring and completion to work flawlessly. I know of no other programming language that puts as much effort into context- and structure-aware refactoring - if another language does one day replace Kotlin, it will need to offer a comparable editing experience.

srcreigh 4y ago
Have you used TypeScript? Not only is it better type system than Kotlin, it has great IDE support in VSCode, AND there’s a language server so you can get IDE support in Emacs/vim.
purplerabbit 4y ago
Have you tried TypeScript? My impression having used it in both JetBrains and VSCode is that it achieves basically what you're describing. I similarly get irritated using anything else now.
- randy909 4y ago
  I've used both and Kotlin was a better overall experience for me. TypeScript has weird typing problems far more often due to the underlying runtime being dynamically typed.
  - purplerabbit 4y ago
    What problems in particular have you run into? Genuinely curious.
    - 4y ago

davidatbu 4y ago

I'll bring up the Kotlin LSP[0] every time I see Kotlin on HN because I really hope the LSP takes off (which would make it viable to use Kotlin with a non-IntelliJ editor). Kotlin as a language looks really cool, but I don't want to give up terminal-based, modal editing (which I'd have to in order to use IntelliJ). Along those lines, I once tried diving into using Gradle outside IntelliJ, and I couldn't find any good resources to help with that. If folks have hints/links-to-blog-posts with regards to that as well, that'd be great! [0] https://github.com/fwcd/kotlin-language-server#this-repository-needs-your-help https://github.com/fwcd/kotlin-language-server#this-reposito...

valenterry 4y ago
I think the LSP for Scala works really well. It's not Kotlin, but you might want to try it out.
- davidatbu 4y ago
  Thanks for the tip! I keep reading on HN and elsewhere that Scala's feature-full-ness encourages complex/unmaintainable code, but I gotta check out myself.
  - valenterry 4y ago
    Totally the opposite - I think that's really from Scala's first versions of so. But Scala has a steep learning curve for the advanced techniques and the compile times can be very annoying when using those. And if you don't use the advanced techniques, you might as well pick Kotlin or Java instead.
    - davidatbu 4y ago
      Thanks. My interest is piqued now for sure.
LinXitoW 4y ago
I'm sure you're aware it exists, but the Vim plugin for IntelliJ is actually good enough, imho. Might be worth a try.

auraham 4y ago

The only thing that prevents me from using it is the license that shows up during installation. Has anyone read the license? The same applies to Dart (Flutter).

yotamoron 4y ago

How come we are reading content from this horrible corporation?

mpweiher 4y ago

Interesting that they were able to quantify the reduction in source code length very precisely (11%), but when it came to the regression in build times ... nada ... just talk about how they plan to mitigate the issue.

peheje 4y ago
Same thought. We can only speculate but I'm guessing the compile time is much worse.
strulovich 4y ago
We don't have numbers around this because the numbers are actually really hard to make sense of. This probably sounds a bit weird, and it surprised me at first. Unfortunately measuring build times is extremely noisy: different people build different things. They do so at different times. On top of it we have incremental builds (so only some part, depending on the modularity and some external and in-house optimizations, gets rebuilt). The incremental builds depend on cached artifacts that need to be downloaded, and many more complications. The result is that if you look at the graphs the values jump up and down based on time, days, moods, network, and many more causes, plenty of which we have no idea what they are. I have not yet seen a successful attempt at cleaning this data up so that some number would be worth publishing. We could try building some toy example that we separated. But that won't be useful to guide our work on build times, nor do I think that it will be valuable to share with the community.
- mpweiher 4y ago
  > the numbers are actually really hard to make sense of. 1. Then how do you know builds are slower? 2. How will you know that the things you are doing to improve build times are working? > jump up and down based on time, days, moods, network, and many more causes, plenty of which we have no idea what they are. 3. Performance being highly inconsistent is actually a (significant) performance problem itself and worthy of reporting, analysing and quantifying. (ranges, averages etc.) > not yet seen a successful attempt at cleaning this data up so that some number would be worth publishing. 4. Not sure why you think they need to be "cleaned". Again, numbers being all over the place is likely an important data point in itself, an even if it isn't the raw data would be valuable. > We could try building some toy example that we separated. Why? Just do a clean build on a local machine. Report real and user+system time. (man time). Repeat.

latenightcoding 4y ago

I'm interested in exploring Kotlin for backend development. But, most Kotlin projects, articles and anecdotes center around mobile apps. I imagine companies hiring Kotlin developers would mostly get applications from people with mobile dev experience

fhd2 4y ago
Maybe it's the wrong circles? Pretty much all the Kotlin developers I know (like four) do backend work.
jillesvangurp 4y ago
There's very mature and widely used Kotlin support for Spring Boot. They've been actively supporting Kotlin for years and it's a well documented and well supported option in that space. Same for many other Java frameworks (e.g. Quarkus, Vertx, etc.). The reason is that it's so easy to integrate just about any Java framework from Kotlin and make it nicer by adding a few extension functions, turning builder soup into more readable Kotlin DSLs, getting rid of all the getter/setter madness or silly hacks like Lombok. I've converted a fair bit of Java code to Kotlin. You almost always end up with better code. Certainly less of it. The notion of Kotlin being a mobile only thing emerged out of the happy accident that the need to get rid of Java was simply felt so deeply in Android that developers were all over Kotlin even before it was released properly. Backend developers waited a bit longer. As a drop in replacement for Java it made a lot of sense there. Google at the time had the whole platform stuck on Java 1.6 while they were engaging with Oracle in the courts. So a lot of the nice stuff in 1.7 an d 1.8 was not usable and forget about all the stuff that was added to Java and still is being added. Most of that you could get with Kotlin right then and there. So, people jumped on it. For the same reason, people have been using Kotlin with Spring since about the same time. Google and Spring made it official around the same time as well with Google outright labeling it as the preferred language for Android (while not cutting off Java) and Spring just adding an enormous amount of Kotlin specific features and extensions starting with Spring 5 and Spring Boot 2. At this point both have documentation for both Java and Kotlin. There are really no downsides to using Kotlin on the server. You can do everything you could do with Java and you gain access to a lot of easier to use stuff than the Java equivalent. I've been using it since before Spring supported any of Kotlin. Worked fine then and it only got better since. The language alone is worth switching and once Spring started actively supporting it, it only got better. I write asynchronous co-routine code with Spring by default. Mostly it just looks exactly like synchronous code. The only way you can tell is that my controller functions are suspend functions. Spring takes care of the rest. That makes everything easier: more readable logic, error handling, etc.

cies 4y ago

We're transitioning to Kotlin. And our main problem with it is slow compilation. With only Java is was <2mins and we're touching 10mins now. I'm not sure what exactly the problem is as we still have to investigate. Our use of Kotlinx.html (which we absolutely LOVE as HTML templating tech) seems to be a part of the problem, but we have not gone to the bottom of it yet. Nothing against the language, everyone on the team loves it (when Java is what we consider normal). The extra type safety we get out-of-the-box or have put some effort into (using KFunction all over the place) is really paying off.

hit8run 4y ago

Delete Facebook.

jdhzzz 4y ago

why does navigating to this document, open a new tab, close the old tab. The result being there is no history that the "back" button (FireFox here) can get to. Seems like a lot of trouble to go to just to annoy me.

ahahahahah 4y ago
More likely a big in Firefox... But sure just imagine it's whatever nefarious thing you want.

tannhaeuser 4y ago

What's the story with Android and iOS cross development using Kotlin? Any major benefit over Java (which used to be a thing at least in the days of j2objc)?

JamesSwift 4y ago
KMM (kotlin multiplatform mobile) just hit Beta status. Its a really unique value proposition compared to other cross platform options in that it doesnt run via a VM (either Javascript or e.g. Mono for Xamarin). It compiles to native LLVM on ios, and as such you can write your UI natively if you want. I was holding off on KMM before, but I've started looking lately and its extremely promising. There is still a lot of ecosystem that needs to be built out (e.g. you need to find cross platform / pure kotlin implementations of URI or Color), but it is shaping up to be the leader in the space IMO.
- kaba0 4y ago
  Why would anyone use it if you can’t take advantage of the vast Java ecosystem? Why would I choose it over Graal for example, which has much bigger backing, stable and is language-agnostic.
  - JamesSwift 4y ago
    You can take advantage of Java in the next layer up, but you lose out on sharing that portion of code/logic then. There are actually 3 layers in play for each platform: The pure kotlin shared layer, the "native" kotlin shared layer, and the native-native layer. That second layer (the native kotlin shared layer) is platform-specific kotlin. So on JVM platforms thats the normal Kotlin you are used to, and as such it has access to Java. On iOS that second layer is Kotlin/Native, and you actually have access to native _bindings_ to the native layer (i.e. I can call into UIKit, but in Kotlin code). If you put your "native" code in the second layer instead of the native-native layer (which on iOS is Swift/objective-c), then you can move that into the innermost layer if/when it makes sense over time, and the frontend is none the wiser. Here is a good visual and explanation (the rest of the presentation is a good overview as well, but I think this slide is the best part of the video): https://youtu.be/2yd6rVJdICU?t=1749 https://youtu.be/2yd6rVJdICU?t=1749 EDIT: I should also note that nothing prevents you from creating "glue" bindings in the pure kotlin layer using either expect/actual or an interface, and then reifying that using some JVM thing in the second layer, and writing the other platforms more from scratch to fulfill the contract.