Live data from Hacker News

Kotlin 1.0.5 is here

blog.jetbrains.com

71–80 of 111 posts

Re: Kotlin 1.0.5 is here

#71
post #18

Is there anybody switching from Scala to Kotlin?

After having so much fun with Kotlin, I tried switching to Scala and quickly switched back. Scala seems too complicated, with a steep learning curve. Implicits all over the place made it hard to read code and understand what was going on. I do like many of the more powerful features that Scala has, but Kotlin strikes a right balance of simplicity and power in my opinion.

i think redhat's ceylon strikes my personal sweet spot between java and scala, but kotlin is a great language too.

Re: Kotlin 1.0.5 is here

#72
post #20
post #18

Is there anybody switching from Scala to Kotlin?

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. :(

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.

Re: Kotlin 1.0.5 is here

#73

Earlier quoted context omitted.

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

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.

Hi! I am will join JetBrains in a week to work on new projects with kotlin and vert.x, but have only experience in Akka. Can you point any major issues that you have with vert.x + kotlin?

Re: Kotlin 1.0.5 is here

#74
post #72
post #20

Earlier quoted context omitted.

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. :(

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.

Which issues did you experience?

Re: Kotlin 1.0.5 is here

#75

Earlier quoted context omitted.

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 an…

Thanks for this awesome comment. Agree with everything you said. This could probably make a nice blog post. :)

Yep gonna have to bookmark that comment for some bedtime reading tonight :D

Re: Kotlin 1.0.5 is here

#76

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…

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

Re: Kotlin 1.0.5 is here

#77
post #9

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 wi…

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.

It's not just JVM - even if you are a Unity 3d user you need to work around GC too. There are programming guidelines to ensure less frequent GC pauses. IMO the trade off of having a GC worth is for small developers.

Re: Kotlin 1.0.5 is here

#78

Earlier quoted context omitted.

Thanks for this awesome comment. Agree with everything you said. This could probably make a nice blog post. :)

Yep gonna have to bookmark that comment for some bedtime reading tonight :D

Thanks, if you do nothing else, please (links to follow):

1. Read/watch the naughty dog presentation on Last of Us port where they talk about their time step. I have to say if there's one company who puts out stuff like videos and articles/books you should read, it is Naughty Dog. They know what they are doing optimization-wise, I just happen to find most of their games boring and lifeless from a design point of view, but I can still respect them greatly.

2. Read the GDC presentation about entity systems and the "roster" approach linked below.

3. Read probably everything on the Bitsquid site. Some of it is dated or even not the best, but I pointed some people here before and it really opened up their minds to what I was talking about when they were looking at my code. Changed their view from "black arts" to "wow, that really is simple and makes sense."

4. Read up on Entity Systems. But do not read things written by bloggers, authors of "frameworks," and various Java stuff out there (ex: Artemis). I hate to be so negative, but what I usually found out there is mostly garbage, wrong, and the authors disappear when challenged or asked about the hard, non-obvious parts. If you want good info, read code that's out there and figure out what seems good/bad, and listen to some of the people in the industry like at GDC talking about it. I tried to find one more recent talks, but so far only came across the Amazon one which seems pretty weak (though still interesting) and basic with regard to low-level detail.

Games knowledge is a tough thing because everyone is professor know-it-all and usually just hobbyists and throw away mobile game devs. Most people working on games who are competent are too busy or too sick of it to write about it. I hate to sound like one of those people. And that's why I don't blog about it or normally comment much. The only reason I'm mentioning it now is to pass time while watching the election. My games career was making me go insane and it was either family or video game development, so now I have more time in life to rant here. So, yeah.

http://www.gdcvault.com/play/1022186/Parallelizing-the-Naugh...

http://www.slideshare.net/TerranceCohen/terrance-cohen-dynam...

http://bitsquid.blogspot.com/2011/09/managing-decoupling-par...

Re: Kotlin 1.0.5 is here

#79
post #28

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…

> after which time they forcibly downgrade the software their users have paid for.

What happened? Could you please elaborate?

Re: Kotlin 1.0.5 is here

#80
post #9

Earlier quoted context omitted.

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.

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 an…

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

Post reply on HN