Late last year we had some major instability with our main microservices as they didn't properly scale and it wasn't pleasant. The backend codebase was Java. In any case 2 months before that we got a dev with good Kotlin experience (he wrote a book on it) and he offered to rewrite those services in Kotlin as that instability was occurring. It took him about 5 days for each (sometimes less). And in a few weeks we had services which were rock solid. Amazing really how sometimes a person who knows his stuff can make a difference.

How does Kotlin "scale" differently than Java? I mean I'm anything but a Java fan but both languages run on the JVM, so unless your colleague also changed the architecture of those services I don't see how a switch from Java to Kotlin would help at all.

My guess he implemented those using Kotlin Coroutines to build much more scalable and more thread safe implementations. Concepts it offers like Structured concurrency are really powerful.

True, Coroutines were very heavily used. It was kind of magical how services which nobody wanted to touch with a 10 ft pole due to their complexity for almost years got rewritten in mere days or weeks at most. Those big microservices were broken down to even smaller microservices.

Kotlin makes it easy to avoid the "billion dollar mistake" i.e. using null.

That has nothing to do with scale.

Quite honestly though, I don’t see null as that big of a deal. I haven’t struggled with it since I began programming 10 years ago.

A big study by Microsoft (IIRC) said that ~70% of bugs came from NPEs.

That is interesting. I'm not against compiler enforced null checking, but it's not the killer feature that would convince me to switch to Kotlin from Java.

Your mileage may vary, but for me it's crucial—I can't use a language in production that doesn't have null safety. I want the compiler to force me to consider edge cases, and in many languages the biggest edge case of all is "that value you thought was there isn't actually there".

Sounds in this case attracted a better programmer.

Did he report the issues back to the Kotlin JS team? My experience is that they are quick to respond in Kotlin Slack.

We use it in production and saves us quite some time sharing code with the backend.

I can imagine Kotlin JS takes some effort since it improved a lot but also changed quite a bit throughout the years. Kotlin Slack helped me a lot through this phase.

No idea. I think the demo schedule drove him to find something that he could get working.

To be fair, I think he was fighting not just Kotlin JS but using React within it and his own lack of web technology experience being predominantly an Android dev.

Seb from Kotlin at JetBrains here; if your lead dev would like to help us improve the experience, feel free to reach out via the email in my profile. We are always keen to learn what obstacles are facing in their adoption of Kotlin/JS, and what we can do to help.

Yeah I don't think you are going to get far with React + Kotlin/JS if you haven't used React before.

Maybe he could try again with Jetpack Compose for JS? Then he can use his Android knowledge for the UI and there is less complications with bridging Kotlin code in JS/typescript. To be fair though, Jetpack compose for web is quite new so there is not yet a big ecosystem.