Hacker News new | past | comments | ask | show | jobs | submit login
Kotlin becomes second most popular language on the JVM (snyk.io)
192 points by fulafel 12 days ago | hide | past | web | favorite | 255 comments





I started using Kotlin daily about 8 months ago.

Recently had to go back to an older Android codebase, and immediately decided I had to start converting.

The amount of boilerplate is unbelievable. I'm able to cut the number of lines by half while increasing readability. Type/null safety is a huge added bonus

P.S. Kotlin extensions are the best


Most of the Android boilerplate is related to stagnation of Android Java and the platform's cruft with every IO rebooting how things are supposed to be done in the platform.

Jetpack Composer is the latest example of such, finally is ConstraintLayout and the GUI editor gettting usable, they reboot the whole thing ('cause Flutter) without even having an idea how to support ConstraintLayout and MotionLayout with Jetpack Composer based UI tooling.


About one and a half year ago we also decided to give kotlin a shot. After a few months my opinion was similiar to yours. Extension-functions, yeah!

Anyway, nowadays you wouldn't see me making the same statements anymore.

My first issue appeared when I was maintaining an Android app written in Java. I needed an library for some functionality. The only maintained ones were kotlin-libs. But interoperability, right? I didn't hesitated to include it. There is no way to use or extend functionality with typealiases in your java code.

IntelliJ can compile Kotlin into Java and it is easily accessible. But there is no adb debugger for kotlin.

Null Safety is just overhead imho. I know when it is appropriate or neccessary to check for null, otherwise i can get rid of it. And its more easily grep-pable the Java way.

Writing Kotlin is not so fluent as one would guess, the tooling only fools you, that it is. You can easily make use of actions like typing pfi (extends to public final int) for java aswell. But when your property changes from nullsafe to nullable, you need to rewrtiging eeevverything.

Additionally, i do not like the implicit type on member property declarations used by almost anybody. The benefit of typing less boilerplate becomes annoying when reading sources outside your ide.

Boilerplate in my opinion is code i need to write by myself. When it is generated by any IDE, i do not bother about it. We are so familiar with Java that we can abstract this boilerplate when reading sources.

Spelling Kotlin to somebody via telephone is also strange for me.

I stopped promoting Kotlin as a Java killer. Code style is too different between different developers.

And why are we creating the same libraries once again?


> I know when it is appropriate or neccessary to check for null

Anyone who thinks they can do better than a compiler for code safety is probably very new to this profession.


I did not want to claim this.

But there are times where you can be sure that the nullable object is not null. You got the double-exclamation-point (!!) for this. But some calls to Android-facilities doesnt accept this, so the IDE notifies you about an var, which could have changed at this point in time. Resulting in multiple !! in the same scope of function.


For me !! is a bad code smell. It is appropriate sometimes, but very rarely. Usually you can write it better with ?.let/apply/also/etc scope functions. Assigning it to temporary val can be done as a workaround for doing !! twice, but as said, probably needs a scope function instead.

Same with vars, they are still needed every now and then but most of a clean codebase is hopefully vals and immutable data classes.


The thing with scope functions is, you are doing nothing if it is null, returning default (even magic..) value or throwing an unchecked exception, even though you want to force your colleague to handle his failure accordingly

You can always do something else for the null case, but this totally depends on the context. Hard to say anything generic. Throwing an error is always an option too if the value is expected.

The whole point is to force you to think about your assumptions every time you write that "!!". It might be annoying, but it's less annoying than debugging an obscure user-reported NPE later on.

> But when your property changes from nullsafe to nullable, you need to rewrtiging eeevverything.

Isn't the fact that you have to be explicit about null the main feature of explicit null safety?


You didn't quote the bit above that, "Null Safety is just overhead imho." Having to change all your types for that data is one reason he gives for that assertion.

I don't have a hard stance on that, but I can see where he's coming from. My day job is all Java, and while we do occasionally have to deal with NPEs, they're just NPEs, not segfaults or things that can take down the whole program. They get caught and logged in a thread while the rest of the (server) app marches on. Programmatically, using Optional to signal intention of null as meaningful (and it is sometimes useful to have null as a meaningful "don't know" value, see http://john.freml.in/billion-dollar-mistake) works well and isn't syntactically laborious. (Additionally Optional chaining with maps is much nicer than the old way of nested if-not-null checks, but sure a "?." operator or similar would be slightly nicer.)

Common Lisp complects nil and false and the empty list '(), which originally annoyed me quite a bit, but after working with it more I see it as deeply pragmatic and it simplifies a lot of code while also making many types of annoying errors in other null-supporting languages either not relevant or much more trivial to fix. Additionally its OOP system has a function-call syntax of (method obj arg) instead of something like obj.method(arg) so in error logs you'll see "no applicable method for the generic function #method when called with arguments (nil arg)" (and in development you have the excellent condition system to resolve this without unwinding the stack and losing state, including the choice to define a method that explicitly handles a null object). But I don't see the programming language fashions moving any closer in that direction...


Yes, it is, but the domain req. can change, requiring to handling an nullable result

Isn't that the one big situation where null safety really shines? Something that used to be required is now optional, so, you need to visit all the use sites to figure out what a sensible behaviour is when the data isn't there.

Without null safety that could be quite tricky, especially when combined with type inference. The value could be stored and used only later, for instance. The compiler flagging where those fields are used without a null check is convenient, it tells you exactly where to insert new code to handle the missing data.


Thank you, I shall be more precise when giving any comment. Honestly, I have not considered the advantages from null-safetyness (rated anything..) properly before posting. I just wanted to rant about kotlin, since i hear too many prayers about it and my gud (stomach) tells me different. I am not able to put it into words, yet. I really appreciate your hint.

Anyway, you are absolutely right and I am glad @jach posted an link (above) regarding my intuition (@shoutout). When I learned programming (with Java, 3 yrs. ago) my mentor pointed out that i included too null-checks, even though i was familiar with the entire code base. Just after reading a post on this platform I realized his real intention: Sometimes (most often!) we needlessy check for null. Since then, forcing me to check anytime for null feels wrong and kotlin is forcing me to do so.

Eventually I just wanted to mention downsizes which comes into my way when using kotlin daily..

Thankfully..!


You're welcome!

Exactly. The whole point of null safety is so that null becomes an explicit decision, rather than an implicit/accidental decision. If the requirements change, so should the code (aka you have to refactor the previously nullsafe code to now become nullable).

I find there's nary such a thing as Kotlin. You always get Kotlin+Java and in the end always two languages to support. It's odd to shift gears all the time, with two sets of syntax tools etc..

I found that despite Java's plainness ... it's robust and I don't worry about 'how fast I can express myself' I'm more concerned about readability and Java is still ok there.


Are you sure there’s no debugger? I’m pretty sure I’ve debugged code in Kotlin from inside Android Studio running on an emulator.

Yes, provided from android studio, but via adb there is only jdb available

Needed some POC code on android last week, that was my first use of kotlin and my most memorable encounter: kotlin-stdlib / kotlin.experimental / and . So kotlin has bitwise "and" operator for bytes, but it's still experimental?

> I'm able to cut the number of lines by half while increasing readability.

What I've seen from kotlin code on the web is that sometimes code is so terse that it's too hard to understand, but it's probably because of not being accustomed to kotlin yet (I've written so convoluted erlang list comprehensions that I'm still ashamed, but those can squeeze 10 lines of java into one erlang line).


Like with any language, out can make it short to the point f obfuscation.

The goal (and the opportunity) is to make your code very declarative.

    view.removeSelf()
vs.

    ViewGroup parent = (ViewGroup) view.getParent();
    parent.removeChild(view);
Extension Properties and data classes further help centralize the contents of a class.

With proper Java support that could be written as

    removeSelf(view)
Not that bad, but then it doesn't sell Kotlin.

Looks like a band-aid for bad API.

Of course. And if you are using any sort of 3rd party library, there's a good chance it has some bad design decisions in it. Having extension methods allows you to clean them up.

If the library is open source, you can of course try to contribute changes, but they may or may not be accepted, and maybe the library is in such wide use that they don't want to break backward compatibility.


This is the worst thing about Java. Almost all other languages have some way to deal with bad libraries or missing features in those libraries. Java has nothing of this sort and it gives library provides all kinds of tools to fuck you over.

The worst thing are developer that don't learn to use the tools that Java makes available at their disposition.

In any language it is possible to fix broken libraries.


Nothing prevents one to achieve the same in Java with adapter classes or utility methods statically imported.

That’s true, but adapter classes can be pretty clunky to use, and while static methods are fairly lightweight, they aren’t very convenient if you’re trying to extend a fluent API.

Welcome to Android.

Let me ask a question as someone with pretty minimal Java experience. If someone was starting a greenfield JVM project today, is there really any compelling reason not to choose Kotlin over Java?

Because the impression I get is that Kotlin is a strict improvement along every dimension. But as an outsider, I'm not sure if I"m just being blinded by hype.


Java gets better with every release and is a pretty decent language today. But Kotlin feels just more consistent with less corner cases. Let me name a few things:

    * No checked exceptions destroying lambda expressions and leading to architecture problems (since exceptions are oft not used like the inventors of checked exceptions assumed).
    * Functions are real first class citizens and don't need artificial interfaces.
    * Named parameters with default arguments are very practical.
    * `name: Type` is a better fit for type inference than `Type name`.
    * Null-safety helps to avoid lots of bugs.
    * The type system with `Any` as a unified root and `Unit` instead of the special case `void` makes programming with generics much easier.
    * Constructors are always lean, not only for data classes (record in Java 14).
    * Most things are expressions, so you can write `val a = if(cond) 1 else 99`.
    * Extension functions and operator functions can be used to write simple to use and elegant APIs.
So at least for me Kotlin is definitive the better Java and I wouldn't start a new project with Java, if I could use Kotlin instead.

Mobile-readable version of your list:

* No checked exceptions destroying lambda expressions and leading to architecture problems (since exceptions are oft not used like the inventors of checked exceptions assumed).

* Functions are real first class citizens and don't need artificial interfaces.

* Named parameters with default arguments are very practical.

* `name: Type` is a better fit for type inference than `Type name`.

* Null-safety helps to avoid lots of bugs.

* The type system with `Any` as a unified root and `Unit` instead of the special case `void` makes programming with generics much easier.

* Constructors are always lean, not only for data classes (record in Java 14).

* Most things are expressions, so you can write `val a = if(cond) 1 else 99`.

* Extension functions and operator functions can be used to write simple to use and elegant APIs.


Thanks. Even on desktop I get a horizontal scrollbar!

The real hero here

There's also the question of long-term sustainability. Groovy was very cool and popular in 2010. Ten years later, Groovy is still in the production codebase while the language is essentially dead.

I personally wouldn't go for anything but Java (on JVM, that is) for anything that isn't a pet project.


Kotlin is officially supported by Android which is huge, and the fact that IntelliJ dog foods their own product into their most important product also gives a degree of security about its future.

Another huge advantage Kotlin has over Scala is tooling, which is basically all thanks to an IDE company creating the language. Tooling will never fall behind because they are in the business of selling tools.


Yes because Google is known for its long term commitment to initiatives.

As far as JetBrains, I am big fan, I have a license for R# that I gladly pay for, but JetBrains is just one company whose core set of products are rapidly being encroached upon by free alternatives.


I see lots of shiny new free editors, but IDEs, especially with deep semantic models and refactorings, are a rare breed.

Eclipse, Netbeans, Visual Studio, QtCreator look quite nice to me.

Best of all, I can use Java in any Java IDE.


having used the first three extensively , i’d say intellij is miles beyond them.

Indeed it wins hands down making my laptop sound like an aeroplane getting ready for takeoff with its continuous indexing, while making generous use of the existing memory.

Needs additional configuration for what the others do out of the box, like Javadoc tooltips.

Requires ten finger shortcuts.

It is also the only Java IDE unable to do mixed language debugging, Java/C/C++.


Outside of Java, jetbrains doesn't have much or anything to offer against vscode, hence the GP's comment.

Jetbrains is even lagging behind, look at vscode remote capabilities which is way ahead jetbrains remote features.


For scala, Jetbrain IDE is far better than VsCode + langage server protocol

For the time being...

> JetBrains is just one company whose core set of products are rapidly being encroached upon by free alternatives

This has been true for almost two decades now - Eclipse first shipped in 2001, and it competes directly against IntelliJ, which was JetBrains' main product at the time.

And yet, they're still around.


> Another huge advantage Kotlin has over Scala is tooling, which is basically all thanks to an IDE company creating the language. Tooling will never fall behind because they are in the business of selling tools.

Not sure I'd agree with this. Kotlin's ties to JetBrains means that you're basically hosed if you don't use IntelliJ. Scala's tooling works pretty much everywhere (LSP/Metals, ENSIME, IntelliJ, Eclipse/Scala-IDE).


> Scala's tooling works pretty much everywhere (LSP/Metals, ENSIME, IntelliJ, Eclipse/Scala-IDE).

Scala's tooling also pretty much sucks everywhere (interestingly the least sucking IDE for Scala is guess what ... Intellij!)


In my experience IntelliJ is a bad Scala IDE. While it has lots of cool advanced features, none of them make up for not being able to compile the basic language accurately: what good is an IDE where I can't 100% rely on getting a red underline for invalid code and no red underlines for valid code?

The parts where IntelliJ has always fallen down on Scala seem to be precisely the parts that are missing from Kotlin. I can't help feeling that the JetBrains team just "doesn't get" higher-kinded types at all. Which is a shame, because there is a lot of good stuff in Kotlin otherwise.


And naturally now they have a vested interest that Kotlin experience just feels better than Scala anyway.

It's improved in the last year or so. It's not perfect by any stretch of the imagination but I find that it's one of the better supported languages out there, second to of course Java/Kotlin/TypeScript/C#.

> Scala's tooling also pretty much sucks everywhere (interestingly the least sucking IDE for Scala is guess what ... Intellij!)

In your opinion.

Personally I almost get depressed when I have to switch from Emacs+Metals to Android Studio for Kotlin stuff.


ENSIME was abandoned several years ago because the maintainer felt bullied[1] and LSP/Metals has a ways to go.

[1] https://medium.com/@fommil/hide-your-real-name-in-open-sourc...


As long as nothing bad ever happens to JetBrains.

(You could say the same thing about Sun/Oracle...risks all around.)


> Dead

It's being maintained. A new version (3 iirc) is about to come out. But it's not a hot bed of innovation.

I think Kotlin now already has a lot more mindshare and corporate interest behind it than Groovy ever did.


Groovy had first class support on Spring and Sun was doing talks at JSFDays on how it would become the JEE scripting language.

Those of us that are part of the Java world since the early days, have been through this multiple times.


Grails is 13 years at this point and still the only way to take advantage of the JEE Java ecosystem while also leaving your sanity intact. Since Grails 4 it is slowly moving away from Spring to Micronaut so the JEE ecosystem may die before Grails does.

That is irrelevant for Java as platform and programming language, just libraries that come and go, Java stays.

Just like C on UNIX, JavaScript on the browser, ....


> Those of us that are part of the Java world since the early days, have been through this multiple times.

The hype curve is definitely in the past, but Groovy is living on quite well as a small but viable option in the plateau of productivity. In some ways that is more important because while in the hype phase it is really hard to judge the true value of a technology. The true value emerges when the hype is over.

The problem is, there isn't really a better scripting option for the JVM. While in theory lots of JVM languages (JRuby, Jython ... etc) could fill that gap, they all have ugly impedance mismatches which Groovy doesn't, so companies continue to deploy it as a scripting and DSL implementation still. I tried to substitute Kotlin for a bit and went back to Groovy because Kotlin still lacks standard scripting constructs such map and list literals etc.


> Those of us that are part of the Java world since the early days, have been through this multiple times.

Right, history repeats itself all the time ... until it doesn't. 10 years ago is not now, Kotlin is not Groovy ...


Indeed, Groovy did not had an OS to sell it alongside.

don’t forget gradle and jenkins

Gradle is moving to Kotlin. I would be surprised if Jenkins wouldn't follow to move away from Groovy.

Note that with Kotlin, JetBrains created it initially for working on their IntelliJ IDE and are porting their Java codebase to use Kotlin. So that is a good indicator of long-term sustainability.

Nowadays there are trying to just get Kotlin anywhere and it remains to be seen how Valhalla and Panama will be usable from Kotlin.

Panama would not seem to pose any problems as it's all code generation with MethodHandles/VarHandles. That should be directly callable from Kotlin.

As for Valhalla, it remains to be seen how it's usable from Java, let alone anything else. But Kotlin already has a form of value type (inline classes) so perhaps it'll be an extension of that.


Kotlin inline classes are heap allocated, they are just syntax sugar for regular classes.

One cannot just change their semantics after the fact.


Kotlin's inline classes (and Scala's AnyVal classes) are syntax sugar for static methods. The object itself is erased completely whenever possible (just like primitive values).

