I've been in a few conservative backend projects in the last year where they were stubbornly insisting on Java. I've managed to convince a few on a path to Kotlin.
For those not familiar with the situation. With Spring 5 & Spring Boot 2, Spring started supporting Kotlin properly (i.e. 2 years ago). It worked fine before that but now Spring comes bundled with a lot of Kotlin extension functions that bridge the gap to idiomatic Kotlin. E.g. all the reactive stuff that Spring has you can (and IMHO should as it simplifies things a lot) do using kotlin co-routines. Things like Flows, suspend functions, etc. all just work seamlessly with Spring's Flux.
Also the documentation is now updated with kotlin code examples and increasingly it seems a lot of features are more Kotlin than Java centric.
If you don't need Spring, Ktor is emerging as a nice lightweight alternative. It's more of a express.js/ sinatra style framework. You can actually use Spring in a similar way with the bundled Kotlin router DSL but not everybody does that.
As for typescript, it's a nice step up from javascript but IMHO more of a gateway drug to other languages (like Kotlin).
Although I must admit that I wouldn't use TypeScript in the backend for the projects we work one (but I do for my personal projects).
Can u elaborate on that? Why is TypeScript not suited for some projects?
We also follow a domain-driven design approach for which we not yet have found a good way to implement in TypeScript (at least not on the "tactical" level).
Edit: Also, people don't grok asynchronicity ;)
What do you mean exactly? I feel like Kotlin's brevity is what actually makes it a lot more readable than Java. With Java there's just often so much noise and fluff that doesn't actually mean much, obscuring what the program actually does. Could just be my personal preference, but I feel like in general I have an easier time understanding terse, dense code rather than spacious, verbose code.
I should say, though, that I am by no means an expert Kotlin developer; maybe I just have to get used to idiomatic Kotlin.
Even better, in the latest IntelliJ you can create new inspections from structural search, which is an AST based matching system. So you have a lot of flexibility to make your own lints and warnings without needing to write plugins.
However, I think there's a more general issue here, which is that if you don't trust your team to write tasteful code, linters will be of limited use. It may be better to invest in more rigorous code reviews, trainings, style guidance, mentoring etc. I've spent five years managing technical teams using Kotlin (yep, early adopter!) and found most of them could handle it just fine. A little training goes a long way. The worst problems came from developers creating overly complex abstractions, not playing code golf.
Developers look at their freshly written code, marvel at how succinct it is and then pat themselves on the back for being so clever. "It's just one line and I read it. Boom! Readable!". A few months later, another developer comes to look at the code and has to spend 10x more time parsing each character in that statement before they can even understand the logic behind it.
Brevity might be a kind of "vanity metric" when it comes readability.
Code will be mostly read, not written, so if something will make a junior (or in some cases even seasoned) dev scratch their head to be understood, it is best avoided.
EG Often I prefer writing an "if != null else" instead of chaining takeIf{}s.
I love those porting back to Java projects after the pixie dust fades away.