
Kotlin 1.0.5 is here - ingve
https://blog.jetbrains.com/kotlin/2016/11/kotlin-1-0-5-is-here/
======
gregschlom
Kotlin has been a joy to use. Really happy with it. Our Android app
([http://play.google.com/store/apps/details?id=com.eatsa.app](http://play.google.com/store/apps/details?id=com.eatsa.app))
is 100% Kotlin (with a good amount of Java libraries of course).

Some highlights:

\- Great type system, with type inference.

\- Full Java interop. You can literally copy/paste Java code from
Stackoverflow and it's automatically translated to Kotlin. It doesn't feel
like 2 different languages. Working with Java libraries doesn't feel awkward
or foreign, like in many other JVM languages.

\- Beautiful syntax that allows to construct some pretty advanced DSL, yet
because it's statically typed the IDE can always resolve the DSL constructs
and take you "under the hood" to the actual code that's going to be executed.
This is in contrast to languages such as Ruby where most of the time when you
encounter a DSL construct there's no easy way to understand what's going on.

~~~
adrianlmm
Why not use Xamarin? it has a better lenguaje (C#) and is free.

~~~
bitmapbrother
Probably because IntelliJ is a superior IDE, Kotlin is a better language than
C# and Xamarin apps look and perform like ass.

~~~
V-2
I like both, but why do you consider Kotlin better than C#?

I also don't get your point about how lame Xamarin apps look. Xamarin apps use
native layout components (could be wrapped with lowest common denominator
abstractions in case of Xamarin.Forms, but it's optional), so they're 100%
capable of looking the same way your native app would.

~~~
voddan
iOS and Android UX guides have completely different approaches to the logic of
user interaction. AFAIK, Xamarin does not allow to have different layouts
generated from shared code. So, even that components are native, their
placement is alien.

~~~
V-2
> _Xamarin does not allow to have different layouts generated from shared
> code_

That's true, but noone says or recommends that _all_ the code is shared.
Typical Xamarin architecture and good practice assumes sharing the business
(or domain) layer, and coding the views separately. In terms of reusability
it's still superior in comparison to writing both versions natively. Obviously
the level of reuse you can achieve that way very much depends on the nature of
the application.

------
KennyCason
I have became a 100% Kotlin convert. Every single project I work on now is
using Kotlin.

I have also found that if you are using LibGDX Java game framework, it's very
trivial to convert it to Kotlin. I have been doing that pretty extensively and
it has been very pleasant. Feel free to check my GH for some examples. Most
notably, the Bayesian Classifier.

Also be sure to check out the Kotlin slack room. It is filled with a bunch of
great and active people.

But most importantly, just go try it. If you come from Java and are hesitant
to leave given all the nice libraries available in Java, Kotlin is for you.

~~~
sdegutis
On the topic of using the JVM to make games, do you find yourself using the
trick of not allocating any new objects (wither from Java or Kotlin) within
the game loop? I've heard of that trick, and am considering using it because
GC pauses are the main reason I'm considering avoiding the JVM for games.

~~~
optionalparens
Have worked on many games and game engines for several decades. Here's some
quick advice that applies mostly regardless of the JVM.

1\. Allocations of any kind are often the most expensive operation per frame,
or at least some of the ones that are fixable (you can't just not have physics
in some games). As such, avoid allocations per frame.

2\. Notice transition screens, loading screens before levels, brief artistic
animated overlays (things like ROUND 1 - READY!). These just aren't for fun or
to hide just disk IO, they can actually be used as a time to do controlled
allocations. Let's say you're doing a Metroidvania for instance - perfect time
when changing areas to load new stuff.

3\. Use fixed-sized data structures like arrays. Vectors, Lists, any kind of
dynamically resizing data structures are generally your enemy. Sure you can
use them in non-essential parts, but it's an easy thing most of the time.
These help you control the amount of allocations, and moreover ensure that
your game runs predictably, especially when pushed hard. You shouldn't be
letting your game get into insane states that would allow allocating 5 billion
bullet objects even if your vector and a machine with 64 gigs of rams can
handle it. Obviously some exceptions, but there's sound reasoning.

4\. Operate on fixed-sized data structures in sequence. It's harder on the
JVM, but in most platforms you can start trying to use this to help the
runtime optimize for you, or better yet, get things to fit nicely into cache
lines. Things like "events" and "callbacks" may seem helpful, but they are
actually your enemy, even on the JVM. You are better off using a queue or
mailbox approach if you need more performance and less GC surprises.

5\. Pool. But don't just pool and allocate, make sure you are pooling
efficiently. On some platforms, this means tightly packed structures with no
holes. One cheat you can do is actually use an ID system and work with that to
index into an array-based pool by getting via index instead of a search. Using
dicts/maps for this is the wrong approach for so many reasons. There's an
older GDC presentation about this somewhere I can't remember, but it talks
about this in relation to entity systems and uses the term prius a lot. Free
list might be something else on your google for this.

6\. Pack your textures when you can. Do things like use a sprite sheet. It's
not just the GC pauses that are the enemy on the JVM, but also hitting the
file system. This will help reduce it at the cost of potentially more memory
for a single texture.

7\. Don't go wild with classes. Try a data-based approach. This cuts down on
GC and is the basis for some flexible architectures like entity systems. Of
course you may still need classes as containers if you are using Java, but
you'll end up with less ugliness and perhaps less classes and instantiations
of those classes this way.

8\. Check out your JVM flags and tweak things more if you must. Check out
[https://docs.oracle.com/cd/E40972_01/doc.70/e40973/cnf_jvmgc...](https://docs.oracle.com/cd/E40972_01/doc.70/e40973/cnf_jvmgc.htm#autoId0)
for an example. Not the best guide, but my first google hit to just
demonstrate. On a semi-related note, don't do stupid stuff like reflection or
dynamically load in things that are just going to make the JVM angry. Simple
is better than clever here.

9\. Use a good time step for your game loop where you separate your sim time.
It doesn't necessarily fix GC pauses, but it does ensure that if things are
running slow you can respond and interpolate.

10\. Related to the last point, try to do more per frame and don't assume all
work is the classic game loop of render per tick. Naughty Dog did an
interesting presentation on The Last of Us port to PS4 you can read about
where they talk about optimizing the way they process frames. If your game
permits similar approaches, it gives you a chance to squeeze out some
performance this way.

I have many more tips, but this is just off the top of my head. Some of these
might seem like micro-optimizations, but they actually end up shaping your
game's architecture so it is definitely important to think about it early if
you are serious about not putting yourself in a performance corner.

You can certainly develop games on the JVM. I personally don't recommend it
unless it's for pleasure. C or C++ is still the way to go. I am sure you can
have fun with Rust too doing it, but there's just so much ecosystem and people
talent tied up in the former choices that it effectively makes anything else
far behind. That said, you can write a good game in any language, and if you
are just sane about your game it will be fine. Even with GC pauses, for some
type games, ex: strategy that isn't real-time, your users would barely notice
and it wouldn't effect gameplay. In short, be pragmatic no matter the
language, stick to some of the above, and enjoy yourself and just get it
built. Language is the least of your worries in the end, but still worth
paying attention to on some level.

~~~
sdegutis
Wow. Thanks for all this.

I've casually read a lot of people's advice on game dev, and while some of it
is reflected in what you said, your comment kind of ties it all together. And
it confirms something I've been thinking for a few months (possibly years)...

Everything needed to write a simple game is right there in C, using structs,
pointers, and functions! Anything beyond that is over-engineering. And the
conveniences that languages like Java bring are just simply not worth it in
this context.

Because as far as I can tell, writing a game is basically writing a tight loop
that enumerates arrays and calls functions on them. There's basically no need
for any OOP beyond the simplistic method of using structs, pointers, and
functions.

And considering I've just had 4 years of practice using data and functions
(full time job writing Clojure), I think I'm a lot more comfortable with this
pseudo-OOP approach than I would be trying to jimmy-rig Java to basically be
C.

So that's what I'll probably do. Write a SNES-style metroidvania in C using
SDL2. (Although I'm open to alternative suggestions, but from what I've read,
SDL2 is probably best for this job.)

Thanks for your advice and for bearing with me as I think this through in this
comment :)

~~~
optionalparens
What you are saying is mostly right, perhaps somewhat of an
oversimplification. Interestingly, these days I work with quite a bit of
Clojure.

Most of what I've been describing came about because people were in OOP hell,
and decided to move towards composition vs. inheritance. As multi-core
machines, GPUs, and more sophisticated games arose as well, there was more of
a need to start thinking more in terms of what the CPU wants and pipelining
things for the CPU, GPU, and such (think PS3 for instance). To some degree,
this thinking was always there and circling back to 80s game programming, but
a lot of people got off-track. For example, memory allocation was always a
thing to the point where no sane person every used anything in C++ from std
because of allocations and bad memory layouts. Structure packing has always
been a thing of course too. Another was thinking about v-tables and how they
just get in the way, especially when working on more limited platforms like
the NES, 286, etc. in those days.

Games are mostly about enumerating a lot of stuff, very fast, per some measure
of time, and then repeating. If this sounds a bit like a map or a reduce in
functional terms, it should because it is. You have loops inside loops, and
you try to operate on similar blocks of data, rather than jumping around all
over the code or iterating mixed collections (or hybrids using
co/contravariance). It turns out computers, especially x86, really like it
when you enumerate things in a line. There's a fun presentation somewhere
where Stroustrup himself shows how an array can be faster in many situations
than a linked list when the linked list fits the exact description of the
correct data structure.

Anyway, you can rig a lot of this into Java as you say, but fighting the GC is
still considerably hard. Clojure itself is even worse because it generates
garbage like nuts and you also end up doing things like transient! or using
volatile! to work around other speed issues. I'm not sure about Kotlin would
be, but as a JVM language dealing with JVMisms, I suspect largely the same as
Java. Other languages that are more predictable or not GC'd fair much better
for games, they are just not used as much because of the people in the
industry, technical debt, tool chains, know-how, risk, etc.

Where I'd disagree with what you said is that those constructs are all you
need. For certain parts of your game you still need quite sophisticated stuff.
Threading primitives and complex pieces of code help that are a pain to write
with just what you described. But these things are generally higher level. For
example, scripting engines are a good thing to have and often not written in
the same language (ex: lua). Editors are another example. They aren't part of
your game directly necessarily, but these days they increasingly are on some
level, at least some form of them. Either way, you benefit from building
toolchains in a variety of languages to help a game. It's not just a single
code-base and ultimately you only have so much time, so you take shortcuts
like throwing in Lua to make life easier.

Regarding SDL2, it's probably great for what you are doing. It's more low-
level, but if you want to build things from the ground up, it's a fine and
well-tested choice. There are other alternatives, but mostly in the form of
full game engines. Certainly you could do this with something like Unity and
it'd be good enough. If you're going 2D, the one piece of advice I'd give you
is I'd say probably these days you can get just as much done by making things
3D and fixing the camera most of the time, or using a hybrid. 2D is more
difficult than people think and often sucks in certain engines (ex: Unity :)
). Anyway, it's just a matter of some head banging and time. If you go SDL,
you'll learn a lot, just remember, build games, not game engines.

~~~
sdegutis
Thanks for the advice. Best of luck, especially if you're dealing with burnout
which it sounds like you might be from your other comments. I'll definitely be
taking your advice and trying something in SDL. Maybe a simple SNES Mario-like
clone for starters [1]. Man, it's been 10 years since I last tried that, and
back then it was in Freebasic! What a wild ride. Okay I think I'm too tired to
adequately form a comment properly. Stayed up too late for this election and
the speed. Man, what a wild ride! Well anyway good night and thanks again.

[1] : [https://github.com/sdegutis/mario-
sdl2](https://github.com/sdegutis/mario-sdl2)

------
maaaats
Saw a great Kotlin talk by Hadi Hariri from JetBrains at Javazone this year.
[1] What I liked about it was that instead of the usual "this is how you do X
in language Y" it focused on the immediate value it could bring to
professional developers used to Java. Made me really want to try it out and
start using it at my job.

[1]: [https://2016.javazone.no/program/kotlin-ready-for-
production](https://2016.javazone.no/program/kotlin-ready-for-production)

------
meddlepal
Kotlin is great and we're using at in the backend at Datawire.io. Also we're
hiring! Check us out if you're a backend JVM/Kotlin developer and are in the
Boston, MA area!

[https://www.datawire.io/careers/](https://www.datawire.io/careers/)

~~~
sdegutis
Do you use any specific Kotlin (or other JVM lang) web framework for your
backend, or did you roll your own?

~~~
meddlepal
Vert.x 3 currently. First class Kotlin support is dropping before the end of
the year according to the Google Group for Vert.x but for right now the
excellent Java/Kotlin interop hasn't prevented us from building.

~~~
claudiug
vertx looks very slow compare to other java frameworks. And the fact that you
can use them and you will the same speed asta java...

[https://www.techempower.com/benchmarks/#section=data-r12&hw=...](https://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=query&l=27wqyn)

~~~
meddlepal
Hard to say what's going on there. Vert.x itself is quite speedy. The DB
access module they use ([http://vertx.io/docs/vertx-mysql-postgresql-
client/java/](http://vertx.io/docs/vertx-mysql-postgresql-client/java/)) is
still in technical preview so there may be legitimate issue with the module or
something wrong being done (I only glanced quickly and didn't see anything
immediately obvious). Vert.x really isn't much more than a pleasant facade
over Netty so it's hard to imagine what's actually wrong.

It appears there may be an issue with the benchmark?
[https://github.com/TechEmpower/FrameworkBenchmarks/issues/21...](https://github.com/TechEmpower/FrameworkBenchmarks/issues/2117)

Personally, I don't really care about benchmarks. Getting stuff done is more
important at this stage. Eventually this may become more important but I'm not
going to worry about it until it becomes and issue for us specifically.

------
xiaoma
I'm torn on this. On one hand, Kotlin is great. It's not Scala but it gives
you a whole lot while maintaining the ability to very easily swap in for Java.

On the other hand, it's controlled by Jetbrains—the company that now offers a
"yearly license" of many of its compilers at the same price point it once sold
them for, after which time they forcibly downgrade the software their users
have paid for. It's not illegal and some even agree with the practice on an
ethical level, but it's clear that Jetbrains is all about hoarding as much
consumer surplus for themselves as they can.

If only Kotlin were truly an open project and well supported outside of the
Jetbrains marketplace, e.g. by VS Code, I'd be cheering it on.

-former webstorm/rubymine customer

~~~
mike_hearn
I don't really get that. Kotlin is open source. You can write and compile
Kotlin code without paying JetBrains a penny, it's not hard. There's even an
Eclipse plugin - written by JetBrains.

I'm not sure what more is required to make it truly open.

~~~
xiaoma
What non-Jetbrains IDE supports Kotlin well? What % of its contributions come
from outside the Jetbrains ecosystem?

Once Jetbrains no longer controls Kotlin's future and most Kotlin users are
_not_ Jetbrains customers, then I'd consider it truly open.

~~~
trevor-e
I think you're confusing language openness with freedom of choice for
consumption.

~~~
xiaoma
I think you're confusing deduction with speculation. I'm fully aware of the
difference between language openness and "freedom of choice for consumption".
I just don't agree with the wisdom in tying my workflow to a company like
Jetbrains.

~~~
claudiug
why? What is wrong with jetbrains, and also what is the connection between
then and a free software(kotlin) also, vs code is by microsoft. Any time
microsoft can say that plugins needs to be review by them. also vscode is
ahead is a very hard option?

Are you upset for the election in USA?

------
nostrademons
Saw this pop up in my IDE this morning, excited to upgrade. The auto-for-loop-
refactoring is interesting. I've found I _never_ use for-loops in Kotlin -
between the abundance of iterator methods and concise trailing-closure syntax,
it always ends up being more concisely expressed as collection.forEach {
...body... }. Seems like the language may be going that way too; I wonder if
we'll eventually see the for-loop start to fall out of use in modern
languages.

~~~
sdegutis
But does .forEach compile to an efficient for-loop in Kotlin?

~~~
nostrademons
Not completely sure about the internals of the Kotlin compiler, but I believe
it does. You can do a non-local return (i.e. return from the top-level
function, not the lambda passed to .forEach) from inside them. This would be
very difficult if the body were not inlined, because you'd need to store a
lexical stack of return addresses and ensure that the closure never escapes
the HOF. (I think it actually does perform this escape analysis; I've gotten
error messages before when trying to pass a lambda with a non-local return
into a functional argument that _wasn 't_ one of the basic collection
iterators.)

------
gldalmaso
Anyone using Kotlin to compile to javscript in a large app care to share some
experiences?

~~~
avodonosov
JS support was an experimental and TODO for a long time. Is it ready now?

~~~
mr_tristan
I don't believe JavaScript will be "un-experimental" until Kotlin 1.1 is out.

------
edem
I can also vouch for Kotlin. I am actually not an Android dev and I started
using Kotlin for a backend project (uses Spring Boot) and I was pleasantly
surprised how easy my switch to Kotlin was.

------
on_and_off
It also finally solves the Android Studio bug that would show all the
Databinding code as erroneous in the IDE.

The tooling is still a bit rough around the edge compared to the base Android
one, mostly because the android tools team really does an awesome job.

It is still useable though, and the language is so much better than java that
it is a breeze to use.

The only downside is that you have to interface it with java code, which
brings a couple of issues.

------
sandGorgon
Hi guys, what is the Kong term story here ? We have been yearning to use
kotlin for our Android app and backend...but have been worried about Oracle
doing something that breaks compatibility, or jetbrains going out of business
as a company.

I see a few people have adopted it - what do you guys see as the future of the
language? Do you think java8+Lombok is moving in a direction that makes kotlin
useless ?

------
skybrian
Is there a lambda-to-loop refactoring? Every refactoring should have its
inverse. For loops are often better than map() calls (not always).

------
carsongross
Congrats to the entire Jetbrains team.

Great language, greater IDE.

------
davidsawyer
I'm curious to hear from anyone with a Groovy background that has worked with
Kotlin as well.

~~~
vorg
Apache Groovy's original creator, James Strachan, worked on Kotlin for a while
after, er, leaving the project, as also did Alex Tkachman, creator of Groovy++
which was cloned as the static typing facility in Groovy 2.x.

------
dxxvi
Is there anybody switching from Scala to Kotlin?

~~~
runT1ME
I can't imagine anyone who has used Scala for long would switch to Kotlin.
Kotlin is 'Java++'. Scala is a fully featured functional language.

Kotlin is missing all of the most powerful Scala features. No type classes,
monadic comprehension, higher kinded types, adhoc polymoprhism. :(

~~~
V-2
Well, it's kind of the point. Kotlin is supposed to be light weight and easy.
Besides, using Scala for Android, while possible, is cumbersome. Kotlin wins
this one hands down.

~~~
lmm
Scala for Android is fine. The only thing that makes it harder than Kotlin is
JetBrains disingenuously shipping their Kotlin plugin but not their (more
popular) Scala plugin by default, which they could fix tomorrow if they wanted
to.

~~~
V-2
Last I checked, Kotlin plugin isn't installed (in Android Studio) by default.
Are you referring to IntelliJ Idea?

I tried to use Scala for Android in the past and I gave up after attempting to
set it up for a few hours. Admittedly it was a while back, perhaps things have
improved.

Your claim that Scala on Android works fine got me interested again, so I
googled around, found that blog post from May this year (that's more recent
than my own experiments), and apparently there are still hurdles:
[http://blog.scalac.io/2016/05/19/reflections-on-starting-
and...](http://blog.scalac.io/2016/05/19/reflections-on-starting-android-
project-with-scala.html)

With this type of issues the thing that I'm wary about is not getting a "hello
world" app to compile once, but that I can get a project up and running, then
need to add something else to the equation (say, a DI, or some code
processor), and things fall apart again in an X-Files fashion.

I've heard that Scala has long build times, too, but maybe it's a thing of the
past as well - no first-hand experience here as I never got to that stage.

~~~
simono
The article isn't very good, even the link to the 'official' page is outdated.

Just use sbt-android and skip all the other nonsense.

Compilation is impressively fast, as the plugin uses the information from
incremental compilation to skip ProGuarding completely for things that haven't
changed.

------
chenshuiluke
For those who use Kotlin to target Javascript, how does it perform against
something like Elm?