Which is not the same as the semantic meaning of doing stack allocations or being stored in registers.

The following:

    case class Foo(x: Int) extends AnyVal {
        def square: Int = x * x
    }
    val bar: Foo = Foo(5)
    println(bar.square) // => 25
Compiles down to (the moral equivalent of)

    object Foo {
        def square(x: Int): Int = x * x
    }
    val bar: Int = 5
    println(Foo.square(bar)) // => 25
If the inner value (x, in this case) can be stack-allocated or stored in registers then `Foo(x): Foo` will as well. `Foo(x): Bar` (where Bar is a supertype of Foo) will be autoboxed, but that also applies to primitive types (`5: Any` becomes a java.lang.Integer in memory).

Neither of those represent the same semantics of:

    inline class { ... ]
Which is guaranteed to be always stack-allocated or stored in registers, again you cannot retrofit semantics, specially when passing those classes to binary libraries.

You're correct that the Scala version isn't ABI-compatible. But Scala doesn't care about ABI between minor releases anyway, so that probably wouldn't stop them from changing it to align with Java.

There is also precedence for this, Scala 2.12 changed the encoding of lambdas from anonymous classes to Java 8's invokedynamic.


That cuts both ways though. If JetBrains goes away or something shifts their corporate interest away from that then Kotlin has zero support at all. Whereas other languages are built on grass roots foundations. It's certainly unlikely in the short term but it's hard to say long term about the future of any company.

