Kotlin vs. Java

https://www.kotlinvsjava.com

by driver733 • 7 years ago

305 321 7 years ago

kotlinvsjava.com

jermaustin1• 7 years ago

I don't know if I like the "Elvis Operator" - I feel its one too many conditions on a single line.

And the ternary operator is just odd when there is a more terse "standard" approach to it.

dajohnson892• 7 years ago

It feels like a common sentiment that concise code == good code

smt88• 7 years ago

That's true, and Kotlin definitely leans into it, but extremely concise code basically ends up looking like Brainfuck -- lots of symbols jammed together and hard to read.

driver73311• 7 years ago

To be more precise, I would say that expressive code == good code

rongenre2• 7 years ago

Well, more to the point - bugs / LOC is remarkably constant in real code across coding languages, so one of the best things you can do is reduce LOC.

mjcohen• 7 years ago

APL may be a counterexample, at least when trying to understand what you have written a few months later.

ivolimmen2• 7 years ago

Well: less code means less bugs doesn't it?

tjohns• 7 years ago

The Elvis Operator is particularly useful because it's such a common pattern in Kotlin, since the language enforces null safety. When you're using a legacy Java API without nullability annotations, the language forces you to explicitly handle a null result.

vinceve• 7 years ago

It masks the complexity of your statement. I know in ruby we had the same issues with the “try()” method. Our rule was, do or do not, there is no try. :)

More info: https://karolgalanciak.com/blog/2017/09/24/do-or-do-not-ther...

benibela3• 7 years ago

No, in that case it does not enforce it

The Java types become platform types

saagarjha4• 7 years ago

On the contrary, I consider the "Elvis operator" to be one logical operation: give me this value, or the other one if this one is invalid. What's the more terse way to write the example with a ternary operator?

zmmmmm• 7 years ago

The beauty of the ternary operator is that it isn't one. It's just taking advantage of the fact that if/else is an expression in Kotlin and it turns out that when if/else yields a value, a dedicated ternary operator is redundant. It's one of a small number of things that I like better about Kotlin than Groovy.

Someone1234• 7 years ago

That's actually a really clever (yet simple) design. Have other languages done this before?

Now I cannot "unsee" that concept. Why isn't if/else an expression in other languages that just yields a value?! That's a powerful idea.

leeman2016• 7 years ago

One obvious advantage of the "if-else" approach is using indefinite "else if" conditions rather than just one "else"

chrisseaton2• 7 years ago

Why don’t the Java examples use var?

driver73311• 7 years ago

They will. I am in the process of updating Java code snippets to Java 11.

vips7L8• 7 years ago

Probably should do 13 since it's the current release.

nostrademons4• 7 years ago

This doesn't really showcase many of the best advantages of Kotlin. They should add some with data classes, JavaBeans, multiple assignment, lambdas, map/reduce/fold, extension methods, etc. I've found that Kotlin code is usually 3-4x more concise than Java, and most of the benefit is in your data structure definitions (i.e. changing 100 lines of boilerplate to a 4-line data class, or destructuring a Pair/Triple where you would otherwise have been tempted to create a new class and 2-3 lines of assignments) rather than in individual statements.

oh-4-fucks-sake• 7 years ago

So much this. Although if the guide is meant to hit on the heavy-hitter basics, I think it's a great start.

commandlinefan• 7 years ago

