I'm working on a security tool that has both GUI and networking code. There's configuration in the GUI and the configuration data is used in quite complex code that parses and modifies network traffic. Because the user is configuring the setup bit by bit in the GUI, various fields can be null. But the network section only works when the GUI is mostly configured.

If I'd written this in Java, realistically what I'd have done is chuck it together, fix a few glaring NPEs in early testing, and probably live with a few NPEs when it was partially configured. I realise this is not the textbook way of coding in Java, but realistically, that's what I would have done.

Kotlin of course doesn't let me do that. At first I used a few ?. and ?: calls to introduce null safety, but these were starting to look messy, and complicate the flow of code that is already quite complex. It made me realise that there's two conceptually different things here. There's a GUI model with nullable fields, and there's a config model with non-nullable fields. When the GUI is sufficiently completed, it can create a config model. This means the network code can skip the null checks, as the network code is only active if there is a config model.

Sure, I could have introduced this structure in Java, but would I have done that? This is especially relevant for people like me where my primary job is security and I am coding to help me do security work better, not as an end in itself.

JetBrains asked 8,837 developers why they switched programming languages in the State of Developer Ecosystem 2025 Survey. For most languages, the most common answer was that a project required it. Kotlin is the exception:

"People don't go to Kotlin because they have to, but because it offers a better development experience and more modern language features."

The migration tables for the most popular languages, with the reasons given for leaving and joining, are here:

https://kotl.in/lang-migration-reddit

Someone posted a bunch of usability issues with K/JS, and I wanted to explore them in a new post, mostly to have more space to write and also for better awareness.

• Big bundle size. Maybe related to coroutines compiling down to continuations. Even worse with kotlinx-serialization which uses code generation.

  This can indeed be a problem, especially when targeting the browser as there is currently no native way to split into chunks. While there is currently no solution, it appears data-flow-driven optimizations are being explored, see KT-87404. Strictly speaking about coroutines, the state machine is now compiled down to JS generators, which saves quite a bit of space! See KT-81730.

  Additionally, deferred imports when targeting modern ECMAScript (KT-20679) by transpiling with SWC (yes, K/JS does offer an experimental way to transpile with SWC) will definitely help in this regard by improving loading times.

• No Lazy JS exports: this means that if your class is not available on the window at launch, it's going to break despite the class not actually being used.

  I'm not sure I understand this one to be honest. Maybe I've never encountered it.

• Enum/Data class mapping onto JS objects and TS enums: right now requires you to write a ton of conversion code to make APIs usable from JS.

  Fair enough! I agree this is actually pretty bad right now. I feel like optimizations could go towards:

  1. Sealed hierarchies should have a discriminator KT-71798
  2. Sealed interfaces with static values should be exportable as unions. This is possible with https://github.com/turansky/seskar#unions.
  3. Constructor arguments should be exported as object parameter KT-63669

• Lack of a couple of type defs for browser APIs (can't remember anymore which ones exactly, they don't cover everything 100%).

  As far as I know kotlinx-browser is kept fairly up-to-date. The alternative is to use kotlin-wrappers.

• Webpack and Karma toolchain (is going to get changed).

  Indeed, the idea seems to be allowing proper extensibility, that is, you'll be able use whatever tool you prefer by extending KGP or via DSL. In the meantime, Karma is being replaced with Playwright via a new DSL as you can see at A new DSL for browser testing.

• Suspend functions to async functions and TypeScript defs were just stabilized in 2.4 I think (buggy support prior if at all).

  True. From 2.4.20 you'll be able to export pretty much any suspend declaration, including suspend lambdas.

• Bad debuggability. I have to ship debug builds or the stack traces are impossible to read, despite having source maps. Even worse when coroutines are involved.

  Honestly I have not encountered this issue, but maybe it is because I ship to Node.js. That said I believe that and I don't have any real suggestion. In the future, using stuff like Source Map Scopes might give us access to more data while debugging and improve stepping. It appears some work to support that is already being done.

• No support for mixins (yes people use them).

  This can be done with kotlin-wrappers and seskar. See this test case with the @JsMixin annotation.

