Move to Kotlin?

General Discussions
#1

I have been doing quite a few (unfinished)games using Libgdx+Java for the past few years. Now I’m about to start a new pretty big project but I’m not sure what to do !

Do I use the old beloved Libgdx+Java combo or it’s time for Libgdx+Kotlin ?

I’m pretty sure I will be at ease and productive with Java, but this will be a long project and I fear that at some point in the project’s life I’ll HAVE to rewrite everything in Kotlin because it MAY be just that better of a language.

Is it the perfect time for a change? What would you advise me to do ? :persecutioncomplex:

And also, will a project using Kotlin run with the same performances as a project using Java?

#2

I looked at Kotlin and then I looked at Ceylon and tbh, Ceylon appears to be a nicer and more natural move from Java.

Cas :slight_smile:

#3

my advice: first do finish a small project with java

#4

Life is too short to code in java, use kotlin

#5

Obviously, there is no such thing as a “better language” without any context of your actual problem/requirements. All we know is that it is going to be a “long project.”
For what I know about Kotlin, is that it’s a good choice for developing a typesafe internal DSL, as was done by @Spasi for the LWJGL 3 templating/generator system.
But if your project is not going to involve such heavy meta-programming/templating stuff, then you’ll certainly be fine with either language.
Do remember that Kotlin is also not limited to the JVM. It also compiles to JavaScript, and JetBrains is making good progress with their “Kotlin native” project, too. That’s probably another thing to base your language decision on.
But if your strongest known requirement is “I just want to learn Kotlin and play with it, because I feel like it” then you should just use it.

#6

Programming should be fun. Presumably Zeldar didn’t finish them because they stopped being fun and turned into a chore.

My advice: do whatever you want to do and aim as high as possible, while taking into account KaiHH’s excellent reply.

#7

For anyone looking into Java++ languages:

Multiplatform native development in Kotlin

4 applications (server, web, android and iOS), 1 language, 1 project with code sharing.

Also considering other recent advances, like first-class support in Android Studio and Gradle, I’m not sure how Ceylon/Scala could compete with the ecosystem that’s been building around Kotlin.

#8

The iOS path is pretty compelling if you’re thinking about mobile dev.

Cas :slight_smile:

#9

7 years Java guy here.

From my point of view, Kotlin is a superior language in nearly every case one could be interested. I won’t advocate the benefits and advantages of Kotlin here, because I feel many people feel annoyed by the Kotlin movement. Instead, I have some things to consider for you: Java is a very very solid language, that doesn’t change at rates other languages change. Most people see it as a disadvantage, but the good side of things is, that you have a large job market and that most people using Java simply aim to be productive and efficient, and want to get shit done. That means if you are not yet an absolute Java expert, there’s plenty of stuff you can learn to do with the language. Architecture-wise you can do pretty much the same things with Java. My advice would be to get better with Java, if you have the feeling that you can’t use at a very professional level. Knowing Java really good will show you why you will want to have Kotlin after you mastered Java. Since Java is a big part of the foundation of Kotlin, it’s never a mistake to know Java really well.

For people knowing Java in and out, I recommend to switch to Kotlin immediately. I have a personal game engine project that is roughly 40k lines of Java code and I successively convert parts of it to Kotlin know part by part - now i is a mixed Kotlin/Java project and it’s working like a charm. So no need to move to 100% Kotlin right now, you can switch later also.

#10

With the new 6-monthly releases I think we’re about to see Java evolving much more rapidly, partly as a result of things like Kotlin (eg. type inference and pattern matching next March?). I find Kotlin really interesting, but not compelling enough to switch yet - these feel like interesting times, and like Java might be at a sink or swim moment! :slight_smile:

#11

I read that Kotlin is fast, but the article was saying fast as in almost as fast as Java, but much faster than Python, JavaScript, others of that ilk. What is the truth on Kotlin’s speed?

I would be wary about any woohoo on multiplatform implementation. Is it proven or in development? There were several woohoo multiplatform attempts with Java that ended up not being as good as initially hoped. Maybe I’m wrong about all of this, since I didn’t get that far with my games to follow through on that aspect.

Put it this way, is the iOS for Kotlin similar to the iOS provided by RoboVM for Java?

Mostly, I was impressed with what I read about Kotlin, being fast and well designed. But I’m waiting to hear more before I try dabbling with it.

#12

Even though Java might evolve more rapidly than before…Java defines the enterprise land, where new Java versions are adopted veeeery slowly. The language’s foundations are much more static, no matter how fast the language will change.

I respect your opinion, but have you honestly try to use Kotlin? xD And I’m not talking about recoding a single tutorial, but using it several hours to solve real world problems. As I said before, there’s not really the need to “switch”. Unless you are a Netbeans user, you can perfectly fine use both languages in the same project. If you are an experienced Java user, I really can’t comprehend why Kotlin doesn’t offer enough features to “switch”. As it costs basically nothing to switch.

I skip the “you can’t say something is fast or slow, if you don’t look at a specific scenario or don’t do thousands of microbenchmarks”. I know what kind of advise you want to have (because I wanted the same).

