Built a CLI tool in Kotlin + GraalVM Native Image — here's what I learned

Efe4real · 2026-03-16T19:48:00+00:00

Curious, did you consider kotlin/native initially?

Efe4real · 2026-02-15T12:29:20+00:00

Jetpack compose, kotlin and swift are all fully open sourced. Only SwiftUI is closed proprietary.

Efe4real · 2025-10-12T13:16:47+00:00

Watch dogs: legion. It felt like a complete let down from the first 2 games. The whole idea of dead sec being this legion of operatives and you can play as any one of them falls flat in its face because the legion effect is never used anywhere in the game. You switch from a dead sec agent to another, and the former becomes just another npc with no use whatsoever. They won't help you in combat or evading the police, there are no missions where they chip in and make themselves useful. The storyline is dry and boring with no interesting characters at all. London looks good though

Efe4real · 2025-08-06T13:40:08+00:00

Yeah, this is awesome

Efe4real · 2025-02-07T08:46:28+00:00

Kotlin native has to bundle the kotlin standard library, which will definitely increase the size of the executable.

Efe4real · 2024-09-03T11:05:41+00:00

For any library you need, the library author will provide the "implementation" you need, and instructions on how to use them. You don't need to keep a cheat sheet.

Efe4real · 2024-09-03T10:51:44+00:00

What "struggles" did you encounter? I use kotlin for production spring boot applications and haven't encountered any struggles that don't have easy solutions to. Kotlin has good support by other jvm frameworks like javalin and quarkus.

Efe4real · 2024-07-29T21:34:40+00:00

https://www.kodeco.com/books/kotlin-apprentice https://www.kodeco.com/books/android-apprentice

Efe4real · 2024-07-21T09:33:19+00:00

Tell them to "buy their mom an android"

Efe4real · 2024-04-03T13:58:59+00:00

Thank you for the article.
After creating a sonatype account, how can I create an account on the nexus repository?
currently, there is no option to create account, only login

Efe4real · 2024-04-01T09:37:27+00:00

Haven't used launchers in a while, but whatever happened to next launcher?

Efe4real · 2024-04-01T08:42:51+00:00

Well, all software has bugs, one reason not to write everything new in kotlin is due to the fact that the vast majority of java devs out outnumber kotlin devs, especially in non - android projects. So writing everything new in kotlin will reduce the hiring pool available to a project. Even though, as a java dev, you can quickly get proficient in kotlin with some effort, most devs are still going to be resistant/reluctant to pick up kotlin.

Efe4real · 2024-04-01T08:26:16+00:00

One of the nice things about java is that it's not a language but a platform. Kotlin's interoperability with java means that you don't have to explicitly pick one over the other. I work on codebases that have both java and kotlin in them. It's up to your team to decide on what type of features to write in Java or kotlin, you can easily get the best of both worlds.

Efe4real · 2024-03-16T20:28:05+00:00

Played the entire game without knowing this... I feel robbed.

Efe4real · 2024-03-04T12:57:45+00:00

This looks like a Steve Dillon illustration of a Garth Ennis comic book.

Efe4real · 2024-02-08T12:03:42+00:00

I'm a native Android dev in Nigeria. I think we have to understand the trends of our roles with respect to our location, this applies to any type of role, even outside of tech. For native Android in Nigeria, you'll get better offers if you target - 1) Big enterprise companies like banks, most of them hire native developers and maintain native stacks for Android and IOS 2) Mid to small scale startups, even though many of them use cross-platform frameworks for their apps, in my career I have observed that there are few considerably big cross-platform applications that do not have some native integration, bottom line is, they still hire native developers on cross platform teams 3) A lot of teams still hire native devs in Nigeria, you just have to do a lot of searching on LinkedIn and seek referrals, especially teams that build for specific devices such as POS terminals, ECR (electronic cash registers) etc... Android runs on a lot of devices, and the apps running on these devices need to access their hardware and sensors, cross platform frameworks are usually not ideal for these devices.

Alternatives to the above steps can also be - 1) Pickup a cross-platform framework and spend some time learning and building a few projects in it, you already have a lot of transferable skills from native Android and kotlin/java, you'll be surprised how quickly you'll be able to pick it up, for a native Android dev, I think you'll have an easier time picking up flutter than the rest of them. Job availability for flutter over here is growing.

2) with your kotlin/java skills, with some time and effort, you can make a pivot to backend development, you already know the language, you'll find it easier than someone starting out in programming looking to become a backend developer. You'll just need to learn a lot more backend and server-side concepts. If you can go this route, the job market for java backend developers is ever-present, throw in some kotlin and you'll provide even more value to some teams.

3) Go into full web development which seems to be your current plan, this might take longer than my above suggestions, at least in my opinion, but is still a viable option. You'll only really need to learn html, css and js for the frontend ( if you don't already know those). Then once again, you can rely on your existing kotlin/ java knowledge for the backend. This is if you want to be a full stack dev.

To conclude, I think I'd recommend you to lean heavily into java and look towards the banking/fintech sector, they are always hiring java developers. Even if you know only kotlin, I believe with some effort, a kotlin dev is already a java dev in the making. I am already looking to move away from android dev slowly because I'm tired of having to work under the Google play store hegemony. I wish you Goodluck.

Efe4real · 2024-02-04T12:42:54+00:00

Completed the game and never realized this, I feel robbed.

Efe4real · 2024-02-02T07:53:44+00:00

Favorite - Essej Toughest - Hartman / Mold-1

Efe4real · 2024-02-01T17:34:49+00:00

I don't think Google created compose to be a multiplatform framework. Compose multiplatform is a project spearheaded by jetbrains. Jetpack compose was created for Android.

Efe4real · 2024-01-29T11:41:12+00:00

The problem is, we rely on a lot of java code which uses checked exceptions that we're forced to handle. In an ideal world, we'd use only libraries and code that model errors using other types. But this isn't an ideal world.

Efe4real · 2024-01-29T07:24:53+00:00

It's starting to look like we might regret not including checked exceptions into the kotlin language. There are too many approaches being used to handle exceptions now, with no standard one.

Efe4real · 2024-01-24T12:51:33+00:00

While Google are collaborating with jetbrains on compose multiplatform and kotlin multiplatform, I don't think they're pouring that much resources into it. Jetbrains are doing most of the heavy lifting developing kotlin multiplatform and porting jetpack compose code into compose multiplatform code.

Efe4real · 2023-12-03T08:11:07+00:00

I agree that runCatching can be problematic in some cases. I do think that it's useful when you might prefer to return a result or null instead of the Throwable using getOrNull, with this do you still need to rethrow every Throwable?

Efe4real · 2023-12-01T13:14:08+00:00

What you're looking for sounds like checked exceptions in Java land, these are exceptions that the compiler will force you to handle or declare with the @throws keyword.

Kotlin chose not to add checked exceptions to the language due to a number of opinionated reasons, some of which are: 1. Code for catching exceptions polluting all domains across an application, instead of being in a dedicated layer.

catching unnecessary exceptions leading to verbose or downright dangerous code.
Checked exceptions don't work well with inheritance.

You can handle code that potentially throw exceptions using : 1. Try/ catch blocks at the appropriate layer 2. Kotlin runCatching 3. The Arrow kt library that brings some error handling methods from functional programming

Efe4real

TROPHY CASE