• Lack of documentation. Especially bad for Kotlin Wrappers and Gradle build docs.

  I can comment on the Gradle side of things: it does take time to get used to it. Exploring Kotlin's source code for the compiler and Gradle plugin gives you a lot more insight in what can and cannot be done.

• TypeScript interface equivalents use a compiler plugin (@JsPlainObject) which still produces red squigglies in IntelliJ and sometimes does not properly auto complete.

  This was an IntelliJ issue. If you can still reproduce in 2026.1 or 2026.2 it is definitely worth reporting it.

• I don't think there is a great way yet to consume TypeScript type defs (basically translating d.ts files into "expect" typedefs). There's a library but I think it's still experimental.

  Dukat is dead at the moment. What you are probably referring to is Karakum. Karakum supports writing plugins in Kotlin btw! But documentation is still pretty limited so the best bet is to go look at how kotlin-wrappers projects are set up.

• Lack of ergonomic interop: Using Kotlin from Java is pretty straightforward; sometimes you need an annotation like @Throws or @JvmStatic but most of the time, it's very neat. Using Kotlin from JS is impossible without bridging code.

  This was very valid a couple years ago. I can guarantee that things have improved quite a bit. What we are still missing is:

  1. Exportability of class properties without accessors, so that objects can be naturally (de)serialized KT-17683
  2. Exportability of unsigned numbers and primitive arrays KT-51389
  3. Exportability of coroutine "primitives" like Channel and Flow KT-80733
  4. Exportability of dependencies via DSL (where @JsExport cannot be manually added) KT-47200

And btw, if you want to know which flags the K/JS compiler supports, go look at K2JSCompilerArguments.kt.

JetBrains doesn't ship tvOS artifacts for Compose Multiplatform, and the issue asking for it (CMP-5686) has been open for a while. I needed it for my own TV app, so I built the port and published it. It's a community project, not official. I posted it in Kotlin Slack #compose-ios earlier this week; this is the longer writeup.

Using it

// settings.gradle.kts
plugins {
    id("dev.sajidali.compose-tvos") version "1.3.0"
}

Add tvosArm64() / tvosSimulatorArm64() to your KMP module and leave your dependencies alone: org.jetbrains.compose.*, androidx.tv:tv-material, Koin, Coil 3, all stock coordinates. Kotlin 2.3.20+.

How it works (the part I think is interesting)

It's not a hard fork you point your build at. The settings plugin registers a component-metadata rule that, at dependency-resolution time, attaches tvOS variants to the official Compose modules and points them at tvOS-enabled builds published under dev.sajidali.* on Maven Central. Every other target keeps resolving the official JetBrains artifacts byte-for-byte, and it's official-first: if a module already ships tvOS klibs upstream (compose.runtime, koin-core, lifecycle...), the plugin leaves it alone. So when JetBrains eventually ships tvOS for a module, the plugin steps aside for that module with no change on the consumer side. It also intercepts the org.jetbrains.compose Gradle plugin marker so compose.material3 etc. resolve correctly.

The fork itself (compose-multiplatform-core with tvOS as a Kotlin/Native target) is where most of the work went:

