Struggling to keep your kids/students engaged in learning Kotlin?

Introducing Rotlin.

No more memorizing normal syntax. Embrace the degeneracy and engage with the youth.

A statically typed, null-safe, object-oriented programming language for teaching web dev but with brainrot syntax.

Compiles to Kotlin so every Java/Kotlin library works

I should take my meds.

They are unlisted on YouTube, but you can get to ’em from the website.

I expect the rest are on the way.

Which one is your favorite?!

Hey kotlin devs,

I have been a developer for 2 years now, mostly using Kotlin for Android and Java for backend. After working with both, I feel like Kotlin is becoming unnecessarily complex because it’s trying to be everything at once.

Betwen deep OOP, functional programming, and massive async concepts like advanced Coroutines, it feels like there's just too much abstraction. Honestly, this is why I still love Java on the backend. Yes, it is verbose, but it is clean, explicit, and highly predictable. You always know exactly what the code is doing.

Lately, I decided to stop chasing complex feature in Kotlin because it just ruins my productivity. Instead, I have stripped my usage down to a simple, predictable subset:

• Standard OOP and basic Kotlin concepts.
• Basic functional concepts (like collection operations, Extension function, High Ordered Function).
• Basic coroutines for simple background work.

I really think a language should be simple and powerful, not bloated with endless concepts.
Anyone else intentionally keep their Kotlin simple just to stay sane? Or am I missing something?

I see that new startups barely pick Java/Kotlin as backend language. They usually pick node.js/python/Go. We usually see Java in old companies, and these companies sometimes choose to write new stuff in Kotlin.

The old companies will somewhen get closed. If the new generations of companies do not pick Java/Kotlin, then the conclusion is that these languages will become obsolete (at least for backend) in the near future.

What do you think?

between method1 and method2 which has better performance and lower overhead?

ChatGPT says method1 is slightly cheaper but Gemini says method2 is better.

(dont complain about semikolons in the comments, its harder to know if this line is the end of the statement or if it continues in the next line)

@file:JvmName("Suppliers")

import java.util.function.IntSupplier;

@JvmSynthetic
@JvmName("_intSupplierOf")
inline fun intSupplierOf(value: Int): IntSupplier = IntSupplier { value };

@JvmName("intSupplierOf")
fun _intSupplierOf(value: Int): IntSupplier = IntSupplier { value };

class Test {
	fun method1(): Int {
		val x = intSupplierOf(3);
		return x.getAsInt();
	}

	fun method2(): Int {
		val x = _intSupplierOf(3);
		return x.getAsInt();
	}
}

decompiled Java code for reference:

public final class Suppliers {
	// $FF: synthetic method
	@JvmName(
		name = "_intSupplierOf"
	)
	public static final IntSupplier _intSupplierOf(final int value) {
		int $i$f$_intSupplierOf = 0;
		return new IntSupplier() {
			public final int getAsInt() {
				return value;
			}
		};
	}

	@JvmName(
		name = "intSupplierOf"
	)
	@NotNull
	public static final IntSupplier intSupplierOf(int value) {
		return Suppliers::_intSupplierOf$lambda$0;
	}

	private static final int _intSupplierOf$lambda$0(int $value) {
		return $value;
	}
}

public final class Test {
	public final int method1() {
		int value$iv = 3;
		int $i$f$_intSupplierOf = false;
		IntSupplier x = (IntSupplier)(new 1(value$iv));
		return x.getAsInt();
	}

	public final int method2() {
		IntSupplier x = Suppliers.intSupplierOf(3);
		return x.getAsInt();
	}
}

I have an MVI/UDF feature with two entry flows: a pre-action flow and a post-action flow.

One idea I had for the initial step is to have a repository, or similar abstraction, determine whether the feature should start in the pre-action or post-action flow. The ViewModel would call this repository, which would return the initial flow along with the data needed to render the first UI state.

My team's existing preference is to model UI state using sealed classes, where only one screen state is active at a time. I'm thinking of following the same approach for the new flows we're building so the pattern stays consistent across the feature.

Example state shape:

sealed interface FeatureUiState {

    // Pre-action flow entry.
    // User selects the initial date and time.
    data class DateTimeSelection(
        val date: String,
        val time: String,
        val isNextEnabled: Boolean
    ) : FeatureUiState

    // Shared loading state while calling the validation/recalculation API.
    data object Loading : FeatureUiState