Kotlin (which I don't know) looks a lot like Scala (which I do), at least superficially. Wonder if you've had any experience with Scala to compare the two?

Filligree• 7 years ago

Scala is way more complicated. I don't know if that's an advantage or not -- I never got far enough into learning it to do a valid comparison.

Kotlin code is something any Java programmer can read with just a few days learning, however.

tlarkworthy• 7 years ago

I did Scala first, then recently took over a codebase with both. I think the people who did Scala were not good and they made a total mess, however, their Kotlin miscroservice was actually quite nice and was the best code in the project. So I reluctantly have concluded Kotlin is a better level of expressivity. Scala is full of footguns... I love it ... but it's hard to write well.

One example was they were using enumerations and got boxed in. They had to add unit tests to ensure they enumerated all the options. Why does Scala have that feature? It's full of bad features you should avoid.

eugen_a• 7 years ago

To sum up my experience: Scala can be even more terse than Kotlin, but I found Scala code generally harder to read and understand compared to Java. It has the kitchen sink thrown in in terms of features and the idiomatic way of writing code is pretty complex and very different from Java.

Kotlin on the other hand is just a breath of fresh air, very easy to pick up and get productive.

I just hope they keep the language to a manageable size and don't keep putting things on top.

ayberk• 7 years ago

Used Scala in production for two years and have been writing Kotlin for a year now.

I'd still prefer Scala to Kotlin any day as I still think it's a stronger language. We had to use arrow library to make Kotlin more like Scala. Especially if you're leaning more functional, standard Kotlin will be lacking.

That being said, Kotlin's entry point is much much lower for Java programmers. Kotlin is a better Java, so I can understand the appeal. I'd never start a new project in Java when Kotlin is available.

nine_k2• 7 years ago

Scala is like C++: powerful, unkempt, and has a number of footguns built in. It has naturally evolved.

Kotlin is like Clojure, or Elm, or Rust: it is lean, orthogonal, and thought out. It has been intellijently designed.

My choice is firmly behind designed languages.

joostdevries• 7 years ago

I've developed in Scala for 5 yrs, last yr in Kotlin. Scala spearheaded from 2007 a lot of features that nowadays are the norm for statically typed programming languages. Odersky is a visionary imo. For a while I experienced Kotlin as Scala--. (No pattern matching?!? ) A bit later I discerned where Kotlin is treading its own path. The biggest things for me are: non monadic approach to async. Which works really well. And simpler extension functions. I'm looking forward to trying out union types that are coming to Scala.

mrkeen3• 7 years ago

It misses higher-kinded types and for-comprehensions. So you cannot generalise List<X> as L<X> nor pull out its values with x<-lx.

bitL4• 7 years ago

OK, but where are the advantages? The page has just a different syntactic sugar resembling Pascal/Scala; sine JVM nihil Kotlin anyway. Sometimes Kotlin's "advantages" there have more boilerplate than Java...

driver73311• 7 years ago

I leave it to the reader to decide whether the advantages are clear or not.

For instance, in Kotlin you can perform operations on collection without converting them to a stream first, and collecting them with a certain collector afterwards. So in order to perform a single filtering operation on a collection, you need to do three steps in Java and just one in Kotlin.

Another advantage is coroutines, which not only allow you to write asynchronous code in a common, synchronous manner, but also get rid of shared mutable state, since coroutines can send/receive shared state through channels.

deepsun5• 7 years ago

That's actually what I like about Kotlin the most -- it's just syntactic sugar over Java, I wouldn't call it a new language.

E.g. if you want to parse a CSV or JSON, you would google "how to parse it in Java", not "... in Kotlin". That's different, from e.g. Scala, where everything should be Scala-way (of course you could use Java libs in Scala, but it was always second-class I feel).

pkolaczk13• 7 years ago

Once you learn the Scala way of e.g. parsing JSON or defining any custom parser or working with collections/optionals you don't want to look back. I had to move back to coding in pure Java for a while after coding Scala many years, and really it feels Java is making things far too overcomplicated in many places.

xwowsersx• 7 years ago

Comparing to

>> public static void main(final String[] args) { System.out.println("Hello world!") }

Is just a glamour shot. How many times does one actually have to type public static void main? Once per application, by definition.

driver73311• 7 years ago

It is, however, even in the scope of the "Hello world" app, Kotlin performs much better than Java in terms of bringing out business logic to the front.

deepsun5• 7 years ago

And in IntelliJ you just write "psvm" and hit Tab.

achikin• 7 years ago

Intellij driven development.

sansnomme• 7 years ago

Isn't final optional?

saagarjha4• 7 years ago

Yes. And there are cases where omitting it is specifically useful.

skocznymroczny• 7 years ago

This, some people underestimate how good Java/C# IDEs are and how much typing they save. I love how I can select a piece of code and do something like "extract to class" and it will create a new file, create a class there, put the code in the method and add a class method call at the original spot.

JanecekPetr• 7 years ago

The I/O example is moot since Java 11 where Java got https://docs.oracle.com/en/java/javase/13/docs/api/java.base..., so we can do `Files.readString(Paths.get(doc.txt))`.

Java 14 is getting an experimental preview of Records (https://openjdk.java.net/jeps/359) which takes care of much (but not all) of ceremony around "data classes".

And Java 13 got a preview of text blocks, https://openjdk.java.net/jeps/355.

Things are coming. That said, I hardly believe those minor syntax improvements are what is so "good" about Kotlin. It has some better defaults (non-null by default, final classes by default), and is a more modern language. Java will stay with us for many years to come, though.

driver73311• 7 years ago

You are right, but you still have to catch the checked IOException.

deepsun5• 7 years ago

I actually like it. I also create my own exceptions for rare (exceptional) cases, just not to forget to handle them.

But some Java SDK exceptions drive me crazy. For example `URL.parse("http://example.com")` over hard-coded strings that I know 100% won't throw exceptions, but I still to catch 3 of them.

twic11• 7 years ago

Absolutely wild how people are all in favour of Either/Result, but still look down on checked exceptions.

bArray• 7 years ago

You are right, but you still have to catch the checked
IOException.

Rather than which alternative? There are tonnes of IO errors that can occur and are captured in Java that you may not ever even consider. IO is exceptionally tough and programmers should be aware that there could be 1 of a possible million reasons for failure, even if they don't care exactly why.

It's not a massive ask either:

    try{
      /* Perform some IO that 99.999999% of the time */
    }catch(Exception e){
      /* Something went wrong and we don't know the state of the disk */
    }

Personally I believe applications should have their own wrapper around IO and handle it accordingly. I.e. not caring, re-trying, show-stopper, etc, etc.

A lot of code I've written will have the following if I really don't care if it works or not:

    try{
      /* IO code */
    }catch(Exception e){
      /* Do nothing */  // <-- Let others know that this was on purpose
    }

madiathomas7• 7 years ago

Checked Exceptions are the main reason I switched to C#.NET. I hated checked exception. I know the designers wanted to save us from ourselves but they ended up making the language verbose.

guelo3• 7 years ago

I wonder if Java's speeding up of new language features over the past several years, after many years of a stagnant feature set, is a direct result of pressure from the likes of kotlin.

hinkley• 7 years ago

Who has it now is a good question, but so too is 'who had it first'.

And if you also consider the upgrade treadmill, and where the average Java developer is relative to say ten years ago, it may turn out that at any given point in time, the Kotlin version you'd be able to deploy may have a number of features the most recent Java version you could deploy does not have.

(to say nothing of companies where 'the version' is decided by committee or fiat and thus having a more obscure language sometimes gets you less scrutiny).

hyperpallium• 7 years ago

Ask "how does Oracle benefit?"

_akei3• 7 years ago

It is mostly C# that is keeping Java on their toes. Java competes with C# than any other language in this world. In the enterprise space, it is either Java or C#. If you check most of their improvements, they were done ion C# first, then they follow.

pjmlp7• 7 years ago

Pressure is only from C# and languages like Go.

There is nothing to fear from Kotlin, it is a guest language on the JVM.

It is only relevant on Android, as Google is making ART into the KVM.

Outside Android, Kotlin market share adoption is very low, as any trends chart will easily prove.

pron4• 7 years ago

It's not so much pressure as data. Java is conservative by design. Even back in 1997, James Gosling wrote that Java only adopts features after they've been tried in other, more adventurous languages, and then Java picks those who've shown the best cost/benefit tradeoff, and only after enough people seem comfortable with them. Java, then, depends on languages like Kotlin or Scala for crucial data about features. The interesting thing, though, is not which features Java adopts, but which ones it doesn't.

melling• 7 years ago

I like a succinct way to define immutable variables. That’s what I do by default in Swift

   let str = “foo”
   let age = 10

Kotlin does this with val, which is great.

How do Scala and Kotlin compare?

Next time I’m back on the JVM, I’d like to one of these two, perhaps both if they interoperate.

unnouinceput2• 7 years ago

I love programming languages that are case sensitive. So easy for each programmer to have their own programming style on naming variables and then errors galore, which in the end will result in hiring an outside senior to clean-up the mess - that's me of course, and all for heavy money.

Somebody please invent another case sensitive programming language, we don't have enough of them already.

dboreham• 7 years ago

Aren't they all case sensitive since FORTRAN and BASIC?

Roboprog• 7 years ago

Only in the C, C++, Java, ... universe.

Worked with a few case smashers in the 80s. Smashing Unicode is hard, I guess. I don’t really have much of a preference for or against case sensitivity, though I do hate fuglyCaps

klodolph• 7 years ago

Pascal, R, Lisp, Ada, SQL are case-insensitive.

ratherbefuddled• 7 years ago

It's hard to conceive of an issue which is less important in modern programming. In 20 years of commercial programming on a variety of platforms my experience is that case sensitivity causes no problems at all and case insensitivity causes only minor and occasional problems.

unnouinceput2• 7 years ago

I would love to live in your bubble. Unfortunately, or perhaps fortunately, depends on what point of view you refer to, as freelancer in past 10+ years, real life is quite different.

jeroenhd4• 7 years ago

Why don't the nullability examples use Java's Optional?

This code:

  if (nullableVariable != null) {
      boolean success = nullableVariable.someMethodCall()
      if (success) {
          return success
      } else {
          return fallbackIfNullMethodCall()
      }
  } else {
      return fallbackIfNullMethodCall()
  }

Could also be written something like this:

  result = Optional.ofNullable(nullableVariable)
                   .map(NullableType::someMethodCall)
                   .orElse(fallbackIfNullMethodCall());

Sure, it's no Elvis operator, but it's a lot more readable than the "standard" if/else structure of traditional Java. If we're comparing Java and Kotlin, we should at least give Java a fair chance. I dislike the verbosity of the Optional wrapper, but it's a lot better than if/else checking.

rococode• 7 years ago

Even the simple if/else approach can be done more cleanly (i.e. without repeating the fallback call):

  boolean success = false;
  if (nullableVariable != null) {
      success = nullableVariable.someMethodCall();
  }
  if (success) {
      return success;
  } else {
      return fallbackIfNullMethodCall();
  }

arnvidr• 7 years ago

Even that seems way too much. The original would be much easier as:

  if (nullableVariable != null) {
      boolean success = nullableVariable.someMethodCall()
      if (success) {
          return success;
      }
  }
  return fallbackIfNullMethodCall();

And even that can be more concise if you prefer:

  if (nullableVariable != null && nullableVariable.someMethodCall()) {
      return true;
  }
  return fallbackIfNullMethodCall();

posedge• 7 years ago

That's 9 lines of code vs. 3, and one additional variable. Cognitive load from lots of verbosity like this adds up.

cosarara2• 7 years ago

How does the order of evaluation work in the second form there? Will fallbackIfNullMethodCall() be evaluated even if not returned?

driver73311• 7 years ago

It can be done this way:

  result = Optional.ofNullable(nullableVariable)
                   .map(NullableType::someMethodCall)
                   .orElseGet(() -> fallbackIfNullMethodCall());

jeroenhd4• 7 years ago

My code contains a bug, the code driver733 wrote is what I intended to write (usually I use predefined variables for orElse, conditionally taking the method call threw me of guard).

driver73311• 7 years ago

I completely agree. I'll make that change soon.

Thanks for the feedback.

mpawelski• 7 years ago

Is the actual logic different in Java vs Kotlin examples?

In Java: when `nullableVariable` is not null and someMethodCall() return `false` then we return what `fallbackIfNullMethodCall()` returns right? and in Kotlin in that case we just return `false` from `someMethodCall()` because this is not null and `fallbackIfNullMethodCall()` is not even evaluated?

desert_boi• 7 years ago

Java's Optionals can be `Some | None | null` right? They're just reference types still.

chii3• 7 years ago

the intension is that the Optional reference is not null (despite it being _possible_ due to how references work in java). And it's fairly easy to add annotations like @NotNullable or some other compile time annotation which can be checked very easily by an IDE or other tool.

Hermel• 7 years ago

Here's an even shorter one-liner:

return nullableVariable != null && nullableVariable.someMethodCall() ? true : fallbackIfNullMethodCall();

mormegil• 7 years ago

"? true :" is equivalent to just "||".

jeroenhd4• 7 years ago

This works in this case, but the pattern is less easy when the result is not a boolean.

But I agree, in this specific case using a ternary operator after a null check is probably easier.

muzani• 7 years ago

That's shorter, but I find the given example more legible.

soulnothing2• 7 years ago

At it's base Kotlin is a nicer java. But it's much more. Simply looking at the syntax comparison is only half of the story. The focus at the recent conference was multi platform and concurrency.

They are making concurrency a first class citizen. With items like Go channels, Observable etc. This is baked into the language. There are a number of new frameworks utilizing these patterns. Resulting in less code, and more performance. At the cost of sometimes more difficult debugging.

The bigger item to me is multi platform. I'm working on a micro orm. That reflects your schema automatically generating types for NodeJs, Native, and JVM(Graal/JDK). It can then be run on any of those platforms. An example is libpq for postgres allows streaming and observing rows on update. This is not in the DB libraries that I've seen yet. I can have an actor run natively on LLVM, talk back via grpc/rsocket/tcp/etc. To a JVM/JS service. All while adhering to the same interface / method description.

Besides that. There are scripts for kubernetes, react/angular/vue, etc. Dukat is coming to automatically convert ts.d files to kotlin description files. For me I can have one language, one IDE, for every part of my product. From deployment, back end, data handling, front end, and mobile.

vips7L8• 7 years ago

I don't see how concurrency isn't a first class citizen in Java, especially compared to kotlin/native's concurrency package which is barely a package.

fnord1233• 7 years ago

Thread based concurrency where everything is blocking inside the thread is the first class citizen. If you want to move to a non blocking world, then you will suffer.

Moving between Channel and Flow sucks. No async/await keywords like Python, C#, Rust so you have callback hell. try-with-resources doesn't work with async callbacks (i.e. thenApply, thenCompose, etc.).

Also, JAX-WS standard doesn't currently support Channel or Publisher<ByteBuffer> for body types.

apta2• 7 years ago

Java is getting fibers (check out project Loom). They're supposed to provide the same level of debugability as regular multi-threaded code.

findjashua• 7 years ago

the biggest wins w Kotlin, imo, are the sensible defaults - variables are non-nullable & collections are immutable by default. These eliminate entire classes of runtime exceptions and bugs (respectively).

svnpenn• 7 years ago

I learned that Kotlin has a native compiler:

https://github.com/JetBrains/kotlin-native

does this mean end user can run without JRE? Does Java proper have something similar?

vips7L8• 7 years ago

GraalVM has a native-image compiler.

https://www.graalvm.org/

spelunker• 7 years ago

GraalVM can build native images: https://www.graalvm.org/docs/reference-manual/native-image/

I haven't heard of kotlin-native, but apparently it isn't using GraalVM under the sheets which is interesting.

thu21116• 7 years ago

Kotlin Native predates the release of native-image. Also it's actually a slightly different language. Kotlin/Native really wants you to not write shared memory multi-threading. All variables are thread local by default. It has special constructs for interop with C libraries, and uses a sort of reference counting Python-esque memory manager if I recall correctly. You can only use C or other Kotlin/Native libraries.

GraalVM native images are a different matter. It uses the Java memory model and ahead of time compiles all the code to native. The "VM" part is bundled with the binary but it's very small and thin. Really it's just a simple generational GC and a bit of support for reflection over things you said you want to reflect over.

Both produce small binaries that start as fast as C programs do. In fact the GraalVM team have advertised cases where native-image binaries start faster than C programs do.

saagarjha4• 7 years ago

Is this like Graal (e.g. build the VM into the “native” image) or actually compiling to a just a native binary?

AndrewBissell2• 7 years ago

Yes and no. It's "like Graal" in that there is a Kotlin/Native runtime which is built into the binary. It's "not like Graal" in that it is not building in the entire JVM, and K/N code provides things like manual memory management APIs which are not available in e.g. a Java->Graal context.

ajross• 7 years ago

Java had a native gcc front end way back in the 90's. No one used it and they eventually dropped it. This isn't really a killer feature for the problem areas targetted by Java developers.

Android ART is, effectively, a native compiler for a Java-targetted (but not JVM) bytecode too.

vips7L8• 7 years ago

I think one of the main use cases of graal native will be for container's with smaller memory footprint (where GO traditionally shines) or where startup time needs to be fast.

soulnothing2• 7 years ago

It's alpha/beta there is a lot of talk about concurrency and memory management.

But yes this goes down to llvm. You can also import and compile c/c++ libraries via headers. I've been doing it recently.

This is the strength with multi platform declarations. you can write a back-end service then pick the best run time for that component.

https://kotlinlang.org/docs/reference/native/c_interop.html

jillesvangurp5• 7 years ago

This is correct. It's a proper compiler (on top of llvm) and when you use it, you can't use Java classes or libraries. Instead, Kotlin has a notion of multi platform libraries with e.g. serialization, http, and IO libraries that you use. Short term this is aimed at mobile developers looking to build libraries that compile to IOS and Android. Long term this will likely pop up in other places as well.

There's also a javascript transpiler and tools to adapt typescript definitions so you can use Kotlin for react work or node.js work as well.

vmchale• 7 years ago

The Null II example and the Elvis operator look like special cases of monadic bind/functorial map.

tdelev3• 7 years ago

I have been extensively programming in Kotlin in the last 2 years coming from a 10 years Java experience. Even Java advanced a lot from from version 8, still it is very far behind in reaching the pure joy of programing in Kotlin, especially in functional style. Immutability with 'val', data classes, functions as first class citizens, destructuring, if/when expressions, just to name a few of the features than enables this.

Also, the great 100% interoperability with Java makes possible to migrate part of your codebase to Kotlin and using tons of already proven and great libraries in the Java ecosystem. On top of the Kotlin standard library includes many improvements of the existing Java classes from collections to String, and all of this using extension functions, one very usefull and powerful feature.

I can keep going on and on, but to conclude Kotlin is not just Java with improved syntax, but completely new modern programming language incorporating or "borrowing" some of the best features from Scala, C# and other popular programming languages. So in my opinion it is a great language which has a lot more funtional features than Java, but still pragmatic and easier to learn than Scala.

pjmlp7• 7 years ago

There is no 100% interoperability with Java.

Try to call co-routines from Java, use SAM types with default methods from Kotlin, just for starters.

tdelev3• 7 years ago

I was mostly referring to the Kotlin calling side of Java code and libraries, and yes you're technically right that would mean only 100% compatibility with existing Java code and not interoperability. But, when moving forward to using exclusively Kotlin and not building libraries that will be Java compatible that is totally ok.

ragnese2• 7 years ago

'val' does not make something immutable. It makes it read only. That's very different. You can still call a mutating method of the val entity.

tdelev3• 7 years ago

For sure, declaring something as `val someReferenceOfMutableObject` will not make the object itself immutable, only the reference. The case I had in mind was when creating class with only `val` fields, and that would certainly make that class immutable.

echelon• 7 years ago

All of this stuff will eventually wind up in Java, and when it does, Kotlin is going to feel an awful lot like Coffeescript. The Kotlin proponents of today are going to feel a bit silly.

I predict there's going to be a lot of effort wasted porting old Kotlin code to Java 20 or some such.

Willing to place a longbet on it.

enitihas2• 7 years ago

But all of this stuff simply can't end up in Java, because of backwards compatibility. For example, kotlin object references are non null by default. That is not something Java can easily bolt on. I think there should be many such features.

xixixao• 7 years ago

Certainly Kotlin vs Java looks a lot like CoffeeScript vs JS.

For one, CoffeeScript had great impact on JS, and still has a few advantages (along its disadvantages). Perhaps Kotlin will play the same role.

But I'm doubtful Java can evolve as JS did. For one, the philosophy and speed of development of Java is very different, and kinda set in stone. But perhaps more importantly, types are part of Java, and they need to be backwards compatible. I think this will make it extremely hard to adopt some of the sane defaults from Kotlin.

Zarel• 7 years ago

Having lived through the CoffeeScript thing, the main issues were:

1. CoffeeScript required a compile step; JavaScript didn't. It also meant that you needed to do your debugging in JavaScript, and deal with a lot more leaky abstractions. On the other hand, Kotlin and Java both compile directly to JVM bytecode.

2. CoffeeScript had a lot of features that work very unpredictably, like a number becoming an array of numbers if you add more lines at the same indentation level (which also means that your array will surprisingly become not an array if you delete too many entries). A lot of people only used CoffeeScript because there was no alternative, rather than actually liking it, and they were the first to jump ship when ES6 gave them an alternative.

Kotlin doesn't have any of these issues. It really is an improved Java.

dionian• 7 years ago

what i want to see is kotlin vs scala

AndrewBissell2• 7 years ago

Very nice catalog of comparisons. IMO it could also use a section on "Generics," Kotlin's declaration-site variance is a nice improvement over Java wildcards.

https://kotlinlang.org/docs/reference/generics.html

thom• 7 years ago

There are very few of these examples that don't just make me feel exhausted compared to the Clojure version, but I realise it's a different set of priorities entirely.

zonidjan• 7 years ago

This seems great.

For someone who already knows Kotlin.

EsssM7QVMehFPAs• 7 years ago

Kotline looses me at val vs. var

So much focus on readability otherwise, what happened there?

jrempel• 7 years ago

value vs variable. As someone that works on both Kotlin and Java daily, what is issue? 95% of the time I'm using val.

Larrikin• 7 years ago

They also look completely different in the IDE

_akei3• 7 years ago

Whenever I see an article comparing a market leader with an underdog, I always know that the article will be biased against the market leader. It is human nature to root for the underdog. What was the reason for not starting with variables II? I suspect the author wanted to manipulate our minds right there. It is obvious that Java version is the better of the two but they decided to start with a variable with final. Ternary operator for Kotlin doesn't look like ternary to me. It is just an inline if\else.

guelo3• 7 years ago

The missing ternary operator makes no sense considering they have the ?: operator for null checks.

_akei3• 7 years ago

They explain it here[1] on their discussion forum but still it doesn't make sense to me. If is a statement in every language I know and returns a value, but still those languages have ternary operator. I suspect they don't want to end up with a language similar to what we already have. They want to be different. Even when it isn't necessary.

[1] https://kotlinlang.org/docs/reference/control-flow.html

oriolid2• 7 years ago

What's the difference between ternary operator and inline if/else? Is there even any reason for if/else that doesn't return a value (that may be void/unit/similar)?

It is also obvious that Java version of the variable syntax is awful and just asking for unintentional modification.

madiathomas7• 7 years ago

What's the difference between ternary operator and inline if/else?

There is no difference. Ternary operator is a syntactic sugar for if/else.

Is there even any reason for if/else that doesn't return a value (that may be void/unit/similar)?

Main reason why an if statement returns a value is because it is used to test if condition is true or false. If it returns other values, it was going to make it more complicated. Especially when you have an if statement with multiple conditions that must be ORed or ANDed.

What is awful about the variable syntax? This syntax was copied directly from C language.

Jataman606• 7 years ago

Why is variables II better in Java? Its almost the same with advantage on Kotlin side with type inference. Also ternary operator isnt needed in Kotlin since if/else itself can return value, so its just example to show so people dont try to look for it in Kotlin. Overall its not even an article, its just a showcase of differences in syntax and idioms in both languages, i cant fathom how could you be manipulated with that.

madiathomas7• 7 years ago

Clear and concise to someone new to programming. Also less typing. Comparison of an a market leader to a new entrant is designed to make you switch from market leader to new entrant in the market.

lenkite2• 7 years ago

Raw, multi-line strings are coming in JDK 13 thanks to https://openjdk.java.net/jeps/326

Polyisoprene2• 7 years ago

Java 13 was released 2 months ago.

lenkite2• 7 years ago

I am so outdated. (Our company uses an internal licensed version of the JDK and we don't have JDK 13 yet)

aliakhtar9• 7 years ago

It pisses me off a bit to not see Scala mentioned anywhere. Scala has everything Kotlin has, and a lot more.

cortesoft• 7 years ago

I am not a user of either, but my understanding is that Kotlin is a lot easier to use with existing Java projects.

aliakhtar9• 7 years ago

Absolutely untrue, Scala is completely backwards compatible with Java - you can use all your java code in Scala and even write scala as mostly a better Java.

wskinner• 7 years ago

Which could be considered a reason to use Kotlin instead. Scala is a more powerful footgun. You pay for the power in overengineered code, slow compile times, and worse compatibility with other JVM languages.

aliakhtar9• 7 years ago

overengineered code

False, scala is really concise.

slow compile times

A few seconds slower on average, you mean

worse compatibility with other JVM languages.

Its completely backwards compatible with Java.

pkolaczk13• 7 years ago

Scala compatibility with JVM is the same as Kotlin's. It is implemented the same way in both languages - they compile to JVM bytecode and as long as you keep away from non-Java features, interoperability is good both ways. If you start using stuff not directly supported by Java like default arguments or multiple inheritance of traits, then calling Scala/Kotlin code from Java is similarly bad experience. Scala has also a few more non-Java features e.g. macros or implicits, so I get how you could end up with this impression. Just don't use these features of you need to call your code from Java.

As for compile times, Scala with Bloop is the fastest of JVM languages I ever saw. We switched to compile Java with Bloop because it is orders of magnitude faster than Maven/Gradle. Bloop works for Java and Scala, but not Kotlin. So Kotlin, having really nothing comparable at the moment, is currently the slowest to compile from these three languages.

jillesvangurp5• 7 years ago

The Kotlin creators were looking to create a modern language without some of the issues that Scala has. Judging from its rapid growth in popularity, it is doing a few things right.

aliakhtar9• 7 years ago

I think its growing because its the only way to do Android dev if you don't want to do Java 6. For that, its still great, but for any backend programming, you should consider getting the real thing (Scala) and not its watered down copy.

aliakhtar9• 7 years ago

For fun, I'm going to rewrite all of the examples in Scala:

1) Main

def main() = println("Hello")

2) Variables:

val y = 1

3) Options (nulls are discouraged):

