
Kotlin 1.4 - ingve
https://blog.jetbrains.com/kotlin/2020/08/kotlin-1-4-released-with-a-focus-on-quality-and-performance/
======
lordnacho
If you haven't tried it yet, here's my seal of approval for Kotlin.

Normally I'm quite reluctant to start a new project in a new language, but
Kotlin edited on IntelliJ just seems so very smooth. I'm doing a side project
which is a game, where most of the website parts are Kotlin.

Most of what I'll say will be a bit vague, I mainly write Python and C++. I'm
also not too clear on what benefits come from the language and which from the
IDE, my understanding is that JetBrains had a lot to do with it so they are
probably connected.

\- Compile times seem pretty fast.

\- Errors seem clear, haven't been as stumped as I'd expected with a new
language.

\- Greytext types that are inferred are super useful. I do wonder how I'd do
if the IDE didn't tell me what the types were. But it basically means you get
all the benefits of type annotation without having to write out the types.

\- The style of using a lot of filter/map/reduce makes my code more terse, but
the greytext hints keep it easy to understand.

\- Great sugars. No need to add getters and setters for every member. Likewise
it seems to change the calls to old Java lib getters and setters. Data classes
can be short and sweet. One-liner functions in-line for simple stuff to keep
simple stuff short.

\- Can still do whatever you want with Java libs. Unit testing for instance
works much the same.

\- Ecosystem has moved nicely with Kotlin. Ktor and Ebean seem to be on board
and pretty mature.

\- Null safety built in makes it clear where you need to do something about
it.

~~~
Matthias247
> \- Greytext types that are inferred are super useful. I do wonder how I'd do
> if the IDE didn't tell me what the types were. But it basically means you
> get all the benefits of type annotation without having to write out the
> types.

Actually the strong-type-inference plus greytext thing is one part of Kotlin
where I'm not sure what to think about it.

When I first saw Kotlin examples on the internet with all the "it.something" I
was "What is going on there?!? What is that supposed to do".

Then the first time I tried writing Kotlin myself everything became super
clear due to that Greytext shown in IntelliJ. However 80% of the time I'm
looking at code is not in an IDE. It's either on code reviews or in the
browser (github, internal code browsers, etc). All the information is not
available there, and one has to be aware again what the implicit types will
be.

