We have no plans to support LSP at this time. Instead, we’re focusing on providing the best possible Kotlin development experience in our own IDE, IntelliJ IDEA.
While I understand JetBrains’ motivation and I really like where language is going (I actually really want to try their new Compose for Desktop project) there might be some tensions when introducing the language. In fact I have recently removed a few Kotlin classes from our Java project to speed up build times and remove a lot of pain for me (I work in Emacs and use Eclipse’s language server for Java which knows nothing about Kotlin classes).
As for the null safety example I guess it is is a common practice to use java.util.Optional nowadays:
int subLength = 0;
if (obj != null) {
if (obj.subObj != null) {
subLenth = obj.subObj.length();
}
}
could be written as
int subLength = Optional.ofNullable(obj).map(o -> o.subObj)
.map(s -> s.length).orElse(0);
Obviously, it is not as short as in Kotlin but a huge improvement over if/else nesting.
Still less concise than the Kotlin example but (to me, totally subjective) clearer than the Optional call chain and doesn’t require instantiating a series of intermediate objects.
You can do the null checking in a less concise way in Java, but it becomes a pain for highly nested types from third party libraries. Additionally, having the optional types in Kotlin make it really easy to enforce when something might be null vs will never be with syntax that’s shorter than Java. I know Java has @Nullable and @NotNull, but I never got it to enforce the checks as easily as Kotlin. If you are working a big project and you don’t have a standard way to determine if something is nullable or not, you end up with null checks everywhere for safety, which is a pain. For new developers to Kotlin you can just tell them not to use !! in production code, and then you don’t get NPEs.
There are other languages that have nicer optionals, but I think Kotlin does a good job while still working well with existing JVM libraries written in Java.
I’ve been going through a similar thought process lately regarding software stacks. I’m unhappy with Go as a language, and I’d never willingly use JavaScript on the server. I still think Django is the safest bet for a wide class of software. As we see with Doordash, Python 2 and old Django got them very far. Afaik companies like Pinterest and Instagram still make heavy use of Django?
However, given their heavy (and IMO, warranted!) emphasis on a REPL in their comparison table, I’m surprised they didn’t give a look to Phoenix/Elixir. It provides an experience similar to Django where you can open your app in the REPL and poke at everything, but it’ll scale to all your cores, and LiveView is truly a game-changer.
However, given their heavy (and IMO, warranted!) emphasis on a REPL in their comparison table, I’m surprised they didn’t give a look to Phoenix/Elixir.
It’s probably because there aren’t as many elixir developers. They mention headcount as a disqualifying feature. From the article:
We discarded major languages, including C++, Ruby, PHP, and Scala, that would not support growth in queries per second (QPS) and headcount.
This might be off-topic, but do you mind sharing why you are unhappy with Go? I was going to start some new personal projects in Go rather than Python (as a learning experience), and I’d be interested in knowing some of the possible downsides.
I encourage you to learn Go. There’s not much to it. It’s fine if you think it is. To me it feels bad to program in, given its limited facilities for abstraction and error handling. “Everything is a loop” makes simple algorithms feel complicated, and having error returns but no Result type or sugar syntax (like in Rust or Zig) for bubbling up errors is the worst of all error-handling worlds.
There are a lot of things to like about it, but I find it fatiguing to read. I think it’s somewhat unique in that it is a higher-level language in terms of its runtime (GC, M:N threading, channels) but sticks to these lower-level imperative control flow aesthetics. I’m sure there was some reason for this aside from the aesthetic preferences of Pike and peers. Maybe generics will allow for a more idiomatic use of FP.
Import note: They migrated away from Python 2
TLDR: Kotlin is nice but the fact that you can have a full dev environment only in IntelliJ makes it hard to adopt in the teams.
There is an independent Kotlin language server but the repository says right off the bat:
As for JetBrains position on the topic:
While I understand JetBrains’ motivation and I really like where language is going (I actually really want to try their new Compose for Desktop project) there might be some tensions when introducing the language. In fact I have recently removed a few Kotlin classes from our Java project to speed up build times and remove a lot of pain for me (I work in Emacs and use Eclipse’s language server for Java which knows nothing about Kotlin classes).
As for the null safety example I guess it is is a common practice to use java.util.Optional nowadays:
could be written as
Obviously, it is not as short as in Kotlin but a huge improvement over if/else nesting.
Interesting – in Java, if I were trying to be concise, I’d probably turn to a ternary operator first, like
Still less concise than the Kotlin example but (to me, totally subjective) clearer than the
Optionalcall chain and doesn’t require instantiating a series of intermediate objects.You can do the null checking in a less concise way in Java, but it becomes a pain for highly nested types from third party libraries. Additionally, having the optional types in Kotlin make it really easy to enforce when something might be null vs will never be with syntax that’s shorter than Java. I know Java has
@Nullableand@NotNull, but I never got it to enforce the checks as easily as Kotlin. If you are working a big project and you don’t have a standard way to determine if something is nullable or not, you end up with null checks everywhere for safety, which is a pain. For new developers to Kotlin you can just tell them not to use!!in production code, and then you don’t get NPEs.There are other languages that have nicer optionals, but I think Kotlin does a good job while still working well with existing JVM libraries written in Java.
I’ve been going through a similar thought process lately regarding software stacks. I’m unhappy with Go as a language, and I’d never willingly use JavaScript on the server. I still think Django is the safest bet for a wide class of software. As we see with Doordash, Python 2 and old Django got them very far. Afaik companies like Pinterest and Instagram still make heavy use of Django?
However, given their heavy (and IMO, warranted!) emphasis on a REPL in their comparison table, I’m surprised they didn’t give a look to Phoenix/Elixir. It provides an experience similar to Django where you can open your app in the REPL and poke at everything, but it’ll scale to all your cores, and LiveView is truly a game-changer.
It’s probably because there aren’t as many elixir developers. They mention headcount as a disqualifying feature. From the article:
This might be off-topic, but do you mind sharing why you are unhappy with Go? I was going to start some new personal projects in Go rather than Python (as a learning experience), and I’d be interested in knowing some of the possible downsides.
I encourage you to learn Go. There’s not much to it. It’s fine if you think it is. To me it feels bad to program in, given its limited facilities for abstraction and error handling. “Everything is a loop” makes simple algorithms feel complicated, and having error returns but no Result type or sugar syntax (like in Rust or Zig) for bubbling up errors is the worst of all error-handling worlds.
There are a lot of things to like about it, but I find it fatiguing to read. I think it’s somewhat unique in that it is a higher-level language in terms of its runtime (GC, M:N threading, channels) but sticks to these lower-level imperative control flow aesthetics. I’m sure there was some reason for this aside from the aesthetic preferences of Pike and peers. Maybe generics will allow for a more idiomatic use of FP.
Thanks!