Yeah, it's not like it's a Google project. You can probably expect JetBrains to support Kotlin going long into the future.

SUN was supposed to be here forever as well...

I still love groovy, it doesn’t need to evolve that much to be useful for the things it’s good at, like parsing unstructured data and making boilerplate free pojos.

This time this is the official android language and there is jetbrains behind it.

I would not make Kotlin my first language. It is absolutely a language that requires you already know the patterns and mannerisms of OO languages, like Java or C#. Once you do, its syntactic sugar and features are amaaaaazing.

If you’re already familiar with OO languages and their standard coding patterns, then there’s little reason to use Java over it.

To clarify, for the Kotlin / Java users out there that might not get what I mean: the syntax for classes and constructors and default constructors and all can be very confusing when reading Kotlin compared to C#, Java or Python, since the constructor and the class declaration are halfway merged.


Actually you can code in kotlin exclusively with a functional style, especially with Arrow. since the constructor and the class declaration are halfway merged. this is an optional sugar (data classes)

As much as I like FP and Kotlin, we ended up removing Arrow and hand rolling the few things we really wanted, like a Result sum type. It's an impressive project, however adding FP to an intentionally multi-paradigm language can lead to rough ergonomics in some places.

Interesting, but did you check out arrow-meta? It should really improve expressiveness and ergonomics.

I didn't, but I will now. Thanks!

Indeed, but if you want any OO, it’s a liiiittle weird looking at first, since it’s so much syntactic sugar. Only a little, though. It was a stumbling block when I was learning it at first.

As a scala user, I laugh when I hear Kotlin users saying they are doing functionnal programming.

Can you give me a list of kotlin missing FP features that Scala has? Then I might consider it.

Please, distinguish what Scala has over kotlin separately than what cats/scalaz has over arrow. You will be surprised to see how little the list is.


From lower-level to higher-level:

Real immutable collections (might be available in a third-party library for Kotlin, but not used in the standard library or any of the ecosystem)

