simon_void

at the (semi-state owned) company (in Germany) I work at, Kotlin is a first-class language also for backend. It depends on the teams wheather they prefer Java or Kotlin. I'm firmly in the team-Kotlin camp and Java code that becomes my responsibility has the strong tendency to suddenly become Kotlin code. By the way, I never worked on Android, so all my Kotlin work (since 2019) was server-side Kotlin.

Java is getting better, so maybe in 10 years it'll be a less ergonomic Kotlin variant.

PS: Jetbrains - the company behind Kotlin - started a strategic partnership with the Spring team, to make the combo Kotlin-Spring even better: https://blog.jetbrains.com/kotlin/2025/05/strategic-partners...

PSS: Jetbrains is actually working on an official Kotlin-lsp server: https://github.com/Kotlin/kotlin-lsp So devs in the near future won't be locked into the IntelliJ ecosystem, if that is a concern of yours.

check out Borgo https://github.com/borgo-lang/borgo It is Go with algebraic datatypes!

true, it's just that the topic of this post seemed strange to me, since you wouldn't use a programming language with GC for high intensity graphics app in native either, hmmm.

so what about realtime graphics with wasm without GC? (compiled from languages not needing a GC like Rust, C/C++, Odin, ...)

I'm actually in team no-ternary operator in Kotlin, simply because there shouldn't be two ways of doing the same thing. Maybe the problem is a linter issue: for me the main point of the ternary operator to have a very concise expression, a one-liner. But maybe our linters warn when a) we use if-else without braces and b) we put everything on the same line!?? Btw there is already another way to write the ternary operator in Kotlin (assuming the positive-case value of expression X is non-nullable): "C ? X : Y" -> "X.takeIf { C } ?: Y" https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/take-if... Though I admit, I've never used this version either.

Kotlin backend dev of 7 years here (never done Android). Here my 50 cents to some of the "bad" points: 1) tenary operator. Apart from the "if-else is an expression" defence there's also the fact the in Kotlin the '?' is linked to nullability, not only conceptually but also in regards to parsing Kotlin code. There's a video on youtube where the first Kotlin language designer said that he once - because so many people were asking for it - actually sat down and tried to my the "a ? b : c" syntax work, but couldn't because of ambiguity (I think the issue was interaction with nullability operators, but I could be wrong). 2) return inside lambda. There is actually an option that allows for normal returns, but it's not very idiomatic (to a degree where I myself forgot that this option exists until a few months ago) and that is to instead of providing a lambda as a parameter, you can always provide an anonymous function instead (https://kotlinlang.org/docs/lambdas.html#anonymous-functions). In anonymous functions a return works like you're used to, but but the whole code gets more verbose. Here's an example: https://pl.kotl.in/4NQ4lMasf 3) Destructuring is worthless without naming. I visited the KotlinConf2024 and in one talk they said there are going to fix this (Kotlin 2.3??), probably in this one https://www.youtube.com/watch?v=tAGJ5zJXJ7w&list=PLlFc5cFwUn... 4) Coroutines. If I'm writing a Spring app, I (generally) don't use those as well. The exception was an reactive Spring with Webflux app that I converted from Java to Kotlin where the native coroutines constructs were just nicer (and more secure thanks to structured programming) than using Mono/Flux (see https://www.baeldung.com/kotlin/spring-webflux-kotlin). But I use Ktor in several of my newer apps and there coroutines are the only option. I admit that I struggled for a long time with coroutines. I read a tutorial or official documentation here and there, got the gist of it, but things got fuzzy soon enough. But I want to recommend the 3rd chapter of the 2nd edition of "Kotlin in Action". This is the best description of coroutines I've ever read and I finally got the feeling that I understood the whole thing! https://www.manning.com/books/kotlin-in-action-second-editio...

To complete the completion of the TL;DR : the 95% safe Rust Code using auto vectorization is even slightly faster than the C code.

> Rust takes longer to write than C

> but spent basically zero time debugging

that's the difference to rewriting it in C

> What JVM do I use?

latest LTS (longterm-support) version, so currently 21, next 25 (late 2025).

> Does it matter?

new is always better

> what if I have to install/manage multiple versions?

https://sdkman.io/

> If I want to write a web service can I use vanilla Java stdlib or do I have to use Spring or some framework?

Spring

> If I use Spring, do I have to get into the weeds of dependency injection

yes, but it's not hard (or I've done it long enough)

> other complexity

that might just be inherent complexity when have to deal with a webservice. personally I dislike have to configure security

So basically go to Spring Initializr (https://start.spring.io/) pick the latest LTS Java&Maven (or Kotlin&Gradle-Kotlin) and You're off to the races.

Silence will fall when the question is asked

you failed to mention that Kotlin has platform types only if it's interoperates with Java. Platform types are for objects that come over from Java code (and therefore have unspecified nullability (assuming the Java code doesn't use nullability annotations)). Admittedly you provided a link that explains this, but how many people will follow the link? And yes, this detail feels kind of important. And yes, future Java (and Kotlin) will only have their version of platform types to interop with old Java code.

As a long-time Kotlin user I can only say: Nullability is nice! Once you know it, you won't want to code without it.