The challenge certainly also exists in other langues with type inference (auto
in C++, var in Java/C#, inference in Rust, etc), but for some reason I found
it worse in Kotlin. Maybe due to the commonly used methods which take a
closure/interface as last parameter, and and the fancy builders.

~~~
john_miller
btw it's "type inference", not "type interference"

~~~
Matthias247
thanks - I'll try to remember it. Fixed the text

------
kevsim
As a guy who has written a lot of modern JS but was working in a JVM-only shop
(all tooling etc assumed services were running on the JVM), Kotlin was like a
breath of fresh air. Doesn’t go as FP as Scala (which is a plus for me) but
still has all the nice collection APIs etc that I use frequently in JS.

Really looking forward to seeing what happens with Kotlin native. Compile
times were pretty bad last I tried it but I’d give it another go if they
improved those.

~~~
throwaway8941
>Doesn’t go as FP as Scala (which is a plus for me)

If anyone reading this thinks about using Kotlin and has more positive views
towards FP, there's this project to bridge the gap somewhat

[https://arrow-kt.io/](https://arrow-kt.io/)

~~~
ragnese
Doesn't this require a plugin, though? So it's basically an extension of
Kotlin-the-language.

To those who are using Arrow- why not Scala? Is it just because Scala has too
much cruft? The only thing Kotlin has over Scala (AFAIK) is coroutines, which,
honestly- I don't even love. They're very awkward to use and require unchecked
exceptions for control-flow (and therefore have convention-based rules around
using them).

~~~
valenterry
I think the answer is quite simple. You might start out with Kotlin and get
familiar with it. But when you get thirsty for more, arrow is the logical next
step. Going for Scala would require learning a lot of new stuff and once or
even rewrite your things.

It's the same for Scala and Haskell, which is why Scala is sometimes called
Haskellator - I still would start a project in Scala because I'm more familiar
with it.

------
maxpert
2 years back we had huge debate to choose between Kotlin or Java. While Java
folks thought it was immature to even discuss anything other than Java, we
ended up adopting Kotlin company wide. Looking back at it we don't regret the
decision even single bit! We are using Kotlin and Coroutines to run extremely
heavy services (almost 1K req/sec per pod, with complex logic, few hundred
threads, 6GB RAM and 2 CPU cores). People concerned with Project Loom, should
remember it's backwards compatible & upgrade path can be done multiple ways. I
would highly recommend Kotlin for backend services, you won't have to code
review IDE vomit, depend on annotations, or live with callback hell (project
reactor, rx-java).

~~~
htamas
What framework do you use? I guess not Spring.

~~~
maxpert
Surprisingly spring with webflux works fine too.

------
brzozowski
As a grad student who has been using Kotlin in research for the last few
years, it can also be a great language for data science. Kotlin is one of the
few statically typed languages with scripting and Jupyter notebook support,
and offers some great features for parallel and asynchronous data processing.
Once you set up a project and import the right dependencies, the workflow
really clicks. It works smoothly with the JVM and JS ecosystems, which have a
bunch of fantastic libraries for data processing and visualization. Happy to
answer any questions about using Kotlin for DS/ML if anyone’s curious.

~~~
posedge
How about tooling/the ecosystem? Python has all the scipys, pandas, scikits,
tensorflows, pytorches.

~~~
bmc7505
The tooling is ahead in some ways and behind in others. As a statically typed
language, Kotlin's autocompletion and static analysis is already miles ahead.
More broadly, the JVM has a rich ecosystem of libraries for data processing,
from natural language processing (CoreNLP) to big data analytics (Spark). If
you're looking for something similar to Pandas/Numpy/Matplotlib, maybe check
out Krangl [1], EJML-Kotlin [3] or lets-plot [4]. There are also efforts to
port TensorFlow [5] and PyTorch [6] to the JVM. While not all libraries as
mature as their Python cousins, there are a growing number of native libraries
and JVM wrappers for scientific computing, which provide most of the
functionality and are very ergonomic to use in Kotlin.

[1]:
[https://github.com/holgerbrandl/krangl](https://github.com/holgerbrandl/krangl)

[2]: [https://github.com/mipt-npm/kmath](https://github.com/mipt-npm/kmath)

[3]:
[https://github.com/lessthanoptimal/ejml/tree/SNAPSHOT/main/e...](https://github.com/lessthanoptimal/ejml/tree/SNAPSHOT/main/ejml-
kotlin)

[4]: [https://github.com/JetBrains/lets-plot-
kotlin/](https://github.com/JetBrains/lets-plot-kotlin/)

[5]: [https://github.com/tensorflow/java](https://github.com/tensorflow/java)

[6]: [https://github.com/pytorch/java-demo](https://github.com/pytorch/java-
demo)

------
rockyj
Really good to see these changes. Kotlin is a great language to work with, it
has the stability and performance of the JVM and it writes like Ruby /
TypeScript. I wish more companies were adopting it as their core language and
it is not just limited to Android development.

~~~
renke1
Kotlin really is good and definitely an improvement over Java, but in my
experience (like ~1 year) the language itself makes writing unreadable code
too easy; it also doesn't help that IDEs like IntelliJ Idea often suggest
shorter yet less readable alternatives because it's "idiomatic" Kotlin code.
For perspectice, I am writing "enterprise software" and I am big fan of
TypeScript.

~~~
ImprobableTruth
>suggest shorter yet less readable alternatives

What do you mean exactly? I feel like Kotlin's brevity is what actually makes
it a lot more readable than Java. With Java there's just often so much noise
and fluff that doesn't actually mean much, obscuring what the program actually
does. Could just be my personal preference, but I feel like in general I have
an easier time understanding terse, dense code rather than spacious, verbose
code.

~~~
renke1
I can't give specific examples, but something along the lines of suggesting to
replace an early return in the form of `if (…)` by something like `…
?:return`. The former alternative makes it way easier to spot on first glance
where the functions bails out. The latter hides it in an assignment making it
harder to see.

I should say, though, that I am by no means an expert Kotlin developer; maybe
I just have to get used to idiomatic Kotlin.

~~~
thu2111
Don't take idiomatic Kotlin too seriously. It's not Go where there's exactly
one allowed way to do things. IntelliJ's suggestions go both ways - you can
convert to short form and also back to long form automatically. It's that way
for a reason: you're trusted to pick the right form on your own.

~~~
renke1
I'd agree in general, but that hardly works for larger teams or even multiple
teams. This can probably be solved by a good linting tool, but I am not too
familiar with the state of linting in Kotlin.

~~~
thu2111
The best linter for Kotlin is the IntelliJ inspector, which is very powerful.
You can run inspections from CI builds using TeamCity, at least, probably
other CI builds. You may also configure project defaults to trigger various
patterns as warnings or errors.

Even better, in the latest IntelliJ you can create new inspections from
structural search, which is an AST based matching system. So you have a lot of
flexibility to make your own lints and warnings without needing to write
plugins.

However, I think there's a more general issue here, which is that if you don't
trust your team to write tasteful code, linters will be of limited use. It may
be better to invest in more rigorous code reviews, trainings, style guidance,
mentoring etc. I've spent five years managing technical teams using Kotlin
(yep, early adopter!) and found most of them could handle it just fine. A
little training goes a long way. The worst problems came from developers
creating overly complex abstractions, not playing code golf.

------
pron
As far as the Java platform (AKA "the JVM") goes, Kotlin is painting itself
into a corner. Kotlin was designed in 2009-10, in the Java 7 days, around the
time of the Oracle acquisition, and at a time of stagnation for Java due to
Sun's decline. At the time, Android was also quite similar to Java. Kotlin was
a great design in those conditions. Things are very different today.

Kotlin's design goals are now contradictory. It seeks to be a low-overhead
language, i.e. provide abstractions that don't add overhead over the target
platform, give access to all platform capabilities, and at the same time
target multiple platforms -- Java, Android, LLVM and JS -- over _none of
which_ does Kotlin exert much influence (maybe a bit on Android). Since 2010,
Java has moved away from Android, to the point that there are very big gaps
between the two, and they're only growing.

By both trying to target multiple platforms (with no say in their design) and
trying to add little or no overhead, Kotlin will soon find itself in a bind.
It's coroutines are in conflict with Java's upcoming virtual thread's design,
and its inline classes will cause problems with Java's Valhalla vs. Android.
Kotlin will have to choose to either give up on low-overhead abstractions,
give up on some of its platforms, give up on giving access to full platform
capabilities, or split into multiple languages, each targeting a different
platform. For example, if Kotlin's inline types will make use of Valhalla,
then they won't work on Android, at least not without much overhead.

TL;DR: A full-capability, low-overhead, multi-platform language is hard to
pull off in the long run when you have low market share on all of those
platforms (except Android) and little or no influence on any of them. This was
viable under some accidental circumstances, but those are no longer holding.

~~~
avasthe
^this is an oracle employee speaking

Everyone else puts a disclaimer on HN. You Oracle people are not special.

Edit: I know I am getting severely downvoted for this. But there are some
Oracle shills around here.

~~~
Spivak
I mean an Oracle employee talking bad about their own company in the subtext
is kinda the opposite of shilling.

~~~
ragnese
I didn't downvote either comment, but I do appreciate the person who called
out the individual's affiliation. In the current era of so much astroturfing,
I feel like it's good manners to indicate when you make a comment that you are
an interested party.

------
thu2111
dang, can you update the URL to the actual official announcement instead of
Google's shorter copy?

[https://blog.jetbrains.com/kotlin/2020/08/kotlin-1-4-release...](https://blog.jetbrains.com/kotlin/2020/08/kotlin-1-4-released-
with-a-focus-on-quality-and-performance/)

It's got more detail and is more canonical.

~~~
heinrich5991
Just mail hn@ycombinator.com (see footer).

------
mikece
Given the litigious nature of Oracle, how hard would it be for Kotlin to be
useful without reference to the JVM at all? Is Kotlin/Native ready for prime
time and can it be used for mobile/embedded/IoT applications currently or is
it still a work in progress?

~~~
jillesvangurp
It's used a lot already for cross platform development for android and ios
even though that has been experimental so far. This is where they've been
focusing most of the effort and as far as I know it's usable for that and some
people have already built apps using this.

I've been looking at multiplatform development recently and maintain a few oss
projects on github that are now multiplatform. The build tools are getting
there. The multiplatform gradle plugin has improved a lot over the last year.
Generally you can get stuff working pretty easily. If you need to target IOS
and Android, it's worth a look. Also if you want to share some code with
browsers, it can do that too.

The main issues is with gaps in functionality. E.g. kotlinx datetime just
reached 0.1. There were a few third party alternatives but if you needed
dates, not having a usable datetime library is a bit annoying. That's just one
example. When stuff is missing, you can actually fix it yourself. But of
course that ends up being quite a bit of work.

I think for e.g. command line development on Linux or WASM development for
browsers, the native compiler is not that great yet. They just started working
on WASM only a few weeks ago and posix and Kotlin have not had a lot of
attention. This is also an issue when using kotlin-js with node.js; they've
just not done the work to expose all of the built in node.js stuff to Kotlin
yet. On browsers you get a smoother experience with kotlin-js. Of course
people doing stuff on servers can use the jvm and that's why there's just less
attention going towards native on that front.

So, wouldn't recommend it for IOT just yet unless you are willing to deal with
what is likely to be a rough experience and some gaps in functionality.

The big next pieces are finalizing the transition to the new compiler backend
and improving the multiplatform library ecosystem. They have alpha versions of
the new compilers currently but they are not ready yet. I also expect there
will be lots of activity with both Jetbrains and others releasing
multiplatform libraries. I've actually worked on a few of those and would love
to see this get traction.

------
The_Colonel
Kotlin seems finally like a language designed by people who actually develop
in it.

OTOH Oracle people seem to always focus on the platform issues - green threads
is the next big thing, but it doesn't actually affect 99% of developers since
Java's threading model is just fine for most business applications.

Yet things like missing ability to reasonably express non-nullability (and the
resulting NPEs) hit me every single day, but for Oracle it's apparently not an
interesting enough to work on.

~~~
pjmlp
Great now let them bring the Kotlin Virtual Machine.

Ah, that is what Google is doing for them.

~~~
The_Colonel
No need for this, there's bunch of existing virtual machines. JVM is pretty
nice actually.

~~~
pjmlp
Sure there is, Kotlin users typically bash Java and how much better it is, so
I am waiting for JetBrains to release KVM, Kotlin/Native so far loses in all
frontends against AOT Java based toolchains.

~~~
systems
I dont understand the selling point for a Kotlin VM or Native compilation

Isnt the whole selling point for Kotlin, is that it is a JVM hosted languages,
that give you access to all Java Libraries, framework and tools .. but
purportedly .. is an easier, nicer , more language language compared to Java,
Scala or the other JVM languages

Why go elsewhere, why go native, or develop their own VM ? Any improvement in
the JVM benefits Kotlin, correct or am I missing something ?

~~~
pjmlp
Apparently no, that is why they started Kotlin/Native instead of ping back
into AOT compilers for Java, and in Kotlin forums tends to exist an high
disregard for anything Java.

~~~
thu2111
Actually the story I heard is that Kotlin/Native exists simply because Intel
was laying off a compiler team in St Petersburg around that time, so they came
on the market as a group and could be picked up easily and quickly. And they
wanted to push into iOS.

Could they have done a SubstrateVM/GraalVM competitor instead? Yeah probably,
but that's a very different project to adding another backend to Kotlin. Given
they already decided to make Kotlin "multi-platform" (i.e. js backend) instead
of making Java more portable, it then made sense to go the whole way.

JetBrains also developed TeaVM and arguably it'd have been better to just
invest in JVM related tooling, and keep Kotlin as a JVM language. But I think
they like the idea of it being its own ecosystem. Who wouldn't, in their
position?

------
Jestar342
Kotlin is exploding in the Android sphere. I am seeing more and more
announcements/job postings for Kotlin mobile devs.

~~~
pjmlp
Naturally, Google is pushing it down our throats, providing minimal
compatibility with Java language features post Java 8 and zero JVM
capabilities regarding modules or newer bytecodes.

------
lokedhs
I like Kotlin, but I also feel it's a huge missed opportunity.

I have used Kotlin quite a bit. In particular, I've been working on a
multiplatform project recently which definitely have helped me learn about
some of the less developed parts of the language.

Long ago, I used to do a lot of Java and I liked it a lot (having worked at
Sun back around 2000 was certainly part of the reason). Kotlin, in my opinion,
is a better Java. It does a pretty good job of providing a nice syntax for it,
and these benefits are the first things that are explained in beginners
tutorials to Kotlin.

But, it doesn't really do anything new. There are so many things it could do
to fix long-standing problems with Java, which Jetbrains refuse to implement
due to the fact that the implementation will not be natural to the JVM.

An obvious example is generic functions, or multimethods. This was discussed
on the forums, but quickly dismissed with one of the main reasons being that
it would have to introduce a new dispatch mechanism and so wouldn't be natural
on the JVM. This argument has been made to dismiss many suggested features.

Another reason Jetbrains uses dismiss suggestions is that the new feature
would make the language more complicated and difficult to learn. The refusal
to implement some kind of macro facility falls into this category.

At the same time, this position leads to truly bizarre language behaviour such
as the strange behaviour where declaring a function inline changes the
semantics of the code.

This insistence that the JVM dictate the features makes even less sense since
they also have native as well as JS code generators.

The only unique Kotlin feature that I can think of which is not a result of
the JVM is their support for suspending functions, which is used to implement
their async framework. The problem here is that it semantics can be really
confusing, and can in fact lead to deadlocks if you have a library the needs
to be exposed to Java which internally is implemented using suspending
functions. If these functions are then called by Kotlin code which itself use
suspending functions, you can end up with really strange behaviour.

------
mancini0
I love it. Coroutines make async code concise and much cleaner than Java
completable futures, Kotlin is a supported gRPC language, and the gRPC service
signatures are much cleaner than the java gRPC service signatures, and there
is decent Bazel support. I think the biggest threat to this language is the
$399 iPhone.

------
argestes
SAM conversions finally. I'm in tears!

~~~
wanttocommentt
I was looking forward to this as well. But then noticed you have to write the
fun keyword in front of the interface. Which makes it more like a workaround
than a language feature to me.

------
snafu109
Official announcement:
[https://blog.jetbrains.com/kotlin/2020/08/kotlin-1-4-release...](https://blog.jetbrains.com/kotlin/2020/08/kotlin-1-4-released-
with-a-focus-on-quality-and-performance/)

What's New in Kotlin 1.4:
[https://kotlinlang.org/docs/reference/whatsnew14.html](https://kotlinlang.org/docs/reference/whatsnew14.html)

~~~
ocdtrekkie
Knowing this wasn't a Google thing, I was a bit thrown by the update being
announced by Google. Definitely recommend headlining the original developers'
announcement instead.

~~~
dang
Ok, we've changed to that from [https://android-
developers.googleblog.com/2020/08/new-langua...](https://android-
developers.googleblog.com/2020/08/new-language-features-and-more-in.html).