val name: Option[String] = None

4) Null 2:

//If bob is not null, get his age, or get a default age

val age = bob.map(_.age).getOrElse(0)

5) Elvis operator

Kotlin:

val result = nullableVariable?.someMethodCall() ?: fallbackIfNullMethodCall()

Scala:

val result = option.map(_.someCall()).getOrElse(defaultValue)

6) String interpolation in scala seems to be exactly the same as kotlin:

val name = "John"

val lastName = "Smith"

val text = "My name is: $name $lastName"

val otherText = "My name is: ${name.substring(2)}"

In addition, you can also have:

val longString = s"""

|This is line 1

|This is line 2, my name is $name

""".stripMargin

7) This shows the same multi-line strings as above, but its unclear if you can have variables in multi-line strings like I showed above in Scala

8) Ternary operator:

val text = if (x > 5) "x > 5" else "x <= 5"

Some bonus stuff which scala has:

9) Case classes:

case class Person(name: String, age: Int)

10) Pattern matching

person match {

  case Person("bob", 13) =>

      println("Matched bob with age 13")

  case Person("sally", _) =>

     println("Matched sally, age unknown")

  case Person(name,age) =>

    println(s"Matched unknown person with name $name and age $age")

   case x:_>

      println(s"Matched unknown item: $x")

}

10) Equality which actually makes sense, i.e

val foo = "foo"

val bar = "foo"

foo == bar //true in scala, no need to foo.equals(bar)

val bob = Person("bob", 13)

val other = Person("bob", 13)

bob == other //true, based on values

val list = Seq(bob)

list.contains(other) //true, based on values

11) .par collections / way better higher order functions

val list = Seq(string1, string2,...)

//Do a parallelized search on list to find all strings <= 3 chars in length:

val shortStrings = list.par.filter(_.length <= 3).seq

12) Try:

val riskyOp = Try( doSomethingRisky() )

riskyOp match {

   case Success(result) =>

        println(s"Op succeeded with result $result")

   case Failure(e) =>

        e.printStackTrace

}

Disclaimer: I wrote all these in the HN textbox, please excuse any typos

gentaro_5• 7 years ago

Could you please also provide Scala versions for the other code snippets on that site? Just what you can come up with from the top of your head?

I'm genuinely interested, having spent the last few years with Haskell and having recently rediscovered and being incredibly awed by the JVM and its ecosystem, and pondering on whether I should refresh what I'd known of Java or just outright embrace Scala.

aliakhtar9• 7 years ago

You should definitely go for Scala if you're coming from Erlang. You'll find it much more Erlang-like.

I don't have the time to convert their whole site right now, sorry, but you'll find the same pattern holds - Scala does everything more elegantly and concisely. Feel free to look up a Scala tutorial.

ulkesh2• 7 years ago

I love the idea and look/feel of Kotlin. I work to learn and use it on my own.

In the workplace, however, the problem for me are the fearful developers who think it is too difficult to maintain a multi-project code base that contains more than one language. I want to continually grow and improve and branch out, sadly I find many I work with who would rather just skate by on what they know (in this case, Java, which I helped to mentor).

I haven’t yet found a way to convince them. I feel the only way I’ll be able to use Kotlin within the workplace is by changing jobs.

Java is still a great language, and the new release model is helpful to get some of the more modern language features found in other languages sooner in the Java ecosystem. And while JEP is a fine governance model for feature development, I still find myself wanting more, sooner, than what it produces.

I welcome any thoughts or suggestions on how to convince others of the usefulness of introducing Kotlin into the workflow. The idea I attempted was that I would begin a new project with Kotlin that, to start, only I maintained — to make it easier for others to begin to absorb the language, at their own pace. It was futile and they simply don’t want to try.

wippler• 7 years ago

I don’t know why but your assumption that others are skating by with what they know rubbed me the wrong way (maybe because I have been on other side of this). There are likely many other valid reasons here - project deadlines (sometimes it is not the right time to pick a new language), consistency of code (having a mix of languages is going to raise hell in code reviews with opinions on some code that could be done better in one language vs other), hiring (does your hiring/onboarding get more complex?), writing idiomatic code (learning a new programming language is easy but writing good code is hard), extreme swing in brevity (people abusing new languages to write concise code using obscure language features, which makes it hard for someone new to jump in).

I am sorry I don’t have any suggestions to fix your problem but I just wanted to provide a bit of perspective. Maybe try thinking from your peers perspective to see what benefits adopting this new language would give and be prepared to answer why Kotlin among a whole class of JVM languages - Scala, Kotlin, Groovy, Clojure.

ulkesh2• 7 years ago

It’s a very small company and I’m the lead developer. I know exactly what is being worked on and what timelines are involved. The replies I got when I suggested all of this was something akin to “Why now and not before? Why this project and not the others?” Even though the majority of what we work on was originally developed prior to Kotlin going 1.0 and I had already laid out my reasoning. It felt like excuses due to simply not wanting to learn and maintain something new simply because they didn’t see any benefit, even though I also explained the benefits in my original suggestion.

Thanks for your thoughts, though, I’ll take them into account.

jariel• 7 years ago

I tried Kotlin for some time and went back to Java.

Kotlin is nice, and on some days preferrable, but the fact of the matter is, it's really not that much more legible or succinct than Java in the long run.

Look at Androind BTE docs [1] - the K vs. J examples side by side, there really isn't that much difference.

In the end, I feel K is just a 'different flavour' of Java, and often I feel that the makers of K are just throwing a bunch of ideas together, without necessarily having a philosophy.

Given a choice between a 'world of J or K' - to me, it's kind of a toss up - but in reality - J is the incumbent. You have to know J and deal with J at every step, all sorts of libraries are in J etc. etc. - so in reality, the offer of Kotlin is really not Kotlin, it's always Kotlin+Java - meaning two languages and paradigms to support.

If this were 1996 and we had to pick between DVD and BlueRay, it would be a difference decision, but in the end, it's not really 'either or', it's J or J+K.

In the end, J is not that much more hard to write and the differences are negligible except for some specific things ... so I've switch back to J and don't miss K.

[1] https://developer.android.com/guide/topics/connectivity/blue...

didibus• 7 years ago

To those who've done a lot of Kotlin, does it actually alter your programs' design and structure? Your approach to problem solving? Does it open new doors in how you choose to think about and attack a problem? In a nutshell, do you think your programs are better because you chose Kotlin over Java and why?

jillesvangurp5• 7 years ago

I've converted a lot of Java backend code to Kotlin. You usually start out with the intellij converter. I tend to go class by class. That leaves you with something that nearly compiles but not quite. After addressing that, you typically end up with some needlessly nullable types, lots of mutable types, some misguided generics and a few other java-isms that are easily fixed. So, far you've not really changed the structure of the code, you're merely improving it and making it more safe to use. I usually get the process above over in a few minutes for a single class; it's not hard and I would argue the resulting code is already massively better than what you started with.

After that, there are probably a few places where idiomatic use of Kotlin library and extension functions can improve things. I tend to that as I stumble on opportunities to do so. This stuff is great for getting rid of boiler plate. E.g. Kotlin's internal DSL language features can replace a lot of ugly builder pattern code. Also having constructors with default arguments removes the need for having builders or having multiple constructors. Same for functions.

Converting streams to sequences and restructuring statements with nested returns to return the result of a complex expression helps to. Using when instead of if makes things nicer. Etc. Lots of stuff to use.

My programs are definitely shorter in Kotlin and safer (e.g. nullability). Shorter is correlated with lower maintenance cost in literature on software engineering. Some things that Java is ok with are compile errors in Kotlin. So, safer is better in my book as well.

KorematsuFred• 7 years ago

A lot of this could be misleading, a programming language can have excellent syntax to do something small and yet might turn out to be a horrifying if you are going through a complex system.

Having worked with Kotlin I do love the language though. There are some features like extensions which I hate. But in general I love the syntax though I do not find any significant advantage of using it over java.

balladeer• 7 years ago

Though I do find Java's String concatenation cleaner than Kotlin's (refer: Strings II comparison/example, the 2nd last)