a) if every C program could be translated into an equivalent safe Rust program, that would mean that each C program is as safe as the safe Rust equivalent. b) since there are C programs that are open to memory currption in a way safe Rust isn't, this corruptability would need to be translated into partially unsafe Rust. Congrats, you now have a corruptible Rust program, what's the point again?? c) so DARPA must be trying to fix/change what the program is doing when switching to Rust. So how to discern what behaviour is intended and which is not? Doesn't this run directly into the undecidability/uncomputability of the halting problem!?!

you could use the Zig build system as your C build system. See https://zig.news/kristoff/make-zig-your-c-c-build-system-28g...

As far as I know Gleam is the only strongly typed language on BEAM, which is important to me since I don't like dynamically typed languages. But of course Elixir gets optional types now.

- Backends: Kotlin (on JVM)

- Web frontend: TypeScript (maybe Gleam in the future!?)

- Fast performance and iteration if I want a binary: Kotlin (native compiled)

- Blazingly fast and good for WASM: Rust

- languages that I keep an eye on: Gleam, Zig, Odin

- languages that I will never touch: C, C++

- languages that I think are quaint: OCamel, Lisp, Haskel

- languages that I have used in the past and that are fine: Dart

- languages that I have used in the past and that are ok: Java (if it had nullability, it'd be fine)

I prefer Kotlin over Java as well. I use it at work (where Java code has a tendency to become Kotlin code if it comes close to me) and at home. I'm looking forward to seeing how the native and wasm backends might extends the reach of Kotlin in the future.

Kotlin has type inference and smart-casting, which i guess is what you mean!?

Garbage Collections destroys any real-time guarantees you might need, since the GC can be triggered at any time. So for some classes of applications a GC is not an option (e.g. in 3D-video games you don't want your rendered frames per second to drop under 60 frames per second).

you can use Kotlin in a Maven project as well (configuration here: https://void2unit.onrender.com/post/multimodule-maven-java-k...) or maybe your request is what triggered Jetbrains to develop Amper (https://blog.jetbrains.com/amper/)

not sure what "(non)-isomorphic" but Kotlin code is interoperable with Java code in both directions. You can easily call Java-code from Kotlin (but I guess that's the easy direction) but you can also call Kotlin code from Java. There exist specific annotations to control how Kotlin code will be converted to bytecode and therefore be invoked from Java, e.g. a function in a Kotlin companion object would normally concerted into a function of a Singleton property called INSTANCE on the base class, but if you annotate it with @JvmStatic it will become a static method of that class in bytecode instead. This means you can write a Kotlin lib that feels very normal to call from Java. here's the relevant part of the documentation: https://kotlinlang.org/docs/java-to-kotlin-interop.html So yes, Kotlin is considered to be a successor language, not just another language (also) compiling to the JVM.

I thought exactly the same (lack of self-awareness), only instead of "lack the capability" I though "lack of time". Not every distro has to support old hardware (since the maintainers have limited time to work on it themselves, or whatever other reason they choose), I'm sure there are distros around that do.

maybe OP doen't know about #![no_std] !? You can not (as far as I know) have the Rust std lib as a dll, but you can chose to not use/include the std lib: https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/sh...

check out Inko https://inko-lang.org/

compiling JS to wasm won't make it faster (the things that make it slow are implicitly compiled as well). (typed) TS should be faster, since it provides more guarantees. There is actually a variant of TS which is meant to be compiled to (browser-)wasm: AssemblyScript. And yes, wasm is still closed to being a minimal viable product. But getting adding WasmGC and WASI are big steps (I'm mostly working with Kotlin on the backend, so server-side wasm is more interesting to me then browser-side). Component Model and DOM-support will indeed take some more time.

I'm pretty sure it boils down to JS can be fast (after all the ASM.js subset of JS is what started WASM), WASM is fast... and also more compact, so smaller filesizes which means faster downloads. There are probably other advantages as well (like reliable performance, even if you have fast JS, you don't know which code changes code throw you of the hot path and make your JS slower)

here is the talk by Roman Elizarov, the Kotlin project lead, at KotlinConf 2023 about Coroutines vs VThreads: https://www.youtube.com/watch?v=zluKcazgkV4 short version: both were optimized for different things, so there is a place for both of them.

So I'm pretty sure they're doing something similar to Ferrous systems, since they worked together with them until very recently, Qualifying Rust without forking: https://ferrous-systems.com/blog/qualifying-rust-without-for...

short version: Clang is only removed from the main zig executable, but it's still available via the zig build system.

longer version: I think this is the relevant link here: https://github.com/ziglang/zig/issues/16270#issuecomment-161...

as you can see the proposal "make the main zig executable no longer depend on LLVM, LLD, and Clang libraries" has "accepted" status, but that doesn't mean you can't use Clang/LLVM/LLD to compile zig/C/C++ via the zig command. In the comment the link goes directly to Andrew explains that the usecases that require Clang ... are still covered by the zig build system. (Everybody was very worried first in that GitHub issue, but was relieved after reading the clarification. To be fair, that the build system could take over this functionality wasn't known from the start, so it was a very productive discussion.)

is Grain still actively developed? The latest release and update in their blog was from June 2022.

check all the options under "The Guide" https://grain-lang.org/docs/guide/basics