Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (741)
Games in Android Showcase (225)
games submitted by our members
Games in WIP (823)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2 3 ... 6
  ignore  |  Print  
  Move to Kotlin?  (Read 5269 times)
0 Members and 2 Guests are viewing this topic.
Offline Zeldar
« Posted 2017-11-06 09:19:26 »

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?
Online princec

« JGO Spiffy Duke »


Medals: 976
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2017-11-06 09:48:24 »

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 Smiley

Offline 65K
« Reply #2 - Posted 2017-11-06 09:49:09 »

my advice: first do finish a small project with java

Lethal Running - a RPG about a deadly game show held in a futuristic dysoptian society.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline elect

JGO Knight


Medals: 48



« Reply #3 - Posted 2017-11-06 09:52:45 »

Life is too short to code in java, use kotlin
Offline KaiHH

JGO Kernel


Medals: 482



« Reply #4 - Posted 2017-11-06 10:02:29 »

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.
Offline SteveSmith
« Reply #5 - Posted 2017-11-06 13:20:39 »

my advice: first do finish a small project with java

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.

Offline Spasi
« Reply #6 - Posted 2017-11-06 14:21:08 »

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.
Online princec

« JGO Spiffy Duke »


Medals: 976
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #7 - Posted 2017-11-06 14:49:46 »

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

Cas Smiley

Offline h.pernpeintner

JGO Knight


Medals: 65



« Reply #8 - Posted 2017-11-06 14:59:50 »

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.
Offline nsigma
« Reply #9 - Posted 2017-11-06 19:14:34 »

Java ... doesn't change at rates other languages change.

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!  Smiley

Praxis LIVE - hybrid visual IDE for (live) creative coding
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline philfrei
« Reply #10 - Posted 2017-11-07 03:42:38 »

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.

music and music apps: http://adonax.com
Offline h.pernpeintner

JGO Knight


Medals: 65



« Reply #11 - Posted 2017-11-07 10:01:38 »

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!  Smiley
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.

Quote from: philfrei
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 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
https://discuss.kotlinlang.org/t/run-time-null-checks-and-performance/2086/12
and especially:
https://discuss.kotlinlang.org/t/run-time-null-checks-and-performance/2086/12

I can only say, that is more than fast enough Smiley
Online princec

« JGO Spiffy Duke »


Medals: 976
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #12 - Posted 2017-11-07 10:14:30 »

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 Smiley

Offline KaiHH

JGO Kernel


Medals: 482



« Reply #13 - Posted 2017-11-07 10:17:41 »

Quote
like it wasn't completely thought out from start to finish, like Java always felt.
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
Online princec

« JGO Spiffy Duke »


Medals: 976
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #14 - Posted 2017-11-07 10:20:00 »

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 Smiley

Offline Spasi
« Reply #15 - Posted 2017-11-07 10:21:37 »

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?).

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.

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?

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.

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?

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.
Offline nsigma
« Reply #16 - Posted 2017-11-07 10:47:33 »

Unless you are a Netbeans user ...

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

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.

Then of course there's the fun of doing the exact oppositeWink

Praxis LIVE - hybrid visual IDE for (live) creative coding
Online princec

« JGO Spiffy Duke »


Medals: 976
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #17 - Posted 2017-11-07 10:47:58 »

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 Smiley

Offline Spasi
« Reply #18 - Posted 2017-11-07 11:04:58 »

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.

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).

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

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):

1  
2  
3  
4  
5  
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
Online princec

« JGO Spiffy Duke »


Medals: 976
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #19 - Posted 2017-11-07 11:14:41 »

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 Smiley 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 Smiley

Online princec

« JGO Spiffy Duke »


Medals: 976
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #20 - Posted 2017-11-07 11:17:22 »

btw I wonder if the "adjective before the noun" style is less pleasant to non-English natives than not because that's how we do our natural language?

Eg. we have green apples, not pommes vertes, in the same way that we have Colored fruits not fruits: Colored.

Cas Smiley

Offline elect

JGO Knight


Medals: 48



« Reply #21 - Posted 2017-11-07 11:28:55 »

I guess type on the right was needed also because of inferred types, which I deep use and love

1  
val i = 0
Offline Riven
Administrator

« JGO Overlord »


Medals: 1324
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #22 - Posted 2017-11-07 11:32:05 »

Java ... doesn't change at rates other languages change.

With the new 6-monthly releases I think we're about to see Java evolving much more rapidly
5 (or 10?) years ago they promised us annual releases - that didn't quite happen Smiley