peter303• 7 years ago

Kotlin is people impatient with the glacial evolution of Oracle Java.

m23khan• 7 years ago

Frankly, I find Kotlin syntax a lot more meaningful as it contains much less boilerplate code than Java. And the same time, though, I believe Kotlin can only be truly appreciated if you are coming in from experience with Java.

The thing I found hard at times with Kotlin is that it allows/relies on Java classes/frameworks but almost all of those classes/frameworks have their documentation (and only resources) written in Java so you have to have that additional mental step of translation between the two languages.

If you are not competent with basic Java, you may struggle to utilize those Java classes in Kotlin effectively.

Finally, when it comes to hiring people/finding job for Kotlin development, outside of Android jobs, there are very few positions requiring Kotlin which in terms means that there are very few non-mobile developers working with Kotlin as compared to Java. Now this may not be that much of a concern to us Developers, but for Management and leadership, it can raise a big concern towards adopting a language which from perspective of labor market comes across as a niche.

Having said all this though, I have no doubt at least in Android development, Kotlin will replace Java as programming language of choice but I don't think it will find traction beyond mobile (to displace / challenge Java).

UserIsUnused• 7 years ago

Backend kotlin is growing fast, not as much as android, but it is growing. You can notice big frameworks all adding kotlin niceties.

oblio• 7 years ago

Yeah, Gradle added support, so did Spring, Micronaut, etc.

gentaro_5• 7 years ago

I think I can confirm your sentiment. As far as I can tell, which, however, is not much as pertains to the JVM, apart from polyglot projects, Kotlin is a rarity.

I'm rather unfamiliar with Kotlin as a language. Is Kotlin for Android rather idiosyncratic as is Android Java? In other words, is there a superset of language features in Kotlin that goes beyond Android and is more expressive than modern Java?

ptx• 7 years ago

There is no special Kotlin for Android - it compiles to JVM bytecode and works just as well on any JVM as on Android.

It has lots of language features that make it more expressive than Java (try doing constructor dependency injection in both!) but these are not specific to Android.

thu21116• 7 years ago

It's actually not that rare, in my experience. Job adverts can be quite misleading in this case. Kotlin jobs are usually advertised as Java jobs. For a couple of reasons:

Firstly, quite a few large shops have started to use it, but usually due to grassroots bottoms-up activity of the sort that takes a while to percolate through to recruiting departments in distant departments where changing a job req is a heavy process.

Secondly, there's really not much incentive to try and change job reqs like that because it would be extremely hard to advertise via job reqs We use Kotlin but you don't have to know it to apply. To a non-technical recruiter or HR department this looks like a useless statement and will frequently get "fixed" to what you "really meant", something like "Java experience is required, Kotlin highly desirable" which might just put off candidates who don't know what Kotlin is or how easy it is to learn. You're just restricting your pool of candidates for no reason in a highly competitive market.

Much better to advertise the usage of Kotlin in places where developers looking for new opportunities might notice and leave the job reqs alone, and let Java devs get up to speed in the first few days. For example:

https://medium.com/ing-blog/introducing-kotlin-at-ing-a-long...

Edit: To answer your later question, yes, Kotlin goes beyond Java in a lot of ways other than nicer syntax. For instance it has a different (better) generics model, it has far more type inference, it has sealed (sum) types, it has language-integrated coroutines, it has compiler plugins that automate, amongst other things, serialization, it has delegated properties and interfaces, it has type aliases, it has extension functions etc.

I suppose a lot of these can be considered "just" better syntax than Java (except for coroutines and generics), but, at the heart of most programming languages is making patterns that are possible in other languages much easier.

antfarm2• 7 years ago

When hiring Android developers, experience with Kotlin is a great filter that separates the passionate from the lazy ones.

gentaro_5• 7 years ago

You mean passionate ones embrace Kotlin and the lazy ones stick to Java?

hav• 7 years ago

Are those the only parts of the spectrum that exists? Passionate and lazy?

I'd say that sentiment is lazy. There are lots of reasons why someone wouldn't or couldn't spend time learning Kotlin (kids, other family, other hobbies, list could go on).

_3sno2• 7 years ago

I think one feature of Kotlin that is underestimated is extension functions. Combine them with autocompletion and you've got a great developer experience. Finding the method you need no longer requires a Google, and optimisation pays off massively in terms of productivity by tightening the development loop.

zaphirplane• 7 years ago

Extension functions are dispatched statically which can be surprising if you can’t tell what is an extension and what isn’t

ulrikrasmussen2• 7 years ago

Kotlin is much nicer than Java, that's for sure. It strives to be compatible both ways (calling Java from Kotlin and vice versa), which I think has helped with its adoption. It also means that it cannot have very wild features that can't be mapped nicely to the world of Java, which I think has its downsides.

My main gripe with Kotlin is some of its design choices for syntax. I really really really don't like its syntax for lambdas, specifically. A code block in curly braces could be both a lambda with an implicit argument, or a list of statements. You have to inspect the context to see which one it is, or rely on intelliJ to make the former type slightly bolder. That is so bad for comprehension, and I think the only reason it was done like that was to allow for some cute hacks where control flow constructs such as map, fold etc. could be implemented using lambdas and still look like regular imperative code.

Another thing is that you can create lambdas with an implicit binder that you can refer to as "it" inside the body. It may save you one or two keystrokes, but it also encourages the programmer to be lazy about naming things. Combined with the fact that curly braces are overloaded, whenever I see "it" in code, my eyes scan frantically for the first opening curly brace, and I then have to determine whether it is a lambda with an explicit binder (then it isn't my binder, and I have to continue searching), a statement block (then it also isn't my binder), or a lambda with an implicit binder. Don't get me started on nested lambdas with implicit "it" binders that shadow each other.

thu21116• 7 years ago

Well, they see it more as a core language feature than a cute hack. Kotlin 1.0 was big into DSLs as a competitive advantage, though I don't think it got adopted in the way they hoped and I don't see much talk about it anymore. But the idea was you can make libraries where you can write code like this:

    val page = html {
        head { title = "Title" }
        body {
           etc
        }
    }

It looks like it's a part of the language and naturally integrates with features like code folding, but it's actually all just functions and objects anyone can create.

DSLs have taken off in one area: UI construction. There's TornadoFX for JavaFX, SwiftUI on Apple and JetPack Compose for Android. I've tried both new and old approaches extensively and to be honest I'm not sure this is actually better than using a proper GUI builder, but for small fragments of UI it's pretty neat. Sort of like what JSX does in React but more principled and type safe.