    // Pre-action flow.
    // Displayed after the API returns the calculated values.
    // One extra value is calculated locally before the user can save.
    data class EditPreparationTime(
        val preparationTime: String,
        val estimatedPickupTime: String,
        val estimatedDeliveryTime: String,
        val fireAtTime: String,
        val isConfirmEnabled: Boolean
    ) : FeatureUiState

    // Post-action flow.
    // User edits preparation time. One value is recalculated locally,
    // then the API recalculates the remaining values.
    // The same screen is shown again with the updated API values.
    data class AdjustPreparationTime(
        val preparationTime: String,
        val estimatedPickupTime: String,
        val estimatedDeliveryTime: String,
        val isNextEnabled: Boolean
    ) : FeatureUiState

    // Shared saving state.
    data object Saving : FeatureUiState

    // Shared API error state.
    // When dismissed, the entire flow restarts from the beginning.
    data class Error(
        val message: String
    ) : FeatureUiState
}

The flow would look like this:

Pre-action flow: DateTimeSelection → Loading → API success → EditPreparationTime → calculate local value → Saving

The user can also navigate back from EditPreparationTime to DateTimeSelection. When they do, the previously selected date and time should be preserved.

Another thing I'm unsure about is how to model this in MVI/UDF. Since the UI is modeled as a single active sealed state, once DateTimeSelection is replaced by Loading and then EditPreparationTime, the original DateTimeSelection state no longer exists.

When the user presses Back from EditPreparationTime, what is the idiomatic way to restore the previously selected date and time? The domain model may only contain the original/default values, so recreating the screen from the domain model would lose any changes the user made before navigating forward.

Should the ViewModel keep the last selected date/time as draft UI state, keep the previous DateTimeSelection state somewhere, or is there a better pattern for handling this while still keeping a single active sealed UI state?

Post-action flow: AdjustPreparationTime → Loading → API success → AdjustPreparationTime with updated values → Saving

Any API error: Loading / Saving → Error → Restart the entire flow

One part I'm unsure about is the shared "Loading" state.

Both flows call the same API, and the API response contains the same fields, such as preparation time, estimated pickup time, and estimated delivery time. However, after the API succeeds, the next state is different depending on which flow triggered the API call.

For the pre-action flow, API success should map to "EditPreparationTime", with one extra value calculated locally. For the post-action flow, API success should map back to "AdjustPreparationTime" with updated values.

Should the ViewModel keep track of the current flow before emitting "Loading", so it knows whether API success should map to "EditPreparationTime" or "AdjustPreparationTime"?

Or is it better to avoid a shared loading state and use more explicit states, for example "CalculatingEditPreparationTime" and "RecalculatingAdjustedPreparationTime", so the next state is clear from the state itself?

Has anyone implemented something similar? I'd appreciate any guidance on whether this is an idiomatic way to model this in MVI/UDF while still keeping a single active sealed UI state.

I'd love to hear about what people are doing. I've been working solo for a while and I miss the conversation with other coders. It is a weird and exciting time to be working on code, am I right?

Hello, I have a question. I did a fullstack course but I didn’t like it, not my thing. My neighbour is working dev using kotlin, said it’s cool. I want to try smth new, but I want to get a job that I at least 50% will like

So if it’s popular and needed where can I learn it fast and good?

Our prod backend — Spring + Hibernate — had a ~25s cold start, on a system that scales out during traffic spikes. So a slow boot wasn't slow, it was user-visible downtime. In an R&D spike I built the same service on Kotlin Multiplatform: ~3s cold start on the JVM, under 0.3s compiled to Kotlin/Native — same code, two targets. That gap is why I think the whole JVM-startup arms race — CRaC, Leyden, GraalVM — is solving the wrong problem. I hit a wall worth arguing about.

To kill the obvious misread: I did not port that prod backend to native — it runs on the JVM and always will. The KMP build was a separate spike; it matured into something we could have shipped, then the company shrank and it never ran in prod.

We didn't skip the JVM's own startup playbook — GraalVM got the most serious look, and it's good tech that just didn't fit us: closed-world reflection config (even Ktor needs the CIO engine plus a JSON file from the tracing agent), AOT trading away the JIT on a workload that stays warm long enough to want it, heavy CI.