I certainly hope we get 6-month releases, but odds are we should be happy if we get 24-month schedules.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Online princec

« JGO Spiffy Duke »


Medals: 976
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #23 - Posted 2017-11-07 11:32:21 »

I'm a massive hater of val types.

Cas Smiley

Offline nsigma
« Reply #24 - Posted 2017-11-07 11:36:03 »

I guess type on the right was needed also because of inferred types, which I deep use and love

Considering Java is getting inferred types in March, that doesn't seem a correct assertion. Sorry @princec, you'll just have to ignore them!  Wink

I actually think we will get 6-monthly releases this time around, because it's linked to changing the development model.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Online princec

« JGO Spiffy Duke »


Medals: 976
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #25 - Posted 2017-11-07 11:45:37 »

Yes, at least I can ignore them in my own code. Not looking forward to having to decipher everyone else's code though - which is exactly what I hate about them. It removes yet another bit of self-documentation from code and means I have to figure something out painstakingly for myself. And then assume the originator got their thinking right in the first place. Grr. Hopefully not too many serious library maintainers will use them.

Cas Smiley

Offline h.pernpeintner

JGO Knight


Medals: 65



« Reply #26 - Posted 2017-11-07 11:52:00 »

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

Ah, thats very nice Smiley So you can explain, why Netbeans isn't able (is it?) to handle multi language projects? I tried to do a project in Kotlin and Java and afterwards in Groovy and Java and neither worked. It told me there are symbols that can't be found. Pretty much the only issue I had in an IDE with Kotlin. Sadly, I can't find any info on this and the corresponding issue is ignored heavily.
Offline KaiHH

JGO Kernel


Medals: 482



« Reply #27 - Posted 2017-11-07 12:03:58 »

I'm also not believing this 6-month release cycle. It'll likely be either:
1. "Yes, we know we promised to do a 6-month release but that certain feature is taking longer than expected. And eventually they release after two years of development time."; OR
2. "Yes, we actually DO release after 6 months but none of the things we promised would make it into the release actually do, and we just have some bug fixes and small JDK library changes"
It would be the first time in the history of software development, that such a big project actually keeps their release cycle.
Offline nsigma
« Reply #28 - Posted 2017-11-07 12:12:32 »

2. "Yes, we actually DO release after 6 months but none of the things we promised would make it into the release actually do, and we just have some bug fixes and small JDK library changes"
It would be the first time in the history of software development, that such a big project actually keeps their release cycle.

Yes, 2.  This is what I meant by the development model also changing.  We will just see features dropping back when not ready.  Remember there's also an LTS aspect to this.  And I can think of a few big projects that do keep their release cycles!

Ah, thats very nice Smiley So you can explain, why Netbeans isn't able (is it?) to handle multi language projects? I tried to do a project in Kotlin and Java and afterwards in Groovy and Java and neither worked. It told me there are symbols that can't be found. Pretty much the only issue I had in an IDE with Kotlin. Sadly, I can't find any info on this and the corresponding issue is ignored heavily.

I believe JetBrains themselves are responsible for the Kotlin support, so perhaps ask there?  In terms of NetBeans issues, better to file in the Apache NetBeans JIRA.  Things a bit in flux at the moment around the old NetBeans site.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Online princec

« JGO Spiffy Duke »


Medals: 976
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #29 - Posted 2017-11-07 12:33:24 »

The 6 month release cycle commitment is a realistic solution to the disastrous release cycles of Java 7 and Java 9, where hundreds of useful smaller features were held back by a couple of massive epic features. They can easily hit a 6 month cadence and just ensure that no feature is ever designed to take longer than 6 months to implement. (If it does - it needs to be broken down into releasable steps)

Cas Smiley

Pages: [1] 2 3 ... 6
  ignore  |  Print  
 
 

 
xxMrPHDxx (21 views)
2017-11-21 16:21:00

xxMrPHDxx (14 views)
2017-11-21 16:14:31

xxMrPHDxx (16 views)
2017-11-21 16:10:57

Ecumene (114 views)
2017-09-30 02:57:34

theagentd (150 views)
2017-09-26 18:23:31

cybrmynd (260 views)
2017-08-02 12:28:51

cybrmynd (250 views)
2017-08-02 12:19:43

cybrmynd (247 views)
2017-08-02 12:18:09

Sralse (260 views)
2017-07-25 17:13:48

Archive (881 views)
2017-04-27 17:45:51
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!