simon_void

less is more, I just want the plain old search experience I've had for 25 years so I stated paying for Kagi around a year ago. (Before that I used DuckDuckGo which still seems fine. They seem to also offer AI now, but it's not obnoxious like on Google.)

Is the inclusion of synchronous interfaces a new thing? When I learned actix_web 2-3 years ago for some webservices at work, the documentation surely (at least) started of with async functions everywhere. Did that change? Were synchronous interfaces introduced later in the actix_web documentation? Or did everybody switch over to axum in the meantime and axum has synchrounous interfaces!? (I just checked and according to crates.io axum seems to have 8x the recent downloads of actix_web.) background: actix_web is still the only Rust webframework I have experience with

nobody trusts AI agents, that's why they are put in a harness. It's just that I additionally belong to the people who don't trust AI agents to always adhere to harnesses either.

true, but you'd be wrong to assume that Germans only compound words if both parts are nouns, e.g. "Gehweg" (walk way) and "Springseil" (jump rope) use the base of a verb. We do actually have "Kochwasser" ("kochen" means "to cook", "kochend" means "boiling") but that's not boiling water ("kochendes Wasser") but for water used for cooking.

not anything. As a German I see no way to compound "boiling water". It remains two words: "kochendes Wasser".

thank you for the link to the talk! I actually witnessed the talk live, but must have completely missed this or simply forgot that this was answered :D

Rich Errors look promising to me, but what about interop with Java? What will the return-type of a function be on the Java side be, if the return type on Kotlin side is: Int | ParseError | SomeOtherError?

Background: unions aren't restricted to one normal type and one error type, but to one normal type and any number of error types, so this can't be modelled as syntactic sugar on top of an implicit Either/Result type, can it??

technically, Kotlin can use VirtualThreads like it can use any other Java Api (when being compiled to JVM bytecode).[1] If I remember correctly the Kotlin team was e.g. thinking about implementing a Coroutine Dispatcher with VirtualThreads. So building a Kotlin service that uses Virtual Threads instead of coroutines is -in principle- possible. But if you've got a Java project using Virtual Threads you could rewrite it slowly -class for class- to Kotlin (and later probably refactor the VirtualThreads to coroutines). What you have to keep in mind though: if you're creating a Kotlin lib that is meant to be used by Java then the public Api of this lib should include suspend functions! My company made that mistake at some point, they ordered a lib from an external supplier and since Java and Kotlin are both first class languages and "Kotlin is compatible with Java", they ordered this lib in Kotlin. They learned the hard way that Kotlin suspend methods translate to Java methods returning a Continuation class (!? If I remember correctly. I wasn't part of that project, but heard their story) which is very unergonomic to use manually. The fix was to write a small Kotlin shim lib that wrapped the other lib and replaced every suspend function with a normal function invoking their suspend counterpart in a runBlocking-block (I think). Hardly ideal, but workable. So yes, writing a Kotlin lib that's (also) meant to be consumed from Java requires more thought than one that is only meant to be used by Kotlin. (There is functionality in Kotlin to help with this though, e.g. look up the annotations @JvmStatic, @JvmName, @JvmRecord.)

[1] https://void2unit.onrender.com/post/virtualthreads-in-kotlin...

I really like languages with non-/nullable types like Kotlin and Rust! I used to work with Java for over a decade and therefore used to code very defensively against NullPointerException and now (with Kotlin) I just don't have to do this anymore. That being said there are two possible sources of nullpointers: from inside your program or from outside (e.g. the json your server got send wasn't fully initialized). The majority of NullPointers come from outside in my experience. Nullpointers from within you have to fix mostly once. but there's no end to what data send to you from outside your control can be missing. Of course you still have to validate/parse outside data when using Kotlin but since the type system then carries on which data has been validated, you can drop the defensive mindset that was appropriate in Java.

So if you have a self-contained, non-safety critical project and want to use/try out an arena-allocated memory approach using Odin seems fine (e.g. looking at you: "raytracing in a weekend").

So yeah, I think there's a niche of projects where the possibility of null pointers isn't a huge deal.

None of my work-related projects fall in that category though :D

I agree, i started with (scope) blocks in Rust, but keep the habit in Kotlin win the run - scope-function. Since run takes no arguments, it feels like the closest equivalent to Rust scopes (compared to other Korlin scope functions, which also keep their local variables from polluting the rest of the function body).

a Corridor Crew YouTube video describing/recreating that sodium vapour process: https://www.youtube.com/watch?v=UQuIVsNzqDk

this is exactly about what is legal or not. If I remember correctly in Germany there's a distinction about people being the focus of a photograph or people in the background. You can e.g. publish a picture of a public place without asking everybody on that place for their consent. Another corner case would be filming police brutality. What if the police officers in question wouldn't like to be photographed being brutal!? Local laws do apply.

I works very well, thank you for asking: https://rustwasm.github.io/book/

Kotlin! personal disclosure: I'm a Kotlin fan boy. (If performance is important then Rust, but Kotlin is more ergonomic.)

In a worlde where kotlin exists, I still have not seen any reason to consider java XD

there are two ways to achieve native binaries with Kotlin: 1) Kotlin native https://kotlinlang.org/docs/native-overview.html 2) Kotlin JVM but use GraalVM https://www.graalvm.org/ (which creates a binary of your program combined with GraalVM)

I like Rust as much as the next guy, but Kotlin is the most ergonomic programming language I know. So my approach is to use Kotlin by default and should it some day become clear that the service is a bottleneck (or if the cloud cost can be lowered substancially), to only then rewrite it in Rust. At that point the service has probably already gained most of the functionality it'll ever have, which should make the Rust conversion as straight-forward as it can be.

I wonder if that confusion is due to the fact that you haven't yet wrapped your head around the fact that extension functions are "just" syntactic sugar for static functions. The implicit "this" becomes the the first parameter of the static function and function parameters can be null. Now you might ask "why not use static (/first class) functions then? Because those "feel" like less ideomatic to use then extension functions or methods that are defined on the object (hirachy) itself. But understanding why the extension type can be nullable is not the same is using it on nullable types. I restrict my extension functions to non-nullable types most of the time as well. The best exception to this preference -just to see where it makes sense- is the build-in function [toString](https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/to-stri...), since you want it to return "null" if you invoke it on null.

Jetbrains is working on an LSP: https://github.com/Kotlin/kotlin-lsp It was announced at KotlinConf 2025.

I know one of these developers as well! It's me :D

this will change, Jetbrains is working on a Kotlin-LSP, just don't expect it to be done anytime soon: https://github.com/Kotlin/kotlin-lsp

i've used ktor for 2 small-ish microservices. It's fine. I was curious about corouitnes. I know SpringBoot has support for corouitnes as well, but in ktor it's front and center. (Disclaimer: I never used Scala)

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