People usually get confused when we tell them that we're using Kotlin for our backend APIs. I can't blame them because we attended KotlinConf last year and almost 90% of the audience were using Kotlin on the Android platform.
Hopefully, it gets more attraction from different platforms because staying in the JVM land and being able to use an expressive & lightweight language is great!
In short, if you are using Spring and are ignoring Kotlin, you are missing out a lot of good stuff. Or in other words, the same that happened to Java on Android is now happening to backend Java. You can still use it but why would you when things can be so much better with a simple upgrade to Kotlin (I've migrated tens of thousands of lines of code, it's easy). And yes Java 9-14 added a bunch of things that are definitely nice/useful but it doesn't come close to Kotlin in terms of expressiveness and language ergonomics.
Also, KotlinConf was on last week. There was a nice presentation about the state of kotlin-js, which is getting some nice updates in the next year including much better dead code elimination resulting in very compact minified code (< 100kb is now feasible for simple stuff), better integration of existing typescript type script defifinitions (i.e. support for most relevant npms out there), better build tooling in the form of an improved gradle plugin. Or put different, Kotlin might start doing to typescript/javascript what it already did to Java. IMHO it's a more capable language than typescript, which I consider to be pretty nice but it just lacks a bunch of things and comes with a some ugliness that relates to backwards compatibility with js.
In related news, Kotlin native is also happening. So, Kotlin is joining a list of full stack languages that used to be really short.
I tried using Spring with Kotlin last year but it felt verbose as if I'm writing Java so we decided to implement support for Kotlin in our in-house Netty-based server (https://github.com/buremba/netty-rest) and use it. Great to hear that Spring finally has native integration with Kotlin!
The native compiler is maturing and they are moving the JVM and JS compilers to the IR format they have developed for that. Additionally, they are going to support a new type of library that compiles to IR and that is reusable for all platforms.
They already have a few multi platform things. Mainly Ktor currently, which kind of should work on native. Additionally, you can target the node-js ecosystem via Kotlin-js. Also, one goal with Spring Kofu at least is also supporting GraalVM at least.
They are also adding more platforms to the native target.
Reading between the lines with what was announced last week at Kotlinconf, I expect a lot of this stuff might stay at least partially experimental through the 1.4 cycle (current is 1.3.61) and would expect that they might start pushing harder on backend native stuff around 1.5. Also there are still a lot of question marks around things like WASM where e.g. MS has a more clear strategy with .Net and Blazor.
Problem is that thanks to Android (stuck on partial Java 8 support), and JetBrains plans to put Kotlin everywhere as they try to build a business on top of it (Borland Turbo Pascal style), there is only so much that they can access on the JVM while making Kotlin code portable, specially regarding the Valhala, Panama and Loom roadmaps.
There is nothing keeping them from not making some constructs not portable to certain platforms. Mostly they try to do this with standard language constructs (of course), but for example the 'dynamic' type is completely javascript specific.
This only goes for Valhala. The other examples seem to be java playing catch-up to Kotlin (Panama for Kotlin native and Loom for co-routines).
Yes, the upside of one language should be that you don't have to write the same stuff multiple times. But if you don't want the downside of having one common denominator holding you back, then you have to write some parts specifically for each platform. That is the option Kotlin gives you. And my point was that this doesn't necessarily mean it will hold the specific platforms back (which seemed to be your point).
I the company I've been working at in Austin and we've been increasingly choosing Kotlin for our backend services as well. We started with Scala and found the ramp up to be tough. I came from a company that used mostly Ruby before and had no JVM experience at all and I found kotlin really easy to get productive with in a short amount of time. I actually prefer it in many ways not to everything else I had done before (I think I just really like static typing).
That's interesting.
I'd be more inclined to use Rust/C++ for the android devices since they are slow and more inclined to use Kotlin on the server because they are powerful :D
I don't know the situation on mobile but for cross platform Desktop the JVM is a great target for "write once, run everywhere", and Kotlin is a modern language that fixes or improves a lot of Java's common complaints.
Assuming a JVM is installed, distribution is as simple as sending a packaged .jar file.
There is a huge ecosystem of available libraries in Java, many with Kotlin wrappers for idiomatic usage.
Assuming JVM is (or will be) installed is a little risky though, isn’t it? We got rid of it in our enterprise setting some years ago, and we hardly seem unique in having removed JAVA from our available techs in our area.
I know games aren’t exactly meant for enterprise, but it’s been even longer since I had a JVM on my private computer. Maybe I’m alone in that?
This is not to shit in Kotlin, it’s certainly a nice language, but I wouldn’t expect widespread adoption to be what it was a decades ago.
One usually just bundles a jre and package the whole thing to a binary[0]. You wouldn't even know the game you're playing is running java. One could probably improve this further with modules and the newer additions to java/jvm (jlink).
Yup, with jlink you don't need to ship a full JRE, just the parts your binary actually uses. The user just runs a small binary and doesn't need to install and update a separate JRE.
The alternative (which is against the initial argument that you just ship a .jar) seems to be to include a JRE with your software. Minecraft and LibreOffice do this for example.
My recent java experience is that you end up having to tune it and keep multiple versions and screw around a bunch if you’re doing more than one thing with it. Stick to Android dev and it’ll be fine after the initial config, but switch to something else or try to run some GUI java project off Github and you’ll lose time configuring it. I “nope” out of a lot of Java stuff as soon as I see it’s Java, as a result. If anything the situation seems a little worse than it was in, say, the ‘00s.
I sympathize with your problems, I also had to juggle multiple versions for a period of time on multiple projects. Docker thankfully eliminated that and even without it the most you have to do now days is to point "$JAVA_HOME" to another folder. Java and it's ecosystem is better than ever and the language updates since java 8 are great to work with. The JVM is great. Spring boot finally removed most of the the multiple days config issues. Everything is mature, every problem has one or more library to solve it.
> Assuming JVM is (or will be) installed is a little risky though, isn’t it?
At least in Linux the package management systems enable packagers to specify dependencies such as the JVM. In Windows perhaps it's possible to bundle a JVM of choice.
I wouldn't say "spectacularly", as I don't remember that many attempts at true end-user apps. Enterprise is ripe with Swing.
Nowadays of course the web has blunted our pain receptors for memory bloat and non-native UIs, thus you're probably running three Electron apps right now, compared to which Java is Win32ASM.
And as others pointed out, for games it doesn't matter anyway. You're not building a AAA-game or something for a 6510, so GC pauses and memory consumption don't matter, either. Plus rapid-development, refactoring and a setup where OOP actually makes good sense.
I wouldn't start Kotlin for that, but if you already know it, there's no reason not to use it.
GC is also not that big of an issue in these type of games if one's careful of using pools for the various objects, and then release stuff at appropriate times.
It's more that Desktop development just fizzled out. These days if you are targeting fortune 500 companies with custom applications, you'd have to support multiple platforms in any case and the web makes that a no brainer. Add mobile to the mix and it's game over for desktop app developers.
I'm sure there are still people doing it but it's becoming quite rare that that does not involve electron or similar with a lot of web technology. I haven't come across any projects involving desktop UIs in recent years. Plenty of native IOS/Android + web. But absolutely nothing that had desktop UI on a roadmap or backlog or even on a nice to have list.
Java used to own that space when it still existed. IMHO that went away between 2005-2010 time frame. Before that you could get away with not supporting OSX (or Linux, ever the afterthought) and building stuff with Visual Basic, Delphi or whatever.
I wouldn't really count either as "Desktop". It's basically mobile development for phones and tablets, which I wasn't excluding. ChromeOS is nice but mostly about running web stuff plus whatever kind of works from the Android or Linux ecosystem. I don't think there are a lot of people targeting that specifically.
Enterprise applications are almost exclusively web based. And consumer software that isn't games is mostly web based in electron or one of a few remaining big desktop products (e.g. MS Office or Adobe tools) and also a long tail of relatively niche stuff.
Last time I used a box or tower based desktop was in 2005, since then I only worked in offices where "desktops" are laptops, or more recently 2-1 hybrids, which most people use just like the desktops of yore plugged into docking stations.
It works fine for cross platform tools where how good the GUI looks is not a concern. As an example the last such app I seen was a tool to cleanup some save games for a video game that was Windows and Mac so the person that made the tool used Java and Mac users could benefit of the tool, For Windows only games most such tools use .Net and Windows Forms.
Good GUIs are possible, just that not everyone bothers to read books like "Filthy rich clients", having a designer on their team, or shelling out for component libraries like JGoodies.
What I mean is "good looking GUIs" , as a dev when I create a basic tool , something that are not for customers to see and complain about I don't care about fonts,paddings, "professional looking design" , you get your buttons and inputs and job is done.
The tool I use daily for making money is Intellij, I don't f* care that the menus and buttons do not match my DEs,
I would also prefer programs that use the system defaults rather then try to implement a better theming with custom buttons,colors and whatever some designer with big ego thinks is cool today(I can't understand why they like slim fonts with low contrast colors)
As well as the JVM, there is Kotlin/Native, based on LLVM. This allows a Kotlin mobile app to run on JVM in Android and as a compiled binary on iOS. It can also target WebAssembly to run in a browser too.
On a side note, there seems to be a lot of links being posted from vanity TLDs such as .christmas. Isn't there a risk of these links ending up broken in a matter of nothing?
Most of these have been originating from bekk.christmas it seems, who are making advent calendar blog posts leading up to christmas about a variety of topics under various .christmas domains.
They apparently did it last year as well, so the domains have lasted at least a year, then?
We saw a steady flow of traffic all through last year on a few .christmas domains from last year's advent calendars.
I don't think they seem stale, but perhaps out of season Either way, we're committed to keep this content online for the foreseeable future, and write a new edition next year if people find it interesting.
Domains expire after a year, so it you'll always be renewing around Christmas. Unless you were referring to maintaining the site itself, which yes, probably won't have any new postings around July.
On a side, side note — Are those funky TLDs really widely supported/interpreted as links when not using http in main-stream apps (Mail or even browsers)?
Worse, everything.anything is now treated as a domain, leading to accidentally trying to browse when watching to search for dot separated programming terms such as libraries.
This happens on Twitter a lot. I've seen a lot of people referencing names of libraries, events, etc. and them being turned into links to URLs that don't exist. (.app is a common one for this.)
It also happens, rather unfortunately, with my aging parents who love to sign off emails with 'xxx' and are often missing the space after the final period and ending word of the email. Some of the results are guaranteed risky clicks.
Accidental typos (better yet, missing space after a period) also triggers some clients to send HTTP requests to the pseudo-URL to build up a quick view, which sounds like a potential security problem.
Shameless plug: I'm working on a multiplatform library (https://github.com/Hexworks/zircon) which can be used to write roguelike games with ascii and/or tile based graphics. The whole project is MPP Kotlin (99% common code). We have a LibGDX renderer as well (although we're not using LibKTX yet).
Kotlin seems to have a lot of the tooling required to make games pretty quickly. That's not to say it's not a massive undertaking! The demo at the bottom is just mindblowing
We've been experimenting with this model too, as "write once, run anywhere" is very tempting for business logic, but those platforms have traditionally fallen down when it comes to UI and other native functions (e.g. alarms, sensors, etc). So far, it's proving very do-able. Non-trivial in some areas such as multi-threading, but a lot more practical than replicating the same logic across Android, iOS, and web.
Because I absolutely love Kotlin and I feel I'm much more productive with it. I have a hard time working with script languages and feel confident on my code nowadays.
I can confirm that. I have a couple of games on App Store that use it. I built them initially in 2015 and have updated them a couple of months ago with the latest libGDX.
I used RoboVM just like that person in the article, but I used it with Intellij IDEA instead of Android Studio.
It works and it's pretty easy and straightforward to set up.
I know that a killer feature for Kotlin is that you can use the same code to compile to JS, JVM and Native. Is it actually feasible in practice? Can I make a game that will compile to JS, JVM and Native all with the same code? I assume the core logic would be shared and I'd have to implement platform-specific routines for things like drawing and input, but would this actually work?
Only if all the libraries you use aren't JVM specific. In this case, the developer is using wrapper for a Java library so I doubt it's possible.
There's no reason the wrapper couldn't be enhanced to use the Java library on the JVM and something else on native but it would probably be a lot of work.
Although not strictly a game engine, OPENRNDR[0] could probably be used to create one in Kotlin.
> OPENRNDR is a tool to create tools. It is an open source framework for creative coding, written in Kotlin for the Java VM that simplifies writing real-time interactive software.
We are using Kotlin in most of our backends running on AWS. We are very(!) happy with the Kotlin developer experience as well as the adoption curve that we have seen throughout our company. I can only highly recommend giving it a try and do not believe it is only meant for App development.
Hopefully, it gets more attraction from different platforms because staying in the JVM land and being able to use an expressive & lightweight language is great!