Kotlin really is good and definitely an improvement over Java, but in my experience (like ~1 year) the language itself makes writing unreadable code too easy; it also doesn't help that IDEs like IntelliJ Idea often suggest shorter yet less readable alternatives because it's "idiomatic" Kotlin code. For perspectice, I am writing "enterprise software" and I am big fan of TypeScript.
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 can't give specific examples, but something along the lines of suggesting to replace an early return in the form of `if (…)` by something like `… ?:return`. The former alternative makes it way easier to spot on first glance where the functions bails out. The latter hides it in an assignment making it harder to see.
I should say, though, that I am by no means an expert Kotlin developer; maybe I just have to get used to idiomatic Kotlin.
Don't take idiomatic Kotlin too seriously. It's not Go where there's exactly one allowed way to do things. IntelliJ's suggestions go both ways - you can convert to short form and also back to long form automatically. It's that way for a reason: you're trusted to pick the right form on your own.
I'd agree in general, but that hardly works for larger teams or even multiple teams. This can probably be solved by a good linting tool, but I am not too familiar with the state of linting in Kotlin.
The best linter for Kotlin is the IntelliJ inspector, which is very powerful. You can run inspections from CI builds using TeamCity, at least, probably other CI builds. You may also configure project defaults to trigger various patterns as warnings or errors.
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.
Agree Kotlin gives a developer definitely more rope to hang himself with than Java, and not all IntelliJ suggestions are really "improvements". Biggest danger is, as always, being too clever and/or being a purist.
I find most intellij suggestions to be quite sensible. It basically teaches you idiomatic kotlin. I'd suggest not fighting the tools and letting them guide you.
As for typescript, it's a nice step up from javascript but IMHO more of a gateway drug to other languages (like Kotlin).
TypeScript really hits the sweet spot for me. A good type system (real union types, which Kotlin lacks), barely any special syntax to remember but still powerful enough. I do want nominal typing sometimes, though.
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).
For us particular, we heavily rely on fat frameworks like Spring (and sometimes Java EE) and there is nothing like that in TypeScript/JavaScript world. It boils down to not having classpath scanning, reflection and annotations in TypeScript, I guess. I don't want to defend these frameworks, though, they certaintly have their flaws, but it is what we use and it is often also what is teached in Germany.
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).
last time I was working in Typescript (a year) ago, the date/time libraries were still disappointing and precision math libraries were very way too cumbersome. Both are well solved problems on the JVM and in other languages.
as somebody who has written a lot of java and kotlin, often I prefer the most explicit option.
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.
