
Kotlin: A Language with a Bright Future - venturis_voice
http://www.venturi-group.com/blog/getting-started-kotlin/
======
lmm
As a Scala programmer, Kotlin always feels like a language that frustratingly
_almost_ gets it, but is infuriatingly unwilling to listen to experience of
what works in large codebases. Look at the examples on
[https://philipnilsson.github.io/Badness10k/escaping-hell-
wit...](https://philipnilsson.github.io/Badness10k/escaping-hell-with-monads/)
\- I think Kotlin has literally every one of those ad hoc solutions built into
the language, but stubbornly avoids making the generalisation. In small
examples ad hoc solutions look great, but to succeed in large codebases a
language needs a generality and consistency that Kotlin lacks.

E.g. already there's no way to reuse logic between code paths that operate on
Kotlin nullable types, Java Options (needed for compatibility with Java
streams or more generally other JVM libraries), or rust-style Result types
(for which there are several Kotlin libraries already, because it's a very
useful concept and the language mostly has the facilities to support it), even
though all three behave almost identically and you would often want to do the
same thing in all three cases. But since the language won't let you represent
what these types have in common, your only option is to copy/paste the code.

~~~
bitL
Some of those examples trade development hell with debugging hell (e.g. list
comprehensions). While working with Python's list comprehensions, I often find
myself writing loops instead of super-complicated incomprehensible list
comprehensions. So hijacking your statement, those ways work well for simple
use cases, not so much for real-world ones.

~~~
lmm
I find Python's list comprehensions unusable because they're backwards from
how I'd expect. Thankfully in Scala the syntax is almost exactly the same; you
write

    
    
        for {
          a <- list1
          b <- list2
        } { do something}
    

for an imperative for loop, and

    
    
        for {
          a <- whatever1
          b <- whatever2
        } yield { ... }
    

for the general comprehension. In Python you have to put the equivalent of the
yield right at the start, which is just so different from how everything else
in the language works.

~~~
kazinator
Whoever designed the comprehension syntax for Python was perhaps enamored of
the "such that" math notation { _expr-with-vars_ | _constraint-predicates_ }.

[https://en.wikipedia.org/wiki/Set-
builder_notation#Sets_defi...](https://en.wikipedia.org/wiki/Set-
builder_notation#Sets_defined_by_a_predicate)

~~~
actsasbuffoon
That's because Python's list comprehensions were derived from Haskell's
implementation:
[https://wiki.python.org/moin/PythonVsHaskell#List_Comprehens...](https://wiki.python.org/moin/PythonVsHaskell#List_Comprehension_Syntax):

~~~
lmm
As per
[https://wiki.haskell.org/List_comprehension](https://wiki.haskell.org/List_comprehension)
, many Haskell users prefer to use do syntax (indeed I wasn't aware that the
list comprehension syntax existed).

~~~
actsasbuffoon
Agreed, I never use list comprehensions in Haskell. I feel like they're almost
always harder to read.

------
adamnemecek
I agree 100%. Kotlin compiles to JVM, JS and very soon also to native via
LLVM. That means you can ship a web app (both backend & frontend) and mobile
clients (for android and soon iOS) in one language. This is unprecedented.

For JS, you can use all you favorite front-end frameworks like react (here's
an example by JetBrains themselves [https://github.com/Kotlin/kotlin-
fullstack-sample](https://github.com/Kotlin/kotlin-fullstack-sample)) or
cycle. And you can import typescript definitions.

Also first class IDE integration.

So yeah, bright future is an understatement.

I guess clojure/clojurescript and scala.js are somewhat similar however I feel
like Kotlin has an insane amount of momentum behind it right now.

~~~
djm158
You could also do this with JavaScript correct? Node.js back end with whatever
front end framework and then use something like react native for mobile?

~~~
adamnemecek
But then you'd be writing JavaScript and who wants that. TypeScript is maybe
ok-ish but TS is just putting a lipstick on a pig. Like, ignoring other
issues, JVM at least has decent concurrency and with quasar, you get processes
similar to erlang.

~~~
rictic
What about the other side of that coin. Does a small amount of idiomatic
Kotlin compile down to a small amount of JS, or a large amount (in bytes,
after gzip)?

~~~
adamnemecek
I don't have extensive experience with it but it's not too bad compared with
other JS transpilers.

------
rdsubhas
I'm neither pro nor con with Kotlin, but let's look at history and parallels.

At its peak, Eclipse released Xtend. At that point, Eclipse was the IntelliJ
of today, everyone assumed Xtend would be the next Java with full support of
Eclipse tooling. Today, well, anyone remembers it? But its still there, check
the features:
[http://www.eclipse.org/xtend/documentation/index.html](http://www.eclipse.org/xtend/documentation/index.html).

You will see thousands of articles on kotlin vs java, but only a handful on
kotlin vs xtend, because of the cycle.

Groovy. Same cycle, same result.

Javascript has a large share of syntactic forks. All of them had this hype-
cycle. Coffeescript was "de-facto way" to write cross-browser eloquent
javascript at one point.

There are few lessons from history: Syntactic language forks are what they are
- forks. It takes equal amount of tooling and expertise to maintain them. When
the next two versions of Java releases, the hype cycle will again turn tides.
"X is the better Y", "Groovy is the better Java" \- never, there is only one
Java, there is no better Java.

The best approach is to make the language itself extensible. Look at ES-next
and babel. Every language addition is a proposal, and proposals can be
implemented as language plugins with stages 3/2/1/0\. This effectively
rendered most syntactic forks almost meaningless and unnecessary. Have an
idea? Extend to the language directly! The most important part - tooling -
which is eslint, AST parsing, intermediate representations, code formatting,
etc - have been shifted to work on top of language plugins. Now some of you
will talk against babel, and how different projects use different babel
settings - but given all the history, babel is the best way to pragmatically
evolve a language we've ever had so far.

Java has a longer mature JSR and language proposal process, just like ES. I
really regret that Jetbrains decided to create yet another language fork,
while being in the position to create the next babel for java.

Will Kotlin be different from all the previous cycles? Only real 2020 will
tell, but until then, the only reference available is history.

------
mumphster
Cached:
[http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://www.venturi-
group.com/blog/getting-started-kotlin/)

------
pmelendez
Honest question. I have been checking Kotlin since a while but haven't found a
compelling case for me to start using it. All the features I have seen so far
are syntactic sugar.

Even the article quote something around those lines: “The syntax for Kotlin,
like Apple’s Swift, is clean and modern. The reaction amongst developers
learning Kotlin is not dissimilar to the initial experiences with Ruby years
ago. The syntax is so intuitively designed that even without any previous
exposure it’s almost possible to guess it.”

The question would be: Am I missing something? Is syntax the only reason that
makes people excited about it? or are there any new abstractions/ideas that
are exclusive for Kotlin?

~~~
lmm
To have a clean/nice/familiar syntax in a language with a semi-decent type
system is actually a pretty big deal. What're the other options? Java and C#
are pretty cumbersome, Haskell and OCaml (and to a certain extent F# and Rust)
look weird, Swift/C#/F# are to a certain extent tied to proprietary platforms,
and while Scala actually has a nice core syntax the culture of its libraries
tended to hide that away under a pile of sigils.

~~~
kumarvvr
I can't really pinpoint it, but somehow C# dosen't seem so cumbersome as Java.
Perhaps it's the libraries.

~~~
wvenable
C# isn't as cumbersome as Java.

------
kevinherron
I love Kotlin. It's the sweet spot between Java and Scala. Been using it for
backend stuff since it went 1.0. Coroutines are a game changer for a lot of
the work I do.

Really excited to see how Native progresses as well. I've got a handful of
projects what would benefit from having the 90% core written in Kotlin with
some JVM and Native portions plugged in, ultimately meaning the library is
available on both JVM and Native.

------
russellbeattie
This may not be the most educated opinion, but I tend to think of "languages"
that compile to the JVM as just elaborate macros. My reasoning is that in
order to use Kotlin (or Scala, Groovy, etc.), you will inevitably have to know
Java very well, as most of the language is just syntactic sugar, and you'll
almost always have to interact with standard libraries and SDKs written for
use with Java.

A language isn't a "real" language unless you can live in it and be blissfully
ignorant of anything else. I don't need to know C in order to use Go, or
Python. I don't need to know Ruby in order to use JavaScript. But it'll be
relatively impossible to write code in Kotlin without interacting with Java
constantly. Which means context switching and maybe even bugs.

------
meddlepal
I have been using Kotlin in the backend (along with Python) since late 2015 at
Datawire.io and it is a pleasure to work with.

~~~
duiker101
May I ask you what frameworks and everything are you working with? I've been
enjoying django for a while now but I am really looking for new excuses to use
more kotlin

~~~
meddlepal
I like to keep it simple. I've never been a big fan of most big "mainstream"
JVM frameworks like Spring. I much prefer using libraries and writing a small
amount of glue code to keep it understandable rather than making others become
framework competent before hopping on a project.

For web services I use Sparkjava but I'm thinking of moving to Javalin or
http4k because Sparkjava has really slow release cycles.

JSON is either Gson or Jackson. I prefer Jackson just because I know it better
but they're both great.

I use JDBI for database work but I don't have too much of that in my backend
right now. GRPC for cross service communication.

Back in 2015/2016 I used Vert.x a bunch but I really didn't like the async
programming model. YMMV.

Generally I stick to using well known / common libraries written for Java and
then later look for a Kotlin version if I have time to dick around a bit. I
think this is what I love the most about Kotlin is the great interop with
existing Java libraries.

------
bencollier49
As a Python and Java programmer, Kotlin hits the sweet spot for me with the
type safety of Java (+ ecosystem) together with a clean and modern syntax.

All whilst avoiding adding clever/stupid things (cf. Scala, Go, Rust).

------
venturis_voice
Hi all, thanks for commenting on our recent blog post. We share and discuss
all our content on Venturi’s Voice Slack group. Seeing as you know quite a bit
about this topic it would be great if you joined the conversation on there.
We’re a new community based around the blogs and podcasts we release everyday
at Venturi. We aim to consistently deliver valuable content to our candidates
- but we know there is always room for improvement, so your feedback would
really help us out!

The group’s pretty quiet at the moment whilst we’re building up the community
but stick with us as we’re aiming to grow it rapidly.

[https://publicslack.com/slacks/https-venturisvoice-slack-
com...](https://publicslack.com/slacks/https-venturisvoice-slack-
com/invites/new)

------
ravirajx7
Is the link broken?

~~~
mk321
Mirror:

[https://web.archive.org/web/20171120143056/http://www.ventur...](https://web.archive.org/web/20171120143056/http://www.venturi-
group.com/blog/getting-started-kotlin/)

or:

[http://webcache.googleusercontent.com/search?q=cache%3Ahttp:...](http://webcache.googleusercontent.com/search?q=cache%3Ahttp://www.venturi-
group.com/blog/getting-started-kotlin/)

------
rb808
I like Kotlin, but I'm thinking of just concentrating on Java and giving up on
Scala and Kotlin.

Scala was much better than Java but now the gap has closed and while its still
nice to work with, I feel most applications would be better to stick to
mainstream Java.

Kotlin is interesting but after Scala experience I'm reluctant to invest all
over again. Is it worth it?

~~~
taesis
May I ask where you invested your time in learning Scala (e.g. reading the red
book, studying type theory, syntax + stdlib + collections, etc.)? I found I
could read simple Kotlin in a couple afternoons, and after a couple weekends,
I felt pretty comfortable with it. The only difficult concepts to wrap your
head around, I'd say, are type safe builders [1] and coroutines [2], but you
certainly don't need to know those to be productive in the language.

To answer your specific question, however, if you're doing Android development
it's worth it :) otherwise, it's up to you/your specific situation.

[1]: [https://kotlinlang.org/docs/reference/type-safe-
builders.htm...](https://kotlinlang.org/docs/reference/type-safe-
builders.html)

[2]:
[https://kotlinlang.org/docs/reference/coroutines.html](https://kotlinlang.org/docs/reference/coroutines.html)

------
iLemming
I skimmed through the comments, looked at code examples - they hurt my eyes.
Read arguments of Scala people. Read about C# vs Java. For the life of me I
don't get it. Why people simply wouldn't use Clojure?

------
pankajdoharey
Does anyone remember Groovy this is just a fad Kotlin would be forgotten with
time, i fail to see the real technical innovation in Kotlin.

~~~
nerdponx
Since you seem to have some technical expertise in this area and strong
opinions, it would be nice if you explained why you felt that way, for the
benefit of us who are not experts. AFAIK Groovy is currently in use at lots of
very major companies.

------
edpichler
Could someone tell me if Kotlin and TypeScript are similar solutions? I put
both on my "next reads" list.

~~~
lmm
TypeScript has a marginally weaker type system (it's structural and has
soundness issues with variance) and is more focused on being close to JS; it
has very good ecosystem penetration (e.g. a lot of libraries publish
typescript definitions even if they're not written in typescript). Kotlin is
intended as a general-purpose language that can also compile to JS. So I'd say
it depends on how web-oriented you are.

~~~
edpichler
Got it, thanks for your summary.

------
lobo_tuerto
Woops 404 on the link.

~~~
venturis_voice
Hey sorry about that annoyingly our website went down not long after I posted
the link, it's working again now though if you wanna dive back in

------
pankajdoharey
To me Kotlin feels like the most overrated copy of Scala.