Well-behaved option/maybe type (arrow implements one, but it's not used in the standard library)

Either type used in the standard library where it makes sense (arrow implements one)

First-class (monadic) comprehensions in which the language behaves as normal (arrow makes an impressive effort, but it has rough edges from not being part of the language, and its implementation inherently relies on capturing pieces of imperative execution, so you can't rely on it for monads that do control flow e.g. a backtracking/nondeterminism monad).

Practical way to implement typeclasses for third-party types, that will be understood correctly by the whole ecosystem (IDEs/debuggers/etc.) Together with the above this means you can enable comprehensions for any standard library or third-party type for which they make sense, not just libraries that were built on top of arrow (e.g. standard collections, third-party database libraries, types from the Java or Android standard libraries). Arrow's annotation processing is a poor substitute for being able to do this in a first-class way, and even if it were built in, the typeclasses are a lot more cumbersome at the point of use.

Practical way to write tiny, composable functions that rely on HKT/typeclasses. In Kotlin if you want to write a one-liner you still have to cart the typeclass instance around, which might seem trivial but is actually a huge barrier to working in high functional style, where you'd write hundreds of tiny combinators that each do one simple but really generic thing.

Monad implementation for the standard way of representing presence/absence, the standard way of representing async, etc. Even with annotation processing, it's impossible to ever implement a monad instance for Kotlin's nullable types (because they're not well-behaved).

Iteratees or equivalent - a way to represent possibly-async transformation pipelines such that even the middle of a pipeline can be a well-behaved, reusable value that we can use a lot of general-purpose functions on.

Record types (relying on Shapeless) and a way to convert back and forth between case/data classes and a generic representation of them - fulfills a similar use case to "compile-time reflection". This really unlocks a lot of functional power when you combine it with applicative / monadic traversals of those generic representations - it lets you walk an object graph, doing something effectful at each node, in a completely safe, managed way.

Recursion-schemes style traversals - representing different kinds of recursion as composable values. This makes it a lot more practical to do things like tree transformations in a safe way, because it becomes ok to have 20 subtly different types of tree representing different intermediate stages of your operation.

Kind polymorphism (relies on kind-projector in Scala which has similar limitations to Arrow) - makes the above a lot more effective, as you can write functions that do the right things for generic and non-generic trees (for example).

The first half of this is more a matter of degree than of kind, because an ecosystem is more than a language. An imaginary Kotlin ecosystem in which everyone used immutable collections and everyone used arrow optionals instead of nullable types might approach the usability of Scala on this front. But the Kotlin ecosystem that actually exists does not operate this way - and, crucially, there's no way to interoperate between working this way and not. Scala was able to overcome this barrier by having implicit conversions and good typeclasses, so even if you have to use a third-party library that doesn't follow functional conventions, you can still enable functional operations for it. Kotlin can't do that; extension methods don't allow the types they're attached to to implement interfaces, so the only way to treat a third-party type as having some functional support is to plumb a typeclass instance for it around manually as arrow does.

And beyond that, trivial inconveniences matter. It's possible to write a well-behaved Either type in C++, but no-one uses them because it imposes so much code overhead that it's not worth it. Ultimately Greenspun's law applies - you can implement any language in any other one - but at the point where you're working in what's effectively a Scala interpreter written in Kotlin (which Arrow is halfway to being), you're gaining very little of Kotlin's benefits (in terms of tooling, ecosystem and so on).

And the things in the second half are more fundamental. Arrow is an impressive effort in working around the limitations of not having HKT, but it can only go so far; at some point you need real HKT in your language. (It's the same story in Scala one level higher - the things you can do with kind-projector are really impressive, but they're also no substitute for using a language with real kind polymorphism). And if you want to actually unlock the power of functional programming, it has to be practical to avoid using anything that breaks the rules of the language - reflection, bytecode manipulation, annotation processing, macros - and for that you need an equivalent of Shapeless (or Frunk in Rust), or ideally a proper record system.

I'd love to be optimistic about Kotlin - there's a lot that it cleans up - and certainly I hope that the language will eventually adopt HKT. But even then, the ad-hoc approaches of the language's early design will always be a millstone around its neck. I mean, fundamentally, Kotlin collections are mutable and nullable types are ill-behaved, and I can't see the ecosystem/culture ever managing to go through a wholesale conversion to using immutability and proper optionals (contrast this with Scala where mutable collections and null exist but you'll never see them in a mainstream Scala library). And that alone is always going to make it less pleasant to work with than Scala.


Modern Java is actually quite good. The main three things that Kotlin offers, in my eyes, are Data classes (in preview in JDK 14), Coroutines (should be coming soonish with loom), and nullable reference types (not big enough for me to switch).

Outside of Android I wouldn't choose Kotlin.


I've found Optional<> to at least ~help~ with the null issue - as we still don't have value types it still does come with a runtime penalty but most of the code I write and deal with these days has a no-null policy: if it's optional it's Optional<>, everything else defaults to sane defaults or 'empty' (usually immutable) objects. There will of course always be nulls in legacy and performance sensitive code but it is at least ~something~.

>Modern Java is actually quite good.

Lambdas can't handle checked exceptions, which are the most common exceptions in the system.

There is no way to extend Stream with your own methods.

Still 8 primitive types to wrestle with.

Just to name a few issues. And there are lots and lots more.

The language is simply not extensible enough to write anything elegantly.


Just handle your catched exceptions? It's not that hard.

  () -> {
     try {
       // do work
     } catch (IOException ex) {
       throw new UncheckedIOException(ex);
     }
  }

I also agree with Goetz that extension functions aren't something we need.

What's the point of even having checked exceptions, if you're going to have an unchecked counterpart for every one of them just so that you can flow them through lambdas?

Not only isn't hard, one can write a generic utility method.

Regarding extension methods, while they are nice, with import static it just a matter where the extended type comes, big deal.

And from experience in .NET world, hunting them down isn't always fun, even if they are just Ctrl+F12 away.


It is not hard but cumbersome, ugly and ruins readability when used a lot.

> Lambdas can't handle checked exceptions, which are the most common exceptions in the system.

You can do exactly the same thing that Kotlin would do for you and just rethrow them as runtime exceptions. It's one extra wrapper call; not great, but not a huge overhead either.

> There is no way to extend Stream with your own methods.

That's just syntax sugar; all it's actually doing is calling a static method, which you can still do in Java.

> Still 8 primitive types to wrestle with.

You can just ignore them and use the object versions everywhere, and then it's not a problem.

There are a bunch of irritating warts in Java, but irritating warts alone are not worth switching language over.


Null safety is the one big win for Kotlin. https://kotlinlang.org/docs/reference/null-safety.html

I agree, but like I said it's not enough for me to switch. I use Optional<T> whenever I need to return null. The only outlier there is the JDK which most devs should know when it's returning null to you.

isn’t optional just replacing the null check with if(optionalRef.isPresent)??

i kinda get how this is safer, but clients can just call optionalRef.get() without checking, and boom there goes the safety. compiler warnings be damned.


Optional is just signaling to the user that they should check.

You could also do this in Kotlin and boom there goes the safety:

  fn nonNull(): String {
    val s: String? = null
    return !!s
  }

I would tout sealed classes as well, although I think Java has a proposal that's getting traction.

For back-end service/API type things in an enterprise setting, Kotlin is a good value proposition. There's also probably some truth to the idea that one reason modern Java is adding these things is because of Kotlin's existence.


There are far more resources out there for learning Java, better tooling support beyond IntteliJ and many of the cool features of Kotlin are slowly making their way to Java.

While some of the features in Kotlin are slowly coming to Java, that also means that one has to update Java (while you can use all the new kotlin while still targeting Java 8).

Some features like named parameters or null checking might probably never make it to Java.

There is a nice talk about this that compares Kotlin to what will be in Java 19:

https://youtu.be/te3OU9fxC8U


If you are still targeting java8, isn’t that due to organisational constraints about software version management and wouldn’t that normally also imply issues around getting new tools like kotlin into the org too?

Agreed. I highly doubt someone that doesn't want to upgrade their Java version (outside of Android) will be willing to learn and introduce a whole new language.

It also means that Kotlin doesn't get all Java goodies, like virtual threads, value types or GPGPU support.

Virtual threads (Loom) are also not anything affecting bytecode generation, so Kotlin will work with them out of the box.

Really, I don't get this claim Kotlin will lack Java features. Most big Java upgrades these days are at the VM level. Kotlin gets those mostly for free, once they choose to upgrade to newer bytecode features (which they are slow at doing admittedly, but that's because they're in the middle of a compiler rewrite).


No it won't, because Kotlin also needs to target other platforms, and exposing JVM APIs or new bytecodes needs to have to have that into consideration.

It also means that Kotlin on Android cannot just consume any random Java library, only those that are compatible with Android Java flavour of the month.


Kotlin does expose JVM specific stuff though. Like the entire class library. You have to specifically opt in to the multiplatform subset to avoid that. It's not like they whitelist APIs. The only time they need to do anything to add new Java features is when the bytecode patterns change.


If you want null-checking, you can use Nullable annotations. While they're not as good as proper type system, they mostly do the job.

But you have to remember to use them in all the right places. Yes, they help, but it's not just about how good they are, it's about people actually using them too. If you're working on a team, you need to worry about whether or not everyone else is correctly using the annotations.

Also more experienced developers.

Java isn't the terrible language it used to be before Java8. Especially with Lombok it feels very lean and snappy. There are still some functional sheanigans missing but they're coming. Sometimes I wish it were less verbose, but I also think it's good to be very explicit about what you're doing.

Lombok is pretty much the same amount of trouble as using a different JVM language, IME. (Though by the same token I'd always pick Scala over Kotlin: if you're going to go to the effort of using another language, you might as well pick the one that offers the most power rather than using the equivalent of CoffeeScript)

Lombok? My first encounter with it was years ago with some annotation called sneaky throws. shudders

You can very selectively disable features and behavior of Lombok. While I've never used the annotation in my current project I can see the use of it in cases where Java's forcing of exception annotation is in your way or forces unnecessary verbosity.

Do you recommend using Lombok now for new Android projects written in Java?

Absolutely not. If you want a better Java on Android, pick Kotlin, which is supported by Google at least.

I have no experience with android projects. I guess it's useful with every Java as it cuts down a lot of the boilerplate.

"Do I choose Kotlin over Java" is not the choice you face though - you can choose from a bunch of JVM languages. Clojure is pretty nice, for example.

Clojure is very different from Java, so there are definitely cases you might prefer Java over Clojure.

Scala also is a different beast (the one I prefer personally). I can understand people not choosing Scala if they're not into FP and are afraid to be unable to recruit Scala developers.

But Kotlin being some sort of "improved Java", the philosophy stays the same, Java developers can seamlessly switch to Kotlin... The benefit of picking Java over Kotlin is pretty slim.


> you might prefer Java over Clojure

There are good, explainable reasons why people hate Java and Javascript. Fundamentally, one can argue that they are very nice and solid languages and all those complains aren't warranted. On the other hand if you look at them differently and treat them as low-level, sorta "assembly" languages for their respective platforms, then probably you would find out that Clojure is an amazing tool, because it can perfectly be hosted on both of them.

And given all the good design decisions that went into Clojure, one might argue that it's almost always better to choose Clojure instead of Java.


Sure. But it's the same thing as in the JS platform, it's good to be aware that you don't just have a choice between JS and eg TypeScript, but a choice between all the JS platform languages that seem attractive.

About one and a half year ago we also decided to give kotlin a shot. After a few months my opinion was similiar to yours. Extension-functions, yeah!

Anyway, nowadays you wouldn't see me making the same statements anymore.

My first issue appeared when I was maintaining an Android app written in Java. I needed an library for some functionality. The only maintained ones were kotlin-libs. But interoperability, right? I didn't hesitated to include it. There is no way to use or extend functionality with typealiases in your java code.

IntelliJ can compile Kotlin into Java and it is easily accessible. But there is no adb debugger for kotlin.

Null Safety is just overhead imho. I know when it is appropriate or neccessary to check for null, otherwise i can get rid of it. And its more easily grep-pable the Java way.

Writing Kotlin is not so fluent as one would guess, the tooling only fools you, that it is. You can easily make use of actions like typing pfi (extends to public final int) for java aswell. But when your property changes from nullsafe to nullable, you need to rewrtiging eeevverything.

Additionally, i do not like the implicit type on member property declarations used by almost anybody. The benefit of typing less boilerplate becomes annoying when reading sources outside your ide.

Boilerplate in my opinion is code i need to write by myself. When it is generated by any IDE, i do not bother about it. We are so familiar with Java that we can abstract this boilerplate when reading sources.

Spelling Kotlin to somebody via telephone is also strange for me.

I stopped promoting Kotlin as a Java killer. Code style is too different between different developers.

And why are we creating the same libraries once again?


> Null Safety is just overhead imho.

Not having null safety seems like overhead to me.

> I know when it is appropriate or neccessary to check for null, otherwise i can get rid of it.

How do you know? Do you have the entire code base in your head. What about when someone new works on the project?

> And its more easily grep-pable the Java way.

What does this mean?


sorry, first comment and i referenced somehow the wrong content.

I used to like Kotlin, but now I switched back to Java. The only thing that I miss in Java is short property syntax. And praised null-safety just gets in the way too much. Kotlin adds new layer of complexity to tooling, etc. I don't like some Kotlin idioms. Kotlin made a bet to features I don't need (Kotlin native; coroutines). Kotlin compiler is slow comparing to Java.

That said, Kotlin is awesome language with awesome tooling. I don't think that it'll go anywhere since Google declared it as a preferred Android language. So you won't make a wrong choice, it's just a matter of personal preferences. I'm more of old guy who's not afraid of writing XML and repetitive code and don't like all that modern functional one-liners.


> And praised null-safety just gets in the way too much.

If you mean getting in the way of writing reliable software.


*unreliable ;-)

Yeah, if one ignores the existence of PMD and Sonar, yes.

One of the reason to not consider Kotlin would be lack of resources. We run Kotlin services on Production at work and whole writing and reading Kotlin is so much better than Java, finding ways to do things still means having to fall back on Java examples.

There are still resources available for Kotlin + Android development but non Android resources are very few.

The plus side is because of the First Class Support in Intellij Idea for Kotlin, I can always take Java snippets and have the IDE convert them to Kotlin.


I would mostly disagree. You get all the Java solutions plus the Kotlin ones. Few languages have that much support.

Within ~2 years, native things will hopefully become sufficient, but the state now isn't gloom and doom.


That is exactly the biggest problem with guest languages, instead of being happy with what is already there, they duplicate the eco-system.

So now for every problem we need to consider Java + Guest Language idiomatic libraries + alternative build tools + alternative IDE, across the whole corporation.


Yeah well, it's hard to be happy with what's already there when that's fucking Java.

We use a Dropwizard Application written in Kotlin and I have had a very hard time finding examples and tutorials and have had to translate from Java most of the time.

Ofcourse I am banking on resources improving with time.


Other than that, what's been your experience using kotlin with dropwizard? How would you compare it to Java?

>is there really any compelling reason not to choose Kotlin over Java?

IMHO, any language features rank incredibly low on the list of reasons you might use a language. Things like how long has the language been popular, how long will the language be popular? How strong is the community around the language, how long will it stay strong? What else can you use the language for? What tools are available, is the tooling in a competitive market? Which of those things is most important to your application?

A lot of those questions can't be answered directly, and have to be guessed at. But in the Kotlin vs Java scenario, the choice is pretty obvious for most applications.


Many companies started using Scala a ~5 years ago, it was better, there was no reason not to, until the developers found that better is not as good as do the basic stuff that works and holds to the future have proven past, and have many more developers and more people in community this is what rules the game.

I don't think Scala is a good comparison. Due to the fact that it has a large surface area and there is a lot of magic in places, it's harder to learn than Kotlin. Also, Scala suffers from C++ syndrome, where a team of developers that all nominally know the same language can actually know somewhat incompatible subsets of it.

I think the Typescript/Javascript comparison is more apt, and at this point I'm pretty sure that Typescript will win.


As a scala fan, I think comparing Java and Scala is a bad idea. Scala is functionnal programming on the JVM and Java is OO. Kotlin and Java, on the other hand are both OO programming language and should have a smooth transition.

Everything Java does (including considering recent updates), Kotlin does better. So no. I made the switch to Kotlin two years ago and I'm not looking back. It doesn't matter what frameworks you use, Kotlin is a drop in replacement for Java. Though obviously, if you are doing greenfield use something that makes the most of the language.

There's this misconception that Kotlin is an Android only thing or a JVM only thing. The reality in both Android and server side frameworks is that the big frameworks are all moving towards being Kotlin friendly/ready. Additionally, Kotlin is rapidly moving towards being a proper full stack language with a native compiler (currently in beta), a javascript transpiler, and lots of other tooling maturing. People are already doing cross IOS/Android libraries in Kotlin.

A big advantage of Kotlin over e.g. Scala and other JVM languages that are not Java is that it is designed from the ground up make the transition as seamless as possible. Scala is so far removed from Java that it's generally a completely separate ecosystem with its own libraries, tools, frameworks, idioms, etc. Yes you can use Java stuff but it's generally frowned upon by Scala people.

This is not the case with Kotlin at all. The Android ecosystem started transitioning to Kotlin long before Google recommended that and before Kotlin 1.0 because the pain of having to deal with Java 6/7 just made that development so much better. A few years ago they started endorsing and recommending it and at this point they are clearly deprecating a lot of stuff that they did for Java that can be done better with Kotlin e.g. embracing co-routines over rxjava, adding extension functions and kotlin dsls and designing new features that really only make sense if you use Kotlin. On Android, if you are doing Java, you are working on a legacy code base.

On the server side the same is happening with e.g, Spring, which is basically the dominant server side framework for the JVM. I used Kotlin with Spring Boot 1.x/Spring 4.x, and it was a nice upgrade despite the lack of Kotlin support for it.

With Spring 5 and Spring Boot 2.x they started adding a lot of Kotlin extension functions, co-routine support (which generally makes using their reactive stuff less painful), and there's an experimental project for Kotlin DSL (https://github.com/spring-projects-experimental/spring-fu) to replace the mess of annotations that is currently needed and which reduces the need for reflection, proxies, and other tricks that currently make using Spring with Graal vm hard. Basically, what that means is that if you use Spring in a new project and you are not using Kotlin, you are probably making a mistake because you are missing out on a lot of good stuff. They'll likely not deprecate Java entirely for a long time just because there are a lot of very conservative projects in e.g. banks using Java but if you read between the lines they are basically saying Kotlin is it going forward.

IMHO, the Java language is definitely improving but just not at a pace where it actually keeps up and a lot of the stuff they add is a big compromise compared to what you get in Kotlin. and of course Kotlin is improving as well and a lot of the Java changes (and related JVM changes) also benefit Kotlin.


> A big advantage of Kotlin over e.g. Scala and other JVM languages that are not Java is that it is designed from the ground up make the transition as seamless as possible. Scala is so far removed from Java that it's generally a completely separate ecosystem with its own libraries, tools, frameworks, idioms, etc. Yes you can use Java stuff but it's generally frowned upon by Scala people.

> This is not the case with Kotlin at all. The Android ecosystem started transitioning to Kotlin long before Google recommended that and before Kotlin 1.0 because the pain of having to deal with Java 6/7 just made that development so much better. A few years ago they started endorsing and recommending it and at this point they are clearly deprecating a lot of stuff that they did for Java that can be done better with Kotlin e.g. embracing co-routines over rxjava, adding extension functions and kotlin dsls and designing new features that really only make sense if you use Kotlin. On Android, if you are doing Java, you are working on a legacy code base.

There's a contradiction between your paragraphs; my experience is that as Kotlin projects mature, they also reach a point where developers frown on Java idioms. I mean fundamentally either the language is different from Java or it isn't; if it is, the transition isn't going to be seamless, and if it isn't, then why use it? The Kotlin community may have been better at being supportive, but the practical experience of making the transition is exactly the same (e.g. I used Spring for my early Scala projects, and found that to be a very nice way of working).


Which Java idioms do Kotlin programmers frown on? (I am one)

The only ones I can think of are where the language provides a feature that automates some Java boilerplate, so it wouldn't make sense to write things out by hand anymore. Otherwise they're semantically identical languages so the gap isn't big.


Things like builders no longer make sense if you have named arguments. Transforming or filtering a collection is more idiomatic than mutating it in-place. Factories don't make sense when first-class functions do the job better. Basically everything that's frowned on in Scala is also frowned on in Kotlin, in my experience.

Good points. It'd be great if the kotlin compiler could produce builders or "withers" automatically.

Would you really want them? If you write code in that style then you're giving up a lot of the advantages of Kotlin.

IMO there's a contradiction at the heart of Kotlin's positioning. As the quote goes, a language that doesn't affect the way you think about programming, is not worth knowing. If programming Kotlin is just like programming Java, why not just keep programming Java? If you want to switch to Kotlin because it's going to unlock a better way of programming, then that's going to have to mean changing how you program. It may work as a trick to get users on board at the start, but ultimately the language will have to find its own idioms and patterns, or else go the way of CoffeeScript.


I'm talking about what it compiles down to. Kotlin routinely generates bytecode that uses Java idioms either for its own ABI or in addition to it. So yeah, if some builder classes were produced behind the scenes for an immutable data class, why not, that'd be cool. You could always disable that feature with a flag if for some reason the bytecode size was an issue.

Still waiting for the KVM, given that Kotlin is so much better then it can have its own platform, written from scratch in Kotlin/Native, running circles around GraalVM, without dependencies on lower quality Java libraries.

>is there really any compelling reason not to choose Kotlin over Java?

Kotlin is being developed primarily by developers based in Russia. Putin relies on geopolitical conflict for consent manufacturing within the country. One of his future antics could turn into a real crisis, where Russia ends up sanctioned and isolated as a result, after a series of tit-for-tat moves, with the corresponding disruption to normal business processes.

Being a Russian product it also carries a risk of one day receiving an update with a payload from Russian secret services, if they find your firm sufficiently interesting. But it's a general consideration with software/hardware from "adversary" countries like China or Russia. The story with Huawei is the same.


What!? It’s being developed by JetBrains, which is headquartered in the Czech Republic - a NATO member!

It's registered/incorporated in the Czech Republic, but it's a Russian company. Same way Russian search giant Yandex is incorporated in Netherlands.

In more concrete terms, of their ~1000 employees, 600 are in St. Petersburg, their largest office by far.

Ah. That makes things clear.

Kotlin is named after an island protecting the entry to St. Petersburg. While they have some developers in Germany and Czech Republic (plus some remote IIRC), their main development center is in St. Petersburg. I guess they were incorporated in Czech republic due to political issues, but they would still be crippled if they were somehow cut off from their St. Petersburg office.

The JVM itself has a lot of Russian developers, and IntelliJ is the most popular Java IDE with about 60%+ market share, also developed by JetBrains. Their tools are also widely used in other markets.

But you know, the most aggressive country by far at backdooring systems is the USA. For the vast majority of us who are neither American nor Russian it's all swings and roundabouts.


I have always wondered about that myself. I guess I implicitly trust all the large orgs already using their products to do their due diligence, but if it is a targeted attack there is nothing much you could do.

Would be great to have a tech thread that didn't degenerate into low-grade political opinion.

Being born in the USSR and having to watch the collapse of the Union and later Putin's rise to power with my own eyes, I can honestly say - this comment is not without sense and everyone should think twice before introducing Kotlin in their company.

Last I checked the IDE costs money for web dev.

I was surprised to see that Clojure scored better than Scala. Is Scala loosing its appeal? Did Dotty scare people away, because it smells like Python 2 vs 3?

Scala is a nice language but I fear it suffers from internal politics between FP purists and people who simply want things getting done with the former pulling their side of the blanket harder and harder. This alone can alienate a portion of people who are not so much into FP language theory. Besides, a significant amount of Scala tooling is outdated or outright abandoned. Look at all those libraries like Breeze, Saddle, Scalalab. I am not even talking about scalaz vs cats drama. And while all this mess is going on, the Scala team keeps working on a new compiler for Scala 3, sigh.

There's a tension between people using Scala for pure FP and people preferring to opt into pure FP whenever the model domain is needed, or that don't care about tracking every effect in their program and just focus on the 80/20. There are also those that use Scala for data science and other use cases for quick prototyping.

The interests of all of these parties are different and that's what sometimes causes tensions, but these tensions do also exist in other programming languages that aim at a broad audience. Just look at Rust. Languages that do not show these tensions are languages owned by only one party (most of the time, a company) and that are the only stewards of the project and those controlling the agenda. The good thing about Scala is that it's flexible and it allows you to use it for your use case regardless of whether the language designers want to support your use case or not.

Your claim about Scala tooling being outdated or outright abandoned is not true. There has never been as good tooling as Scala has today, with a lot of innovation happening in the field. The reality is that Scala has really good tooling, on par with that of Kotlin and Java, and sometimes even better. Just look at projects such as Metals, Scalafix, Ammonite, mill, bloop or Scala Steward to get an idea of what I'm talking about.

Also, the Scala team is not working on Scala 3, Martin Odersky's team at EPFL --LAMP-- is. The Scala team at Lightbend is working on keeping improving Scala 2 and making sure tooling is still as good as it gets for when Scala 3 is finally released.

There are lots of people in the Scala community that are not so much into "FP language theory" or category theory and just see its potential as a cross-platform language to prototype and write robust software.


>The good thing about Scala is that it's flexible and it allows you to use it for your use case.

It's always tempting to agree to language X being flexible to suit everyone's needs but I would agree with John A. De Goes on that it should be either functional rather than something in the middle. Being flexible is only good on the surface, once it comes to actual daily work like reading other people's code expressiveness quickly becomes a burden.

>Your claim about Scala tooling being outdated or outright abandoned is not true.

I might have been trapped in my own little domain of data science guy and I don't know about other cool active libraries but whenever I dig something useful, it appears to be some PhD project left-overs or "last commit 5 years go" case. It's frustrating and doesn't encourage you to proceed working with the language.

So, if I ask, how does Scala future look like now that we have Java keeping up the pace with Kotlin basically sweeping the JVM newcomers and even Clojure looking good? I go read the Scala 3 goals and struggle to feel the same excitement over intersection types, better implicits, union types, type lambdas, DOT calculus of all things and all this at the cost of "Scala 3 won't be binary compatible with Scala 2" :) I am sorry but doesn't it look like a neck breaking academic crusade into oblivion? I think it does but time will tell of course.


> on that it should be either functional rather than something in the middle.

I don't think the same thing, and other people developing the Scala language don't either, so it's a respectable opinion but tells you very little about what Scala is and will become. Scala 3 is catering for the Pythonistas and there are lots of important fixes that make the language easy to use for them.

The reality is there are lots of languages that are flexible. The important part is where they are flexible. In Java, you can do pretty much anything you want at runtime. Same with Ruby or Python. You can actually do pretty complicated stuff that screws up local reasoning about the code.

Scala is flexible at compile-time by having an expressive language. Some of this expressiveness has been sacrificed in Scala 3 to make the language simpler. But the foundational stuff stays there and time will tell how successful this release will be.

On your comments of Scala 3 and Scala 2 being binary incompatible, maybe you have missed all along that there will be no binary breaking compatibility with TASTY and the goal is that you will be able to mix Scala 2 and Scala 3 code within the same codebase.

> I might have been trapped in my own little domain of data science guy and I don't know about other cool active libraries but whenever I dig something useful, it appears to be some PhD project left-overs or "last commit 5 years go" case.

Again, check out the tooling projects I've mentioned before. Many of them don't either exist in other languages. I don't know what you're referring to with some PhD tooling project. I've been in the business of doing OSS tooling for Scala and working on the compiler toolchain for a long time. If your definition of "useful" tooling includes projects such as LMS, which was a research project, then there clearly is a mismatch between what good and useful tooling is for you and for me.


> The Scala team at Lightbend is working on keeping improving Scala 2 and making sure tooling is still as good as it gets for when Scala 3 is finally released.

This is not true at all, Scala 2 is officially abandoned with the entire team now focused on Dotty [1]:

> we have decided that, rather than developing Scala 2.14, our efforts should go to Scala 3 instead.

[1] https://www.scala-lang.org/2019/12/18/road-to-scala-3.html


No, you're misreading that announcement. The Scala team is working, today, on improving Scala 2.13.x and improving the migration and tooling path to Scala 3, as I said before. The fact that 2.14.x won't be release has nothing to do with the fact that there's a team of 5 or 6 people working on Scala 2 today.

I think the strong inclination of scala toward FP is its main feature. It differentiate itself in a world dominated by OO languages.

Also leaning toward FP is not theoretical zealotery, FP really helps to create more robust software (no null, better error handling, better concurrency).


So you're easily dismissing the idea that Clojure might have become more mature, ergo more appealing? It's an extremely pragmatic choice, striving for elegance and simplicity, whereas Scala is rather more confusing than straightforward.

My favorite snarky quote along these lines: "With Scala you feel smart having just got something to work in a beautiful way but when you look around the room to tell your clojure colleague how clever you are, you notice he left 3 hours ago and there is a post-it saying use a Map." --Daniel Worthington-Bodart

My feeling is that between sbt being painfully slow and Java 8 getting lambdas, people lost interest in Scala.

Maybe. I just wanted to point out that there's Mill as a build tool for Scala: https://github.com/lihaoyi/mill

(by the Scala.js maintainer Li Haoyi)


The last time I gave Mill a shot, I couldn't find a way to authenticate into private artifactory repositories, which made it kind of a nonstarter. Do you know if this has since been added?

That, and it's one-way interop - calling Scala from Java is a deathly proposition.

For me this is the bigger problem. With Groovy and to a lesser extent Kotlin I can write code and ship a library and the consumers don't even know it's source is Kotlin. But it's much harder with Scala. Especially with Groovy you are really not leaving the Java ecosystem at all.

I think most of the perceived sbt slowness actually comes from dependency resolution and that's the same for Java and Kotlin

Ding

I think Scala hast lost most of its appeal due to Kotlin. Scala has some really powerful and clean concepts, but tooling is not as good as Kotlin's. Scala has a much steeper learning curve, and Scala code can look very different depending on who wrote it. These are all drawbacks in real world projects.

With Kotlin you get like 80 % of the good things from Scala for 20 % the efforts.

I've switched from Scala to Kotlin 3 years ago and didn't miss much (real pattern matching come to mind).


Yep, pattern matching is probably one of the main things missing in Kotlin.

From what I understand it's based on a survey. So who knows what are the biases and other preconditions of the results. Also 2.6 and 2.9 percent is not a huge difference.

I agree it's not a big difference, but I was under the impression (apparently a wrong one) that Scala is at least twice as popular as Clojure.

Clojure is definitely growing. Slowly, steadily, but growing nevertheless. There are more Clojure-specific conferences today than of Haskell, Elixir, OCaml, Elm, Prescript, Racket or Rust. There are more books and podcasts. Last year alone there were new conferences announced in Canada, Brazil, Russia, Ukraine and India. Almost every European country has its own Clojure-conf, some have multiple.

Of course it is still much smaller than Java, but Clojure can also be hosted on JS, BEAM or .Net. There's even a way to interop with Python and R.

Clojure is one of the nicest [production-ready] languages out there. It's pretty cool what it has achieved, with pretty much zero marketing effort and without support from big companies.


I think it's more about Clojure doing very well than Scala doing badly.

No it's not a py2 vs py3 situation at all. It's fud.

Scala suffers due to bad tooling. As somebody else said.

I'd still urge people to try out scala as a much better typescript (scala.js) for web


Wouldn't Kotlin for JS be that?

What's the problem with the Scala plugin for IntelliJ?

It can often give false positives, but it's mostly okay and lots of people really enjoy it. It has innovated a lot on finding better ways of showing types.

It'd be good if the OP elaborates on what "bad tooling" we have in the Scala community given that today Scala's tooling is good and on par with that of Kotlin and Java.


It still can't reliably highlight errors. Every version of it either highlights some kinds of working code as being an error, or fails to highlight some kinds of error.

No much now (except being slow on weak laptop). Scala Intellij's plugin has dramatically improved over the years.

Solid tooling can really boost a language. Clojure advocates should internalize that.

What boosts a language is having a tool vendor alongside an OS vendor shipping it.

It would be a bit hard for Clojure to achieve that level of support.


Of course you are right, but it all started with the tight integration with Jetbrains editing package.

Kotlin and InteliJ are from JetBrains, no wonder.

They are trying to be the next Borland with Kotlin as their Turbo Pascal (#KotlinEverywhere), and got Google Android's team as the language godfather.


Scala isn’t owned by a company making tools, but in the recent years it has experienced a big transformation on the tooling space with projects such as mill, Ammonite, Metals, Scalafix or Bloop. I’m obviously biased because I’ve worked on some of these tools but having worked with other programming languages lately I’d dare to say Scala tooling is solid and good. In some regards, we have better developer workflows than Kotlin and Java developers have and there’s a huge stream of innovation in this space.

It has one of the best Swiss universities, and Twitter, sponsoring its development thought.

Most of GraalVM improvements regarding Scala have been thanks to Twitter.


Rails and Textmate had a similar synergy without the direct connection Kotlin and IntelliJ have. There is something to the language/editor relationship that can kickstart the ecosystem.

Google tried to acquire JetBrains multiple times in the past but owners didn't want to sell their cash cow; this is their way to have a large influence over them by paying them a lot for Android Studio, making JB CEO happy and supportive. AFAIK JB teams often work at Google offices and vice versa and it looks like a slow mental assimilation process in progress. That doesn't mean they won't change their minds in the future.

Where did you hear that?

Because what I heard is that Google pay JetBrains nothing. They forked IntelliJ Community Edition to make Android Studio and have their own development team, which honestly sounds much more like Google to me.


I talked to some higher ups.

I wonder how they feel now about no taking that Google money. VScode is crippling Jetbrains at a fast pace.

Net profit >$100M and in the process of lowering taxes via restructuring to "tax friendly" countries like Netherlands (new HQ after Prague), while staying private. Also, look at how many IntelliJ/WebStorm etc. templates have links to Google Analytics and similar ("runs best in Chrome") in their default starting projects. Do you think that comes for free? Their main problem is uncontrolled growth they have no clue how to manage; I was told their culture used to be great but now is chaotic as their employee intake accelerated and nobody internally knows how to solve it.

OTOH Google at least doesn't try to kill them outright, just to assimilate them and headhunt their employees, but Microsoft would be happy if they disappeared instantly as many of their clients have an unwanted dependency on Resharper.


I never understood ReSharper love, some people just like to cripple the performance of their machines.

VSCode is winning Javascript developer mindshare, but for most other languages Intellij is still dominant. For example, PyCharm is free and far better than VSCode for Python development. Additionally, Jetbrains products are free to use for people in education, which has pulled a lot of users.

JetBrains won't be able to stay doing free beer forever though, hence why one then only gets proper support for Kotlin/Native on CLion.

JetBrains lost it when they forced developers into subscriptions and later slightly backtracked (i.e. you can use 1 year old version after subscription expires), but still offered a worse deal than they had before. That came with a new CEO and CFO who insisted on "subscriptions are the future" model.

VSCode just filled the void they left wide open. But I suspect Sublime and Atom are the main victims of VSCode.


And that’s a good thing, right? I mean, I always hear Turbo Pascal was terrific.

Yes it was, then Borland decided it wanted to play in the big league and rest is history.

emacs and cider are rock-solid tools for Clojure, as are equivalent plugins for other lisps. It's not a very beginner-friendly tool, but I'm pretty convinced it really is the best environment for lisp development there is.

I'm not saying that having more mainstream tooling wouldn't be good, but people should not be discouraged from Clojure or Lisp development because of an apparent lack of tooling.


Telling someone new to a language to start with emacs & cider is a disaster. They are rock solid amazing tools for 2% of programmers. I like emacs, but it is harder to learn than Clojure, and trying to teach someone both at the same time is tough. Plus there is no real community unity in editor choice, so you have the community split over emacs, Cursive, VS Code/Calva, Atom. Plus a bunch of dead ends like Light Table or Nightcode.

You say that like having 4 or 5 solid editors for Clojure is bad because no unity. To me, it seems great because there are a wealth of choices for people that like different things and many of them are excellent, well above the bar for being a productive developer.

It is probably net positive for advanced users who have niche needs that the different editors address, but I'm saying it is bad for beginners/learners. More specifically, I'm saying emacs/cider is bad for beginners/learners, and the more traditional IDE options aren't so solid.

I use Cider every day professionally. It is so far from being a rock in any way. Embarassingly inconsistent release to release. Every major release has a new major bug. The REPL lag in Cider 23/Emacs 26 is stupefying. The more text in the buffer, and it doesn't take much, the lag increases exponentially. Google the issue and you will see the angry defendents blame you and your packages. Profile! Profile! Profile! I didn't change anything, Emacs 26 and Cider changed for the worse.

Clojure is simpler, defaulting to immutable data structures literals and a good REPL is superior to most of that tooling IMO.

Those are great features of a great language to program with, but when you are talking about adoption, you want good, easy tooling to expose the good stuff. When the first two chapter of the oft recommended Clojure for the Brave and True are just about setup and and long Emacs tutorial, you are putting up a barrier to using the language.

"Clojure for the Brave and True" is just one of the many (matter of fact I just checked on Amazon - there are over 50 books on Clojure, I stopped counting at 50, I don't know how many more out there)

And that's probably the only book that recommends setting up Emacs. It was published in 2015. Back then maybe the argument about tooling made sense, but honestly, have you looked around lately?

Every major editor today can be set up for Clojure programming.


Agree, wouldn't recommend Clojure to beginners. As it stands today, it is a tool for experienced programmers mostly.

That is so untrue. I personally have seen people learning Clojure. Absolute beginners with no programming experience and mature, seasoned pros. It is much simpler even than Python and Javascript and a lot more simpler than Java or C++.

I am a professional Clojurist. I have used Emacs for decades but honestly and succinctly -- it sucks. Especially Emacs 26. Cider breaks in new random ways every major release. Clojure tooling is its (only) weakness.

Clojure today has pretty good support in ALL major editors (not just Emacs) - Cursive for IntelliJ - is amazing, Chlorine for Atom - is cool, Calva for VSCode is improving every day, Vim-fireplace is a battle-tested tool used by many, there's even a way to set Sublime to work with Clojure.

Even most popular (and oldest) languages can't brag about being equally supported in all major editors, and Clojure can.


Props to https://ceylon-lang.org/ for a good effort. It doesn't seem to be on the race anymore, but at the time it looked like a super interesting contender.

It was a good example of how to build a language in 4 years but the JVM language space is already filled to the brim. The only way to stand out is by having a large vendor bless it (Kotlin on Android).

I'm not sure that's the whole story. Kotlin was blessed on Android because it was growing like a weed, developers didn't need Google's permission to use it and weren't asking for it. The Android team went with the flow (smartly).

I evaluated Ceylon vs Kotlin in 2015, back when Kotlin wasn't even close to a 1.0 release and neither had any adoption. They're very similar in a lot of ways and so the choice came down to a lot of small things added up rather than any one big thing. I chose Kotlin for a lot of reasons, but a few (in no particular order) were:

1. It had a more convenient syntax. The Ceylon designer felt that autocomplete meant verbose syntax didn't matter but it does. "variable Integer foo = 10" isn't just a typing issue but also a reading issue. "var foo = 10" is better.

2. Ceylon deviated more from the JVM ecosystem than Kotlin, in particular, it invented its own collections like Scala, but which didn't appear to be much different to regular Java collections. This means idiomatic Ceylon would obviously be a Ceylon library to users and not a Java library. Kotlin uses standard Java collections but enhanced via extension methods. It also provides a bunch of knobs to make the output classes seem like idiomatic Java classes in the few places that doesn't happen automatically, so you can reasonably use it for libraries. This makes a huge difference to Java interop. Kotlin is really the only JVM language that takes Java interop seriously: the rest all treat it as a price of admission to use the JVM at all and minimise their effort on it.

3. Ceylon was mostly tooled for Eclipse which, in my view, is an inferior IDE to IntelliJ. The tooling was itself not as good as even the pre-1.0 Kotlin plugin.

4. Ceylon had invested heavily in a complicated module and type system, which was the primary set of things they emphasised. These sorts of features have a relatively poor track record of delivering value; slightly-stronger-than-Java seems to be about the sweet spot at the moment. Much stronger than that and you end up in Haskell. Kotlin went in for more type inference and more usable generics (convenience), Ceylon

5. Ceylon seemed much riskier to me (correctly). Nothing used it. It was clearly the project of one guy at Red Hat who'd had a previous successful project (Hibernate), but Red Hat weren't talking about it or using it in any way. On the other hand JetBrains had a large team assigned to Kotlin and were explicit that they were creating it to use in IntelliJ itself. The existence of a Java to Kotlin converter tool showed that they were completely serious about this, as J2K was a lot of work to build and would only be useful in a truly serious assault on existing Java codebases. Ceylon seemed far more interested in fancy type systems than the practical details of adoption.

6. Ceylon had some weird gotchas and interop glitches that weren't normal for Java-like languages, like a sensitivity to the case of the first letter of identifiers (I know Go does this too) and difficulty handling Java arrays. There are named constructors (cool) which don't compile to static methods as is idiomatic for Java but some weird Ceylon specific notation (boo). This sort of thing showed it wasn't trying to be "just a better Java" which is what I was in the market for.


Wow, thanks for the analysis! I think it was very astute to pay attention to how Red Hat was supporting (or not) the language, it never occurred to me to look at the project from that POV, a really useful one.

I think the language is quirky in a lot of ways with the verbose syntax being one of them. I liked some aspects of the type system that made it look close to an ML flavor, although the language had heavy OOP syntax. In this way I thought it was similar to Scala.

There are a few nice write ups from the author on the process of coming up with the syntax. The one talking about constructors is a good example [1].

1: https://ceylon-lang.org/blog/2015/06/21/constructors/


Having recently started writing a bunch of Kotlin to replace Java, I'm happy to hear this! Type inferencing, data classes, and non-nullability make it so easy to use and have helped me catch bugs, too! I don't enjoy it as much as TypeScript yet, but it's a close second :)

No wonder, having an whole OS as godfather, with on maintenance Java language support.

However don't party too much, all of them counted together are still a minority versus Java on JVM, as clearly shown.


I haven't used Kotlin, but when I read through some examples and guides, it felt like Java with all the messy legacy cleaned up, but it was still familiar.

What is the methodology behind these results? If it is what I read in the introduction, judging Kotlin to be more widely used than Scala based on a poll is deceiving and IMO loses any weight this report might carry.

We build and scaled a startup based on Scala code and successfully sold it, so - with all the Scala problems [0] in mind - Scala will always have a place in my heart. Using IntelliJ since a decade+ I wish those guys the very best with Kotlin.

[0] Binary incompatibilities, very very slow compilation speed, atrocious build tool


Seems like Kotlin is basically "Java: The Do-over", right? Unlike Clojure and Scala, it aims for the same use-cases, a similar multi-paradigm balance, etc to Java, just with an extra 15 years of language design hindsight.

My first impression is that Kotlin is being mostly being used by the android community.

Is anyone using Kotlin to write services, what are your experiences with that ?


turk73's comment (https://news.ycombinator.com/item?id=22258252) can't be replied to for some reason so replying at top level:

I agree that switching between languages can kind of drain you of a good touch to your working language. I think this is a real downside about all the other langugaes that a dev today has to deal with too (Ansible, bash, CloudFormation, CSS, etc. I like Clojure because you can use the same good language on the frontend and backend.

> 3) Recruitment for Kotlin devs is impossible. You have to train people and companies won't do that, so there's no pool of talent ready to go.

Is this really a common problem in the corporate world? In my experience people are to quick to pick up at least dynamic languages. I guess it's possible that Clojure is easier in this respect, or maybe Clojure jobs just attract people with a more exploratory attitude.


Kotlin is Java done right. It's what Java would have been from the start, if only original Java designers weren't C++ copycats in a rush.

Every single popular language was rushed, and every single one borrowed many ideas from elsewhere.

Yes, so it's great to see at least some of them get to the 1.0 version eventually (and I mean Kotlin = Java 1.0). Now if only we could get people off the pre-release versions of Java (which for some reason are named "Java 11", "Java 12" instead of "Java 0.9.1", "Java 0.9.2" as they should) and on to the real deal!

Seriously, I have great hopes for Kotlin. It corrects some Java's most egregious sophomore mistakes, it doesn't try (and fail) to be Haskell like Scala did, it's accessible AND has a major company behind it. Kotlin is surely something I wish I could use at work.


I do think Kotlin is a 'better java' while Scala fails to satisfy that niche. However, I wonder if we'll actually see some big Open Source projects/platforms released that are written in Kotlin. For Scala you have Kafka, Spark and Flink which are widely deployed in the enterprise. Will Kotlin have a marquee infrastructure project to tout soon?

I wonder how long is it gonna be until Kotlin will have the same fate as Groovy and Scala.

Don't get me wrong, I appreciate both Groovy, Scala as well as Kotlin. History has shown that Java has always managed to move forward and superseed the former.


First is Java, 87%. Does anyone here know how JVM ecosystem is governed? Do the needs of Java dominate or can smaller languages get change requests in reasonably easily too?

Java needs drive the JVM, yes they do take into consideration what might be relevant for guest languages on the JVM, but that is "nice to have" kind of thought.

You can easy check this by reading JEP proposals, discussions on the mailing list, or talks from JVM Language Summit.


Java dominates, also because that's the main source of engineering capacity.

There are some notable exceptions though. E.g. invokedynamic from JVM 7 was only really used for Java starting at 8 (with the introduction of lambdas), and was partially introduced to better support dynamically typed languages like Ruby on the JVM.

The languages do benefit from JVM improvements. Scala 2.12 had a significant speed-up due to native lamba support from JVM 8, and if project valhalla ever lands you can bet all JVM languages will be happy to use it.


Guest languages cannot make use of Valhalla/Panama without having plaform specific extensions.

Basically they will end up with some form of conditional compilation or performance loss emulating those features on other platforms (if at all possible).


There's a committee and a process. As an outsider it seems like non-Java languages get at least some influence, e.g. invokedynamic was put into the bytecode largely to support non-Java.

Most of the new development in Java is syntactic sugar, not JVM-level. The most interesting JVM thing recently has been invokedynamic, which was a boon for JRuby, but ended up helping Java's own lambdas.

> Most of the new development in Java is syntactic sugar, not JVM-level.

That's not true. The javac team is what 5% of all people working on OpenJDK.


Are they adding instructions to the language or working optimizing the JVM, though? My point was that someone writing the language targeting the JVM will compile to Java bytecode, so missing/suboptimal instructions are where they're mostly likely to feel pain.

Yet still can't compile kotlin on android.

Kotlin compiles just fine inside Termux Arch.

What would be the use case of compiling Kotlin on Android?

Developing on a phone or tablet.

But I mean... that must be a terrible developer experience. Why even bother?

Well deserved. No academic high browing, no armchair hammocking, just accessible pragmatism.

What does armchair hammocking mean? I've never heard the phrase before.

I'm referring to the very entertaining, but a bit truism-heavy and patronizing presentations of Clojure's Rich Hickey, for example "Hammock driven development": https://www.youtube.com/watch?v=f84n5oFoZBc

I like Rich Hickey's philosophy and personal style, but Clojure just falls short in every aspect as an implementation thereof, in my opinion.

For example, it switched from heavily promoting STM as a concurrency primitive to "app state in atom" to new async/channels.


I don't think you can call clojure.async as something that was made for switching anything, replacing it. Both ways exist and are being promoted for their use cases. I think Clojure is one of the few languages where things have been very stable for a good while. Maybe it's being developed slower than other languages, but using Clojure is nice because of the trust you have of it remaining the same. Everything else is basically libraries on top of the language itself.

You're implying that Clojure is not pragmatic? It's probably one of the most pragmatic programming languages out there. I have personally tried many, but no other language allows me to be as extremely productive.

100% this. Kotlin is a blue-collar language.

It feels like Java meets Python.

Indeed, arrow and flow.

Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: