Hacker News Reader

Comment by the_mitsuhiko | Hacker News Reader

> there’s little of that actually happening (at least with “current” languages, “next” ones seem to fare better).

I'm not too involved but I think the languages that actually develop the tooling as part of the language design have traditionally done quite well at it in language design. Delphi/C#/TypeScript all had tooling built alongside the language and it shows.

Rust sadly made a ton of choices in the language that just make a lot of things hard, but enabled the type of ecosystem that exists today. So it has different tradeoffs. I'm quite amazed how well RLS is doing considering how hostile the language is to fast iteration.

View on HN

I am not entirely sure about C#, if we speak about “static analysis based IDE” tooling. I think this only became focus with Roslyn, and Roslyn came later, after JetBrains did their own thing with resharper.

But yeah, directionally we are getting there: Microsoft seems to be the main popularizer of the idea (TypeScript and LSP), and Google seems to be most acutely aware about the “tooling gap” (Go, Dart, and, most recently, Carbon are cognizant of tooling needs. Carbon has signatures for tooling, and Dart shipped a better version of LSP before LSP became a thing).

I just remember years ago reading interviews with Hejlsberg about how he designed C# (particularly LINQ) with IDEs in mind. Given that he also worked on Delphi I think it’s a core pillar.

I think that was meant in a very narrow sense comparing to SQL. In SQL the columns being selected go before the the table name so the IDE can't suggest a set of valid columns. In LINQ the order is flipped. But other than that there's no grand language design there to support tooling.

You don’t have to have a grand design, you just need to get the important pieces right. C# has an excellent IDE experience not because LINQ is in the right order but because it has a fundamental compilation model and object system that supports tooling well. They could have gone nuts with compile time logic but they did not to support a better IDE experience.

Look at Kotlin to see the opposite. It was designed to be IDE friendly - in fact, it was developed by the IntelliJ folks.

However, looking at it now, it seems that Kotlin is pretty much falling behind even Java in terms of features and functionality. But especially it also seems behind in a well-thought design.

When looking at Rust, I think while there are still a lot of features that I would desire, it at least introduced major improvements like typeclasses (or "traits" in Rust lingo) which really help the ecosystem and libraries to flourish. If this makes it harder for the compiler and the IDE then I think it's a fair tradeoff. Kotlin had the chance to do the same, they deliberately didn't and I is already starting to hinder the language from thriving.

Kotlin is in a tricky place w.r.t. Java because the JVM is one of Kotlin's target platforms. If Kotlin deviated from the JVM too far, it would be harder to migrate to the newer JVM versions.

That specifically applies to things like pattern matching and value classes. Value classes are constrained to single values to allow the Kotlin compiler to do the heavy lifting without involving specific JVM capabilities.

It will be interesting to see how Kotlin evolves with version 2.0 and beyond, with the new compiler and stable multiplatform support.

I don't think so. Look at Scala, which is in the same position as Kotlin. Still, it has a far superior featureset both compared to Java and Kotlin and has had pattern matching since almost forever (in fact, Java's pattern matching, sealed classes etc. are heavily inspired by Scala's). And it manages quite fine to do all these things, even before the JVM improved to support those features better in a native way.

Curious as to what parts of Kotlin you think are falling behind Java. Java has been playing catch-up forever. Java just implemented light weight threads - coroutines in Kotlin which I've been using for years. I've used data classes forever and, again, Java just recently implemented their equivalent - records. Sealed classes are the only feature I can think of but not a must-have for me. What am I missing? For some background, I've been a Java developer for over 10 years. I work with Kotlin and Java daily - my company has a backend written in Kotlin and many ancillary services in Java. I prefer Kotlin - it's a joy to write in. JetBrains hit a sweet spot by being able to mix functional and imperative coding.

A good example is the latest pattern-matching addendums to Java which are lacking in Kotlin in comparison. Sealed classes (aka coproducts/sumtypes) are another and are an essential part of any programming language, on the same level es enums. I think you are experiencing the blub-paradox in this case.

Yes, Java has been (and is still) playing catch-up, but there has been some serious progress recently and when features come, they tend to be better than the Kotlin counterparts from what I can tell.

That being said, I'm not claiming that Java is better than Kotlin right now. But when projecting into the future, I doubt that Kotlin has one, sorry to say that. A couple of years ago I would have said the exact opposite, but Java has really stepped up since then.

Wait, if sealed classes are essential, how did java survive so long without them? Possibly a nice-to-have but essential? To say Kotlin doesn't have a future when it is one of the widest used languages is a stretch. I think it's great that Java has been stepping up their feature development. I will continue to use both.

Well, java "survived" without it because, at the time, most other languages didn't have sumtypes either. But almost every new/modern language does. Exceptions are rare (golang is one of them and even for golang there are discussions: https://github.com/golang/go/issues/57644)

> To say Kotlin doesn't have a future when it is one of the widest used languages is a stretch

Well, let me say it like that: if Java and Kotlin continue to progress with the same speed like they do now, then Kotlin will not be a "better Java" anymore and the only selling-point will be IDE support (if that's even possible).

Kotlin is a 'better Java' because of the ability to mix functional and imperative code. Java will never do that. I don't know what you mean about 'IDE support'. Neither of them are going anywhere.

Kotlin is made by Jetbrains which make IntelliJ - so IDE support is a plus-point for Kotlin. That is what I meant.

I think Java has become way more functional over time. It is not and probably never will properly support a pure functional style (e.g. like Scala) but I don't see it much behind compared to Kotlin. Mind to give some examples where Java is behind Kotlin in this context?

Reply on news.ycombinator.com