The main point. We've decided the fix for "the VM starts slowly" is an arms race to make the VM start fast. At some point it starts to feel like we'd rather rebuild the VM as a native compiler than admit the VM itself is the startup tax. Native doesn't pay that tax in the first place — that 0.3s boot, one binary, tiny footprint, nothing to install on the host. And 3s isn't "fine" here. When you scale to zero and back on a spike, cold start is on the request path, not hidden in a startup log. Even a tuned 3s is latency a user eats; 0.3s makes it disappear. That's not a tuning win — it removes the problem.

Then the wall: no JDBC on Native — and there can't be, JDBC is a JVM standard, which means no mature ORM on top of it either. Grown-up native ecosystems solved this by reimplementing the Postgres wire protocol in their own language: Go has pgx, Rust has sqlx / tokio-postgres, no libpq. Kotlin/Native has almost none of that, so I bound libpq through cinterop to get something working. That was where I stopped looking for an ORM and accidentally started writing one. I kept solving the next missing piece until I had a full data layer. That project eventually became Kormium. I'll leave the link in the comments for anyone who's curious.

Concurrency is where I expect hits. On the JVM the answer is Loom: block on a JDBC call, the carrier thread parks cheaply, your ceiling is the connection pool. Native has no Loom, but libpq has an async API, so you can drive it off a poll-based socket reactor and get genuinely non-blocking suspend with no VM underneath.

No flag-waving: I'm not claiming native is faster. Rust handles load better, a warm JIT beats AOT on sustained throughput. Native wins on startup, footprint, and not shipping a VM. K/N's realistic ceiling is Go's niche, not Rust's.

Here's the take I want proven wrong: Kotlin/Native isn't adopted on the backend because backend performance still isn't compelling enough → nobody builds the ecosystem (the missing data layer is the hole I fell into) → no pressure on JetBrains → performance doesn't improve → nobody adopts it. The root is performance, the rest is symptoms.

So — tell me where I'm wrong. Do CRaC/GraalVM genuinely close the gap, making native on the server unnecessary? Or is the direction right and JetBrains just digging in the wrong place? And if you've run K/N (or Go/Rust) on a backend, tell me where it broke — that's the data we're all missing.

Magic has over 28,000 unique cards and one of the most notoriously complex rules systems in games. I've been building an engine that implements it properly.

The core is a pure function: (GameState, GameAction) -> (GameState, List<GameEvent>). State is fully immutable, modeled as an ECS. There's no card-specific logic in the engine at all — the hard machinery (the 613 layer system, the stack, priority, replacement effects, state-based actions) lives in one place, and cards are pure data defined through a Kotlin DSL.

The whole thing is built as four layers, each with a strict responsibility:

- SDK — the data contract. Cards, effects, targets, and dynamic values are all pure, serializable data structures — no execute(), no lambdas. A dynamic value like Tarmogoyf's power is an AST node (DynamicAmount), not a (GameState) -> Int, so it can be serialized, inspected for UI text, and lazily evaluated. This layer defines what happens.
- Rules engine — the functional core. A zero-dependency Kotlin library (no Spring, no I/O) that interprets that data. Immutable GameState, ECS entities, and — because it can't block a thread waiting on network input mid-resolution — reentrant, serializable continuations: when a spell needs a choice ("search your library"), it pauses, pushes a continuation frame, and resumes when the answer arrives. This layer defines how.
- Game server — thin Spring Boot orchestration with zero game logic. It routes WebSocket messages, manages sessions, and does server-side state masking (fog of war) so a modified client can't read your opponent's hand. It's an anti-corruption layer: the engine's GameState never leaves the server, only client-safe DTOs.
- Web client — a dumb terminal. No game rules, no legal-action computation. It renders what the server sends and captures intent; the server is authoritative for everything.

The payoff of the layering: the engine is a pure library, so it's exhaustively testable without a server, and it's portable — the same engine also powers a Gymnasium-style RL/MCTS wrapper for agent research, with no server or browser involved.

It's playable at magic.wingedsheep.com — booster draft tournaments, multiplayer, up to 6-player free-for-all.

Most of it was written with Claude Code under a strict architecture I kept it to. Source and a writeup below

Repo: https://github.com/wingedsheep/argentum-engine
Writeup: https://wingedsheep.com/building-argentum-a-magic-the-gathering-rules-engine/
Discord Channel: https://discord.com/invite/dy6eSRPWzu

I wrote a technical deep dive about how we migrated one of Denmark's most used Android apps with one million lines of code powered by Java threads, into Kotlin coroutines just by rewriting three files in our internal threading library

Check it out if you are interested in how coroutines use threads, and interop between them :)