ulrikrasmussen2• 7 years ago

I don't see why you can't create DSLs with an equally compact syntax which doesn't overload the curly braces. Yes, it would look different, but it would be more readable. Curly brace lambdas give a first impression of readability, but they really are not when you consider how they affect the binding structure.

mike_kamau• 7 years ago

Kotlin is like a virus. Once you use it in a non trivial project, it infects you and takes over your body and mind. Every time I look at Java code in my Android apps, a part of my body hurts. Luckily there exists a Java to Kotlin converter.

jmkni• 7 years ago

It reminds me of moving from VB.Net to C# years ago!

psychoslave• 7 years ago

Not to defend Java, but some examples seem just unfair:

    if (nullableVariable != null) {
        boolean success = nullableVariable.someMethodCall()
        if (success) {
            return success
        } else {
            return fallbackIfNullMethodCall()
        }
    } else {
        return fallbackIfNullMethodCall()
    }

    // Wouldn't that work just as well ?
    if (nullableVariable != null) {
      return nullableVariable.someMethodCall() || fallbackIfNullMethodCall();
    }
    return fallbackIfNullMethodCall();

Ok, that is still more cluter than the kotlin elvis operator, but more fair, isn't it?

boring_twenties2• 7 years ago

100%, who the hell would write if (success) return success. Come on.

afandian4• 7 years ago

How would you handle the else clause?

RyEgswuCsn• 7 years ago

Would this work?

  return Optional.ofNullable(nullableVariable).map(v -> v.someMethodCall()).orElse(false) ? true : fallbackIfNullMethodCall();

AnyTimeTraveler• 7 years ago

Why not replace the tenary operator at the end with the method call in the or else block?

return Optional.ofNullable(nullableVariable) .map(v::someMethodCall) .orElse(fallbackIfNullMethodCall);

That also looks much easier to understand, at least to me.

dukoid• 7 years ago

return nullableVariable != null && nullableVariable.someMethodCall() || fallbackIfNullMethodCall()

afandian4• 7 years ago

I like Kotlin (as a half-way house in a Java codebase to something purer like Scala) but I'm worried about being locked in in future, and that becoming a liability in a codebase 20 years from now.

Does anyone have experience of emergency automatic conversion back to Java?

(Edit: Never used Kotlin but I like the look of it)

mrkeen3• 7 years ago

It sounds like you got locked in.

afandian4• 7 years ago

Locked into Java, yes. At some level it's unavoidable, you have to choose some kind of stack. And of course there are different kinds of ways to get out of lock-in. One of them is being able to convert to a common 'lower' language.

I've not used Kotlin but I would be more likely to if I knew that avenue was practical.

thu21116• 7 years ago

There's no direct conversion back. IntelliJ has a decompiler that produces reasonable-ish Java code based on the debug symbols, so you get things like local variable names and obviously method/class names back, but, it's a decompiler, so no code comments. And Kotlin constructs frequently require synthetic Java variables to be created that were implicit in the Kotlin, so you have to clean up the result quite a bit.

However note that Kotlin and Java code can co-exist very closely in the same codebase. In the same way you can incrementally port a Java codebase to Kotlin, so too can you incrementally port Kotlin to Java. There's just no automatic tool for it like there is Java->Kotlin.

afandian4• 7 years ago

Thanks for that. I think I'd misread something then and thought that it could work both ways.

jillesvangurp5• 7 years ago

I think the reason a Kotlin to Java converter does not exist is mainly because there's simply no demand for it in the Kotlin community. In my experience it's a one way street and people generally have no desire whatsoever to go back after they start converting Java code to Kotlin. There's nothing particularly hard about it; it all compiles down to the same bytecode.

People keep bringing up Scala as a "purer" language. This seems to be true in the minds of Scala purists mainly. I've done Scala, IMHO it's a very messy language that seems to result in unwieldy code bases that was made for wannabe functional programmers that need a halfway house on the way to a proper functional language (like Haskell or Elixir).

volgar1x• 7 years ago

Kotlin really shines when it comes to async programming. This is some code I wrote using Vert.x with Kotlin extensions :

    router.get("/api/article/:id").coroutineHandler { ctx ->
        val news = newsRepository.get(ctx.pathParam("id")) // no need for await
             ?: return ctx.respondText(404, "Not Found") // can still use basic code constructs
        ctx.respondJson(200, jsonObjectOf("news" to news)) // actually an extension method i wrote
    }

nurettin• 7 years ago

Out of topic, talking about language defaults, I wish C++ defaulted to const reference instead of value. True that it would lead to some pitfalls such as having to explicitly copy values during initialization, but it would make things much less verbose.

dep_b2• 7 years ago

These examples don't show the true power of Kotlin, for example pattern matching is super powerful and helps to put a much more solid and readable logic in your applications.

Still a lot of Kotlin I see from my Android colleagues suffers from all the CONSTANT_STRING_TYPED magic and onion architected* stuff either inherited from the libraries and API's or ingrained into their programming habits.

* many layers, and every time you peel off another layer you feel more like crying

ljackman• 7 years ago

I wonder whether Project Loom will create a split in the Kotlin ecosystem between coroutine-based concurrency and Loom lightweight thread-based concurrency.

Java will have a similar problem with CompletableFuture and third-party projects like Reactor used in Spring WebFlux.

However, Kotlin baking in language syntax for a competing concurrency model will exacerbate the split.

With Java already having type inference, concise lambdas, and with upcoming records that can already be faked in current versions via Lombok, the value proposition of Kotlin seems questionable outside of Android with its held-back version of Java.

Clojure is another story entirely, offering a very different and compelling way of thinking about computing on the JVM. By contrast, my developing view is that Kotlin is different enough to require learning something new yet not different enough from modern vanilla java to offer substantial advantages.

ragnese2• 7 years ago

So choosing Kotlin over Java boils down to some syntactical differences? Nah. The syntax differences between Kotlin and Java are not even that huge. It's not like choosing between Elixir and Erlang, or between JavaScript and ReasonML.

The main differences between Kotlin and Java are:

* Kotlin forces null checks.

* Kotlin arrays are invariant.

* Kotlin does not have checked exceptions.

* Kotlin has first class functions.

* Kotlin sealed classes don't really have an analog in Java, AFAIK.

I don't find data classes to be a big deal. The best thing about them is you get `copy()` for free.

fiatjaf• 7 years ago

Kotlin vs. Java

Related Stories