Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kotlin 1.2.60 comes with native compiler binaries

github.com

Post reply on HN
Print view View original

21–30 of 69 posts

Re: Kotlin 1.2.60 comes with native compiler binaries

#21

Post by pookeh »

seanmcdirmid wrote: post #14
skrebbel wrote: post #12

Earlier quoted context omitted.

Isn't that fantastic? The whole idea that developer productivity (and thus, tool support) shouldn't be a part of programming language design has been flawed from the beginning and I'm happy times are finally changing.

C# also has always been done like this, but 20 years ago only Microsoft could pull that off.

The father of C# also created Typescript and we now see the same level of language tooling support OOTB with the Typescript compiler.

It's a fantastic initiative -- in such a short time we see many IDEs support consistent auto-complete, refactoring and so much more.

Re: Kotlin 1.2.60 comes with native compiler binaries

#22

Post by meddlepal »

skocznymroczny wrote: post #9
rooam-dev wrote: post #2

Is it just me or it's strange that there are so many IDE related fixes in a programming language release?

I think it's a symptom of times changing. People don't want to code in vi/nano anymore. A general purpose language launching today is expected to have a good support in an IDE. At least autocompletion, support for building and debugging, refactoring if possible. Also people prefer to have a one well working IDE plugin than several half-baked ones that don't offer much more than syntax highlighting. That's why IDE plu…

This. I really only bother touching languages with good to great IDE experiences which is why I basically concentrated on JVM tech for most of my career. The good news is that the tools story is improving across all languages these days.

Re: Kotlin 1.2.60 comes with native compiler binaries

#23

Post by kodablah »

rooam-dev wrote: post #2

Is it just me or it's strange that there are so many IDE related fixes in a programming language release?

It's not just you, and it becomes a huge pain for those that do lots of deep JVM development with Kotlin. I run into multiple language issues daily, and many of them are just undocumented facets of the language that you find YouTrack issues for.

Many many corner cases are not accounted for, and the way Kotlin is under-spec'd and developed with so many of the IntelliJ libraries, you'll never see any independently developed implementation.

This is not to say the language isn't great, it is. It's only heavy development while focused on lower level aspects that this becomes a constant theme.

Re: Kotlin 1.2.60 comes with native compiler binaries

#24

Post by _old_dude_ »

floatboth wrote: post #4

Not to be confused with https://github.com/JetBrains/kotlin-native — this is the Java version compiled with Excelsior JET, a proprietary AOT Java compiler thing.

I wonder why they have not used jlink + jaotc ?

Maven is already able to compile a the code with Java 6/Java 8 and the module-info with Java 9. With jlink, you can then create your own jdk and AOT the part of the code you want with jaotc.

Maybe those tools are too new and the perf are not great ?

Re: Kotlin 1.2.60 comes with native compiler binaries

#27

Post by jillesvangurp »

seanmcdirmid wrote: post #14
skrebbel wrote: post #12

Earlier quoted context omitted.

Isn't that fantastic? The whole idea that developer productivity (and thus, tool support) shouldn't be a part of programming language design has been flawed from the beginning and I'm happy times are finally changing.

C# also has always been done like this, but 20 years ago only Microsoft could pull that off.

C# emerged around the time that Java IDEs emerged. Basically, MS did a decent job with the C# language and tooling. However, it was very much inspired by Java, Java IDEs and Microsoft's own Java IDE (Visual J++).

I think IBM was first with supporting refactorings for Java in Visual Age and Eclipse. Refactorings themselves emerged out of the Smalltalk community.

MS was very motivated to support that for C# as they were getting worried about losing marketshare to Java at the time and because J++ got a lot of negative press (compatibiltiy issues, vendor lockin, the usual MS stuff). In the end C# was held back by the same factors that held back J++ and it took them until very recently to openly support it on platforms other than Windows.

Re: Kotlin 1.2.60 comes with native compiler binaries

#28

Post by jillesvangurp »

rooam-dev wrote: post #2

Is it just me or it's strange that there are so many IDE related fixes in a programming language release?

Not so strange if you realize that an IDE needs to do essentially the same type of things as a compiler in order to offer things like refactorings, autocompletion, etc.

Idea developed Kotlin as a better Java. Most of their IDE is now written in it. Deep integration with the IDE was a design goal from day 1.

They release the IDE plugin and compiler with the same version number. They are basically developed together. I usually find out about new Kotlin releases because my IDE prompts me to update the plugin. Happened to me this morning with 1.2.61.

Re: Kotlin 1.2.60 comes with native compiler binaries

#29

Post by pvg »

seanmcdirmid wrote: post #14
skrebbel wrote: post #12

Earlier quoted context omitted.

Isn't that fantastic? The whole idea that developer productivity (and thus, tool support) shouldn't be a part of programming language design has been flawed from the beginning and I'm happy times are finally changing.

C# also has always been done like this, but 20 years ago only Microsoft could pull that off.

There were zillions of language-specific IDEs in 2000 when C# was announced.

Re: Kotlin 1.2.60 comes with native compiler binaries

#30

Post by pvg »

vorg wrote: post #8
floatboth wrote: post #3

Earlier quoted context omitted.

Well, it's a language created by an IDE company…

The dividing line between what's a language and what's the IDE is fairly arbitrary. E.g. a language could conceivably come with a tool chain that includes CLI-driven refactoring, and an "IDE" would only need to be a graphical interface calling it.

The dividing line between what's a language and what's the IDE is fairly arbitrary

How do you figure? The language defines the runtime semantics in a way no IDE or refactoring tool does. It's a very bright line, unless you're conflating the distribution package of the language with the language itself.

Post reply on HN