The truth is: Kotlin does many things you would do with java nonetheless by hand. I took some measurements with JMH and some of Kotlins constructs are compiled to faster code than the Java equivalent (For example a simple delegation for composition over inheritance, but I’m not a performance expert, so take this with a grain of salt). Besides this, there are not toooo many constructs that Kotlin has that do anything fancy. Operators are compiled to regular methods, extension methods are static methods, which is as fast as it can be…delegation, properties is the same as you would do with Java. Additionally, there are some cases where Kotlin can be faster, for example the lambda implementation seems to be faster than Java’s. Or you can inline methods completely and eliminate the costs of a method call. However, there are some pitfalls in Kotlin, just like with any other platofrm too.
There are some posts
http://oneeyedmen.com/cost-of-kotlin-preliminary-results-part1-baselines.html


and especially:

I can only say, that is more than fast enough :slight_smile:

#13

Kotlin broke too much in my head to work for me and always had this strange feeling like it wasn’t completely thought out from start to finish, like Java always felt. Sort of like D vs C++. Ceylon is a far cleaner direction IMO. But I’m an old fool, take no notice of me.

Cas :slight_smile:

#14

[quote]like it wasn’t completely thought out from start to finish, like Java always felt.
[/quote]
Do you mean Java felt like it was also not completely thought out, or do you mean Java felt like thought out?
If the latter: Have you ever used Generics in Java? :wink:

#15

Extensively… but I know enough about Java’s goals, limitations, and promises to understand why generics were made the way they were. They could have been made better - but at a cost that would at the time have been completely unacceptable.

If I were to design Java again from scratch… it would look remarkably like Ceylon.

Cas :slight_smile:

#16

[quote=“nsigma,post:10,topic:59074”]
Definitely. We’ll be seeing new language features and new APIs faster from now on. Also in experimental form, which would not be possible if we hadn’t already paid the price for Java 9 (the JPMS delays). On the other hand, any bytecode or API features that get added to Java, automatically benefit all languages that target the JVM. Java the language will always lag behind because its creators must be extremely careful and conservative. This is a good thing. We want a stable base/compilation target, experimental languages on top of that can come and go. If there’s a great new idea that works, the base can adopt it and everyone benefits (see Kotlin Coroutines and Project Loom).

Another example is “typealias” vs “newtype”. The former is supported already. The latter could have been implemented at the compiler level, but Kotlin’s creators have decided to wait for the JVM to support value types. Adopting new languages doesn’t mean Java is going away. It should always be there and it should be healthy.

[quote=“philfrei,post:11,topic:59074”]
Kotlin/JVM compiles to Java bytecode. It’s as fast as Java bytecode can be on a given JVM. There’s no bytecode that javac can produce, that kotlinc cannot reproduce exactly. Kotlin simply has different constructs at the language level that makes “producing bytecode” easier/cleaner/faster.

Kotlin/JS compiles to Javascript. Same as above.

Kotlin/Native uses LLVM for ahead-of-time compilation to platform-specific executables. This is still a work in progress and early to judge performance-wise. It features both explicit memory management and (currently) a reference-counting GC.

[quote=“philfrei,post:11,topic:59074”]
Kotlin/Native is not a write-once-run-anywhere solution. You’ll be making direct calls to platform-specific libraries and APIs. Each platform will be a separate module with different code. What Kotlin lets you do is extract generic code to “common” modules and reuse it in all platform modules.

#17

I’m an Apache NetBeans committer. ;D And my main project is NetBeans Platform based, so yes not so easy currently.

Then of course there’s the fun of doing the exact opposite. :wink:

#18

Indeed, the idea of writing actual applications that somehow work across smallscreen touch on Android or iOS, largescreen touch on Android or iOS, Windows desktop paradigms, Mac desktop paradigms, and god only knows what awful horror the Linux crowd have come up with is just nuts. Cross-platform libraries on the other hand…

Cas :slight_smile:

#19

[quote=“princec,post:15,topic:59074”]
FWIW, Kotlin was designed under significant constraints too and the initial plan was different. There aren’t any features that cannot be expressed in Java bytecode and having to deal with Javascript was an issue from the get go. A different runtime is required to fix core issues and try radical new ideas (see Go, Pony, Rust).

[quote=“princec,post:15,topic:59074”]
It probably wouldn’t. When moving to Kotlin from Java, there are two kinds of “weirdness” that you have to get used to: 1) types “on the right” and 2) a few conventions (single-expression functions, last-parameter-lambda, etc). The first has language design benefits, that’s why most functional languages look like that. It’s also more natural to read (source):


fun isFree(forWhom: Person): Boolean
// Kotlin: function isFree with parameter forWhom of type Person which returns Boolean.

shared Boolean isFree(Person forWhom)
// Ceylon: shared (function) which returns Boolean and is called isFree with parameter of type Person named forWhom
#20

That depends on what you’re used to and I’m used to C-lexical - that’s why it’s the direction I’d go, not because it’s better :slight_smile: Things that make my brain work harder mean I tend to skip them. One of the main reasons Java was C-lexical in the first place was so it didn’t put off the hordes of C and C++ programmers they wanted to lure, and the same goes for luring me away from Java.

Also a bit like why C# makes my eyes bleed. It’s like “the uncanny valley”.

Cas :slight_smile: