Comment by bad_user | Hacker News Reader

Comment by bad_user | Hacker News Reader

Parent Full thread

The latest Kotlin can target WasmGC. WasmGC became enabled by default, quite recently, in both Chrome and Firefox:

https://developer.chrome.com/blog/wasmgc/

Kotlin's support is in Alpha right now, but works well, and it's one of the first language implementations that can target WasmGC:

https://blog.jetbrains.com/kotlin/2023/12/kotlin-for-webasse...

By comparison, .NET's Blazor targets LLVM, and they either AOT or JIT, however the client has to download a heavier runtime that has at least a garbage collector (nevermind the JIT), and is less than ideal. Basically, the original Wasm was designed for languages with linear memory and still makes a great target for C++ or Rust, but not for managed languages like Kotlin/Java. dotNET's WASM is there only to support Blazor, which is a web framework, a sort of successor to Web Forms and whose future is uncertain. Speaking of which, you're better off with MVC + HTMX, but I digress. So for more interesting use cases, Kotlin is actually ahead in their Wasm support.

For multi-platform support, the company behind it has a vested interest in targeting multiple platforms, and Kotlin Multi-platform support also has Google backing. So, for one, you can share business logic on iOS, as you can integrate Kotlin libraries into Swift applications:

https://kotlinlang.org/docs/multiplatform.html

And they have been porting Jetpack Compose to the desktop and to iOS (and can be used with Wasm in the browser, too):

https://github.com/JetBrains/compose-multiplatform

Also, see this year's keynote at KotlinConf:

https://www.youtube.com/watch?v=c4f4SCEYA5Q&t=2903s

Over on dotNET side, the blessed solution by Microsoft, for targeting iOS, Android, or the desktop, is right now .NET MAUI. So, where's Xamarin? Where's Silverlight for that matter? That's right, Microsoft changes multi-platform solutions like they change socks, and I don't understand how anyone could trust them for a multi-platform solution.

WasmGC is a prototype that only supports the bare minimum that is enough for languages with high level constructs only but not for something like C# which has interior object pointers (ref) and uses them heavily for performance (spans are built on top of them).

The API of WasmGC is really rudimentary.

With that said, you can track support of various WASM features by .NET here: https://github.com/dotnet/runtime/issues/94351

I don’t understand how the logic of your post works however, WASM in .NET is already used in production versus something that is an early alpha? Also, on Kotlin and targeting something that is not Android - “Java Interop” that’s all I need to say.

What’s wrong with Java interop?

Kotlin is really only relevant for Android, and because Google says so.

And even in spite of that, they had to backtrack on leaving Java behind, as Android was slowly not able to consume modern Java libraries.

Kotlin on the browser lags behind Blazor, and Kotlin/Native was so badly implemented they had to redo the whole memory management concept, originally incompatible with JVM semantics.

Kotlin is used in many places where Java is or could be used. Some teams prefer Kotlin over Java for new Spring or Quarkus or Vert.x or Micronaut projects. Kotlin is relevant everywhere outside Google’s realm, too.

I’m unaware of that backtracking you’re mentioning, could you give some context?

How do you measure it lagging behind in the browser? According to Krause’s benchmarks Blazor’s WASM performance is steadily in the bottom 5% of tested frameworks, and devs generally tend to express that Blazor is suitable only for internal enterprise apps where the end users are lenient enough to accept such performance.

The limited GC in the initial Native implementation was reworked long time ago.[1]

[1]: https://kotlinlang.org/docs/whatsnew17.html#kotlin-native

Seems strong to say .net is mostly showmanship... when your main contention is another framework has alpha support for a different GC.

MAUI is rebranded Forms and while MS is pushing it, it's by far the only way to build an Android UI. You can build it natively, sort of like since the beginning. While still supported, Xamarin transitioned quite nicely into .NET where can take all of the advantages. And you get a good reply about WasmGC in the other post. Also .NET is ahead when it comes to cross platform UI compared to Kotlin - there are libraries such as Avalonia, Uno and others. And so on and so forth.

In my experience Uno and Avalonia UI are quite experimental still. And I totally dislike their looks. I spoke to Mike on the topic of theming, hope they introduce something more modern. To be fair, Avalonia UI is only becoming multiplatform.

Uno has been very unstable, not production ready in my books.

As for Kotlin, it’s just a language running on a JVM or any other supported target. The interop with Java is stellar. You can use Swing or JavaFX, which now goes by OpenFX, for the desktop. Vaadin and Hilla target V8. There’s also Kotlin/js. There’s really a lot. Compose is much like SwiftUI, composable, similar to React in a way.

How have I missed Uno! I was familiar with Avalonia, but first time hearing about Uno. I'd love to see more UI frameworks for .NET that also work on Linux.

it's by far the only way to build an Android UI

far from the only way! (as you explain).

Duh, yes, typo, thanks.

Reply on news.ycombinator.com