- 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.
Yeah, I only included the link as a proof that we're actually using Kotlin in production :)
1. Kotlin issues:
- Libraries that use reflection (such as Gson) can break some assumptions that Kotlin makes (for example, a read-only field may actually change). There's maybe 2 or 3 little things like that that may catch you by surprise, but once you figure them out it's easy to work around them.
- Stack traces in lambdas are obscure sometimes. Sometimes you won't get the line number.
- Proguard integration has proven challenging.
2. We started from Kotlin.
3. Learning Clojure and Haskell has made me yearn for more functional languages and better type systems. Kotlin has that, in a neat syntax that's very beginners friendly.
I'm firmly convinced that a good programming language needs:
- Strong library ecosystem
- Static type system + type inference. (I won't get into the static/dynamic argument here. Suffice to say that there's a whole class of bugs that you can avoid with static typing, and type inference makes the "but I hate these types cluttering my code" argument irrelevant)
- Killer IDE support (essential for productivity. If you're writing a large application without using an IDE that gives you code inspection and navigation, you're wasting your time)
Kotlin has these 3 things.
4. Top improvement: can't wait for Kotlin 1.1 to be released, and start using coroutines. Other than that, I'm happy with it.
At the moment I use vals, but it still requires me to mark injected dependencies as nullable (and coerce them with !! on use), which feels like I'm fighting the type system.
It would be really nice if there was some sort of "special" null that was of the non-nullable type, but could only be used when initializing variables.
Even though I'll happily claim to being all aboard the Elixir train, I've looked at Kotlin due to so many of my Java friends talking about it. I really like everything I've seen from it.
If/when I finally need to get around to learning to make an Android app it's definitely the first place I'll look.
-Kotlin outputs bytecode, so from the outside, it is just the same as any android app written in java. The output is a standard android app with one more library (the standard kotlin lib with all its base methods)
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.
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.
> 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.
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.
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.
Definitely. The use of object pools for performance is common in game development regardless of language.
It's something that I tend to add in as needed or when I have decided that a game I'm working on warrants this level of engineering. (i.e. I wouldn't care about it as much if I'm just programming pong or Tetris.)
A bit of a late response as I just noticed your comment "I'm considering avoiding the JVM for games."
I have found myself in this boat many times. I have coded games in Purebasic, TI-83/89 Basic, Z80, C/C++, Java, Kotlin, Javascript, Haskell, Swift, etc. If you are an indie/hobby developer, don't worry about the language too much. Just do it in what's comfortable and enjoy the process. That alone will increase the odds of you completing the game by 50% (random number).
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... 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.
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 :)
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.
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.
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.
Thanks for all these links. Will definitely check them out.
Per your game dev career, sorry to hear that it's so stressful. I've heard from several reliable sources that the game dev industry extremely overworks and underpays people, and that it has a high turnover rate.
As a husband and father of 5 kids, I can't imagine making games in a job like that. Part of the reason my game is still unfinished after 15 years is because web dev is a much more stable income which lets me give my evenings and weekends to my family, and in that time it's either spend time with them or spend time writing a game. So I have like 10 lines of code to show for the choice I've made :D
Regarding entity systems, I read a blog post somewhere which discussed a really good idea that I liked a lot for how to implement them. It recommended eschewing the typical OOP concepts and just writing a struct that had slots for each "trait" that an entity could have, like Movable (x,y & controls), Damageable (HP etc), Container (chests, boxes, secret bookshelves, etc) and in the update function, iterate each entity in the active game state and if they have a thing present, run the relevant function on it. Plus it allows things to have multiple aspects, like an "evil gnome" is both Damageable and Moveable but an "evil tree" is only Damageable, This sounds like a really doable approach.
Okay anyway, will bookmark those links and look into them more when I have time. Thanks for the recommendations.
Regarding entity systems, it's best not to implement as slots in a struct or something like that. Of course there are lots of ways to do it and varying performance. Interestingly, taking a data-first approach and iterating over the same kind of components within a system tends to be good for performance.
An entity is an int, long, or something else depending on your needs. It should be light-weight and not cause garbage to be allocated, thus why a long is good. A UUID/GUID is bad because you cannot use the entity id to cheat into pool rosters or other uses, not to mention it is hungrier for memory and slower to generate. Entity IDs should be allocated, often atomically and in one place and from a single thread.
A component is the data that you mention and should be a class or map/dict depending on the language. It is just a collection of fields, usually flat. Allocation should be done from a pool. It should be attached to an entity and detached as necessary. This is like a foreign key relationship per component to the entity ID if you want to think of it in DB terms.
A system operates on collections of entities, usually per frame/tick. Generally it is looking for one or more types of components per entity and isolating the logic there.
You can go outside the entity system for performance reasons like rendering if you must. Purity is good, but a lot of people go crazy and wreck performance. Be smart. The other hard thing is communicating between entities and between components. There shouldn't be any hierarchies or hard-coded things like that. Usually what is best is a queue or mailbox approach that the system can read from and deal accordingly, and then perhaps something more sophisticated beyond that as required per type of game.
My advice for getting games done in general if that's what you want to do is to just build a game and not an engine. From that regard, do dirty things like using pre-built engines such as Unreal or Unity. Better yet, just make a simple game. You will learn less, but be far more productive as a single person. If however you just want to muck around and learn things, then go wild. One thing we used to do to test architectures and game concepts that might be of interest to save time and explore me is we would build big chunks of a game with wire frames, stick figure-like things, whatever. If it's fun playing as a cube, it will be fun playing with a fancy sprite or 3d model.
Worth noting that Kotlin's support for compile-time inlining can help reliably eliminate object allocations that otherwise you'd rely on the JITC to eliminate. So that can help.
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.
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.
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!
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.
I've built a couple Vert.x apps in Kotlin and honestly I can't even think what first class Kotlin support would add. Vert.x already feels like a perfect match to Kotlin.
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/) 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.
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.
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?
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.
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.
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.
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?
And I'm happy to pay for their 'yearly license'. Great companies should have great revenues. I don't want them to end up like FoundationDB or RethinkDB. The fact that they get steady revenue ensures me that they won't perish and will keep doing great job.
Er, you're eschewing Kotlin despite it's being open source because of your perception that it's controlled by a corporate entity, but in the same post you want it supported in another open source product (VS Code) backed by another corporate entity (Microsoft)?
VS Code is miles ahead of Jetbrains offerings and has no yearly subscription fee.
MS was indeed one of my least favorite companies half a lifetime ago, but they've changed business models and are now pursuing a growth strategy (particularly wrt services) and have abandoned the fight to capture consumer surplus at all costs.
So charging for an IDE which requires hundreds of thousands of man hours of development and maintenance means they're evil and you won't use their products, open source or otherwise? Got it.
No. I honestly can't tell if you're trolling or not at this point, but "Er" is a horrible way to open a comment. Assigning a strawman position to someone you disagree with is equally horrible.
I've gladly purchased Jetbrains products in the past (and other dev tools as well). Noticing that a company is intent on capturing all consumer surplus they possibly can and disliking them for it is not the same as deciding they're "evil" for charging anything to begin with. Before moving to their subscription / hostageware "pay up or be forcibly downgraded model", I happily broke out the credit card and paid for Jetbrains offerings. I don't begrudge them that they sell software.
They just got too greedy and consumer backlash like this is the inevitable result.
I'd better to pay for editor than for compiler/core. Also JB is true software company, its their primary source of revenue. Editors is the only good way of monetization open-source projects.
UPD. When I pay for their job, I receive real stuff and not some obfuscated shit. The stuff that will be compiling even when the subscription ends.
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.
For loops require explicit and error-prone use of integer indices and are of limited utility outside arrays. Foreach loops in Java/C# are an attempt to generalise, but they are really just syntactic sugar over external iterators. They give privileged status to the specific iteration interface chosen, entangling the language and its libraries. The actual Iterator interface chosen by Java has proven to be unsuitable for coroutines/yield, but is now too difficult to change.
In Haskell, foreach loops can be implemented purely as a higher-order library function.
Yeah, I was meaning 'for loops' to include the modern sense of foreach loops too. Java doesn't distinguish and Kotlin doesn't have the old style at all.
There's no rule that says a for loop must only support a single iteration interface. That seems more like an implementation detail of the compiler than a problem with for loops in general.
Of course the big elephant in the room that I didn't mention, is that for loops get work done via mutation. This is perhaps what was mean't by “unclean".
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.)
We do.
We are migrating our WPF, Flex, VB6 apps to our custom fw based on KotlinJS, ViewModels and bindable properties.
There are some kotlin features whixh are not yet supported by JS compiler, ocassionaly something stops working with a new version of Kotlin plugin, but in general it is still the most productive frontend solution I experienced.
We also generate a Kotlin domain classes from our Java backend domain objects to keep strongly typing when building UI.
I have found Kotlin and Dart similar in many aspects, with the major difference that Kotlin is much better if you have a ton of Java libraries that you want to use along your code, while Dart is much better if you want to do frontend development. I'd suggest to check it out if your primary focus is compiling to javascript.
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.
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 ?
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.
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.
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.
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...
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.
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.
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.
As a really big Scala fan, I can say Kotlin is probably the right choice when it comes to doing Android development.
That being said, yes Scala has a steeper learning curve than say, Kotlin or Go. But if you're going to devote the I don't know, next ten years of your life to working in a particular language, does it really matter if it takes two months vs. four months to ramp up?
In the mobile space, I see a lot of "also ran" languages, never mind the platform. I don't think people who wrote iOS apps were much intent on using Objective-C outside of that, and I don't think Swift will improve much on this. A lot of Android developers fall into the same niche: They're using Java because they have to, not because it's their major background. So anything that makes their side errands into Android-land easier is welcome (cf. react-native).
Plenty of "ok-ish, but not too hard to learn" languages proliferate in that kind of climate, like go for small web services (where Erlang was too much of an investment). The Unix approach of 1001 ad hoc sub-languages (awk, pic, ed...) adapted.
Quite different from e.g. a J2EE developer's approach, who tends to think of career-defining technologies and languages, where Scala seems like a wise investment.
I've used both, Scala and Kotlin, and I like Kotlin very much.
A programming with more features is not necessarily better. The limited features of Kotlin (compared to Scala) are an advantage, if you change your point of view. Some advantages:
* easier to learn (a Java dev will be more productive than in Java in a day or two)
* easier to maintain since Kotlin doesn't allow so much hard to understand code constructs
* fewer discussions about the one true style or way to do something
* it's easier to build good tooling
* much faster compilation
* smoother Java interop
* performance implications are more predictable
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.