• A tvOS UIKit scene stack sharing the iOS FrameChoreographer architecture
• Siri Remote input: D-pad focus traversal, swipe-to-focus, Menu mapped to Key.Back, and telling a clickpad press apart from a swipe by hardware timestamp
• 10-foot density (Compose's default density on a 4K TV is unusable), on-demand keyboard for text fields, focus restoration when dialogs close
• androidx.tv:tv-material ported to Compose Multiplatform with a tvOS source set
• A real tvOS build of window-core so material3-adaptive works without stubs
• Koin (koin-compose, koin-compose-viewmodel) and Coil 3 with tvOS targets, since neither ships them

Proof

The GIF is Google's JetStream TV sample (all screens, D-pad focus, theming, AVPlayer on tvOS / ExoPlayer on Android TV behind one interface) on the Apple TV 4K simulator, built from Maven Central + the Plugin Portal with nothing published locally. The same toolchain builds a production TV app of mine with zero app-source changes.

Honest limitations: no automated tvOS tests yet; tvosX64 isn't built; I republish roughly once per Compose stable line (currently 1.12.0), as far as my own app needs. PRs welcome.

• Plugin + docs: https://github.com/sajidalidev/compose-tvos (docs: https://sajidalidev.github.io/compose-tvos/)
• JetStream port: https://github.com/sajidalidev/jetstream-tvos (branch cmp-tvos)
• Forks: https://github.com/sajidalidev/compose-multiplatform-core, https://github.com/sajidalidev/koin, https://github.com/sajidalidev/coil

Every "responsive Compose UI" example I found for WindowSizeClass ends up as a wall of if (width < 600.dp) ... else if (width < 840.dp) ... scattered across every screen. Refactored ours into a sealed class hierarchy (Compact/Medium/Expanded, each carrying its own layout params) and just pattern-match on it with when at the composition root instead.

Ends up much easier to test too — you can construct each sealed subtype directly in a Compose UI test without faking window metrics.

Wrote up the full pattern, including how it plays with foldables and the hinge/posture APIs (which is where it gets genuinely annoying): Please check comment ⬇️

Curious if anyone's modeled this differently — especially interested if people are handling the posture APIs with a different state shape.

Sometimes Kotlin just feels unfairly nice.

```kotlin

val start = LocalDate.of(2024, 1, 31)

val end = LocalDate.of(2024, 12, 31)

for (date in start..end step Period.ofMonths(1)) {

println(date)

}

So I'm new to Kotlin, and I'm trying to make a guess the number game for terminal and I wanted to make a little text intro and clear the console after, but I haven't been able to do it. I found some ways to do it but not as I want to.

Because when you do the clear command in the terminal, it wipes the whole thing, and you can't go back, but when I use commands like "print("\u001b[H\u001b[2J")" or "System.out.flush()" it is like it just pushes the view down; it doesn't really wipe the terminal, it just pushes the text up.

I wanted to know how or if it's even possible to do it. I don't know if it might be helpful, but I use Windows 11 and PowerShell (7.6.5).

Also, in another topic, I want to hear if there's a better way to try my code because right now I'm doing kotlinc .\file-name.kt -include-runtime -d .\file-name.jar && java -jar .\file-name.jar

Hey everyone, following up on kiit-codes from a couple weekends ago, a small taxonomy for classifying success and failure into named groups (Succeeded, Restricted, Invalid, Rejected, ...) instead of a boolean or a numeric code.

I've now published kiit-result, a Result<T, E> type built directly on that same taxonomy, to tell you the kind of success or failure.

Most Result/Either types treat success as just a value. There's no separate classification for whether it completed normally, is still pending, or was intentionally excluded (a duplicate, for example). On the failure side, E usually carries the error details, but there's no independent classification of the kind of failure.

Here, both branches carry a status:

1. Success<T> : Gets a Passed group (Succeeded/Pending/Excluded/Information)
2. Failure<E> : Gets a Failed group (Restricted/Invalid/Rejected/Unserved)
3. Separation: T holds value, E holds error, and Status holds the kind of success or failure

A few things worth knowing:

1. Status on both branches: the primary differentiator from other Result/Either types, status classifies the kind of success or failure independent of T/E, most libraries only give you that on the failure side, if at all.
2. Progressive Adoption : Status is optional to manage in daily use. Builders (see below) apply sensible defaults, so you only need to pick one when you want the extra precision.
3. Type Aliases: E stays fully generic, Outcome<T>, Try<T>, Option<T>, and Validated<T> are just aliases on one Result<T, E>, not four separate types.
4. Builders: restricted()/invalid()/rejected()/unserved() pre-populate the matching status via sensible defaults, so it's rarely built by hand.
5. Familiarity: map, flatMap, fold, ... isn't novel, most of it has precedent in Rust, Swift, Kotlin libraries. The actual bet is the taxonomy fused onto both branches, not new operators.
6. Action: either branch can also carry optional context, recording which operation produced a result, for debugging across nested or chained calls.implementation("dev.kiit:kiit-result:1.0.2")
7. GitHub: github.com/kiitdev/kiit-result
8. Docs: kiit.dev/docs/kiit-result
9. Tutorial: kiit.dev/docs/kiit-result#tutorial

Curious what people think. Happy to answer questions in the comments.

Thanks!

Edit: Updated diagram

Hey everyone,

If you haven’t seen it before, ReqLab is an open-source, desktop-first API client I built with Kotlin and Compose Multiplatform. It runs completely offline with no cloud lock-in, no telemetry, and no mandatory accounts. It’s built to be a fast, scriptable alternative to tools like Postman or Insomnia.

I just rolled out a major update introducing two heavily requested features:

🤖 Full MCP (Model Context Protocol) Client Support

ReqLab is now a full-fledged MCP client that lives right inside your REST workspace!

• Integrated Workflow: Your MCP items sit side-by-side with your REST requests, sharing the same collections, environments, and response panes.
• Rich Features: Supports tools (Form/JSON), resources (read + subscribe), and prompts. You also get an Activity JSON-RPC inspector to see exactly what’s going on under the hood.
• Multiple Transports: Works with streamable HTTP, desktop stdio, legacy HTTP+SSE, and auto fallbacks.
• Variables Everywhere: Interpolate your {{variables}} directly in URLs, commands, headers, and auth (which uses the exact same editor as REST).

📝 JSON5 Authoring by Default

Working with raw JSON bodies can be a headache when you just want to leave a comment or drop a trailing comma.

• I've updated Compose-native code editor to support JSON5 authoring by default for your request bodies.
• You get syntax highlighting, comments, and unquoted keys in your editor, and ReqLab will automatically convert it back to strict JSON when the request is sent over the wire.

I’d love your feedback!

I'm constantly trying to improve the developer experience and make this the best offline API client out there.

If you get a chance to clone the repo and run it (or download the latest release), I want to hear from you!

• How does the MCP workflow feel alongside your traditional REST requests?
• Are there any specific MCP tools or edge cases you’d like to see better supported?
• Any UI/UX rough edges you ran into while editing JSON5 payloads or setting up scripts?

Check out the repo here: https://github.com/snj07/req-lab

I moved the core of a small library from Kotlin to Java mainly to avoid pulling kotlin-stdlib into pure Java applications.

After doing it with Java I ended up adding JSpecify, @NullMarked, nullable annotations, and extra Kotlin compatibility tests just to preserve the same nullability behavior.

For a small JVM library meant for both Java and Kotlin users, would you keep the core in Kotlin and accept kotlin-stdlib as a dependency?

Or do you think keeping the core Java-only is worth the extra work?

I've been trying to use Kotlin/Native for desktop/CLI stuff, and honestly it feels like you get a native binary and then you're on your own. Basic things like logging, resource loading, decent file operations, and process execution are either missing or surprisingly painful. kotlinx-io helps, but it's still pretty limited. There are third-party libraries for some of this, but a lot of them are incomplete, barely maintained, or just don't cover what you actually need. Meanwhile in Rust/Go/Graal NativeImage, this is boring standard-library stuff and you can just get on with building your app. Kotlin/Native is cool technology, but for desktop development it still feels like an unfinished platform rather than something you'd actually choose for getting work done. Would be nice if JetBrains spent some time on the boring fundamentals that make a platform actually usable.

Hey guys, I’m building an Android app that needs map + navigation, custom map icons, and support for multiple transportation modes (car, bike, walking, etc.).

Would you recommend Google Maps, Mapbox, or something else? Any experience with these would be appreciated!

The Java docs say:

"Exception" indicates conditions that a reasonable application might want to catch.

"Error" indicates serious problems that a reasonable application should not try to catch.

I agree with this distinction. I don't want to recover from things like "OutOfMemoryError" or "StackOverflowError".

However, I have a "Builder" class with lifecycle methods:

try {

initializeState()

attachProviders()

isConstructed = true

onConstructed()

} catch (e: Exception) {

reset() // detach providers + clear internal state

throw e

}

The "catch" isn't for recovery. It's only to rollback internal state and then rethrow the original failure.

So should this be:

catch (e: Exception) {

reset()

throw e

}

or:

catch (t: Throwable) {

reset()

throw t

}

Does the fact that I'm only doing cleanup/rollback change the usual recommendation against catching "Throwable"?

I have also read this discussion on stackoverflow. But it does resolve my doubt.

I'd especially appreciate to hear from other for :

- When should "Throwable" ever be caught?

- Should rollback/cleanup catch "Throwable" or only "Exception"?

- Any other cases related to it ?

I’m designing a small Kotlin lifecycle API and would like some guidance on the conventional ordering/naming.

Currently I have:

fun attach() {

isAttached = true

onAttach()

}

fun detach() {

isAttached = false

onDetach()

}

The provider maintains internal state: "attach()" initializes it, while "detach()" clears it.

The question is specifically about "detach()".

1. Option 1

detach() {

isAttached = false

onDetach()

}

Here "onDetach()" runs after the provider is already marked detached. If the callback needs provider state that was cleared as part of detaching, that state may no longer be available.

1. Option 2

detach() {

onDetach()

isAttached = false

}

This seems more practical because "onDetach()" can still access the attached state, but the naming feels slightly contradictory: the method is called "onDetach()" while the provider is technically still attached.

I’ve looked at several lifecycle implementations and noticed that the second pattern seems fairly common.

So what is the better general design?

If the callback is intentionally called before the state changes, should I rename it to make that explicit, for example:

attach() {

isAttached = true

didAttach()

}

detach() {

willDetach()

isAttached = false

}

In other words, should I use the more explicit didAttach() / willDetach() convention for the asymmetric ordering, or keep the onAttach() / onDetach() naming?

Suggest on both the ordering of onDetach and the naming convention that would make the API least ambiguous.

Kotlin is no longer hot, or talked about much. In fact the only library and framework I come across are Jetpack compose and KMP, and Ktor. It almost seems like Jetbrains is the only contributor to the Kotlin ecosystem, I don't see much of any other libraries or frameworks.

Is Kotlin in the phase where there is no hype and is used in production? I wanna hear stories from people here who used or are using Kotlin in production (Which i know, there are quite a lot)

Earlier I was looking to get into game dev with Kotlin for fun. while the libraries are there and Kool seemed fun, there is almost no usage of it anywhere. since they aren't used, you won't find many posts about them on forums, or any discussions about them. Forum discussions are a great way to learn any library/framework

I wonder where kotlin is headed towards, as I feel like it is almost the perfect language, yet it does not seem to be the first choice when developing applications, even on mobile. People still prefer web alternatives (for obvious, and fair reasons)

Caused by: java.nio.file.AccessDeniedException:

C:\Users\avodr\.gradle\.tmp\jdks\jbrsdk_jcef-21...tmp\jbrsdk_jcef-21.0.10-windows-x64-b1163.108

-> C:\Users\avodr\.gradle\jdks\jetbrains_s_r_o_-21-amd64-windows.2

I've posted version 0.10 over here when it was still named kotlin-lsp, some big changes since then, including cli diagnostic commands like missing imports and unused imports, some benchmark to see accuracy rate in your project.

Some are still guesses, since gradle dependencies resolution is hard, but you can narrow that down with workspace.json which official LSP uses.

How's this one different ? Mainly dumb mode and fast indexing, low memory footprint and ideal for use in your agents. Spurred by latest jetbrains LSP which I couldn't make to work on my projects, I present an alternative, give it a try, let me know if anything's broken.

https://github.com/Hessesian/kmp-lsp (renamed from https://github.com/Hessesian/kotlin-lsp )

​

I'm new to all this, I know I can get it from LRCLIB but I need word by word lyrics (like apple music) for my music app (made with kotlin) I can't do it, I found Lyrically but it doesn't seem to work for me

I want it to be free, without rate-limiting

Are there any options? Or I will have to do scraping myself

every java + aws project i've worked on hits the same wall in tests.

you either spin up localstack in testcontainers and wait 30-60s per

test class for docker to warm up, or hand-roll mockito mocks that

break on every sdk upgrade. neither is great.

python has moto for this. in-process aws fakes, 8k stars, tests run

in ms. someone actually asked aws on re:post if there was a java

version. the reply was basically "moto is a python library, no

equivalent for java."

how do other people handle this? is it just accepted that aws unit

tests are slow, or is there something people use that i missed?

I am a beginner to testing and I may be not acquainted with all underlying techniques . So guide me on when should I use Junit and when to employ Kotlin test. If my project is not multiplatform then what to choose . Or should I go with mix of junit and kotlin test such as @Test from junit while all assertX from kotlin test.