Live data from Hacker News

Kotlin 1.2.60 comes with native compiler binaries

github.com

41–50 of 69 posts

Re: Kotlin 1.2.60 comes with native compiler binaries

#41

Earlier quoted context omitted.

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 wer…

Why C# exists isn’t very relevant to that, Microsoft actually made the IDE team a first class member st the table during C#’s design and evolution. Such and such feature thought to be difficult to tool even if it can compile? Well, fix it or cut it.

Microsoft intellisense (aka code completion) was truly a first back in 1997 (then just for VB and C++).

Re: Kotlin 1.2.60 comes with native compiler binaries

#42
post #29

Earlier quoted context omitted.

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.

Yes, but none of those IDEs were developed concurrently with the language by tightly integrated teams (well, except smalltalk).

Re: Kotlin 1.2.60 comes with native compiler binaries

#43
post #37
post #34

Earlier quoted context omitted.

I went the other way round; dumped all JetBrains stuff and now write most things in Atom/Nuclide. At least it's not as slow with very large files as JetBrains stuff. I realized with Deep Learning work and Jupyter Notebook that I actually don't need IDE anymore...

How do you use Jupyter for Deep Learning? I can only think about prototyping stuff, but not for training a large dataset (that doesn't fit in memory) for days.

Of course, prototyping only + test runs; then moving the code to proper source files (or writing them separately and including them in the notebook). Usually I write everything in the notebook, make sure I catch all the bugs, do some initial test runs to see if I am getting anywhere, then separating code out to individual Python files. The good thing is I can immediately showcase principles and progress to clients by interleaving markdown with the code, throw in some visualization and stats to the mix, add links to arxiv papers and github repos, showcase multiple approaches/models with preliminary accuracy results or heatmap visualizations etc. Then (reasonable) clients are properly informed and can decide which direction they want to move forward etc.

Re: Kotlin 1.2.60 comes with native compiler binaries

#44

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 ?

Perhaps the compiled output of jaotc is not suitable for distribution, but is intended more as an equivalent of ngen in .NET?

JEP 295 says: "AOT compilation must be executed on the same system or a system with the same configuration on which AOT code will be used by Java application."

Re: Kotlin 1.2.60 comes with native compiler binaries

#45

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…

Also, Kotlin is mostly developed by JetBrains, makers of IntelliJ.

Re: Kotlin 1.2.60 comes with native compiler binaries

#46

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.

sorry dumb question (i think that answer is yes): can i use this to build a statically linked binary of my kotlin app?

You can use SubstrateVM to do that for free, if you don't use too much dynamic coding.

Re: Kotlin 1.2.60 comes with native compiler binaries

#47
post #39

Earlier quoted context omitted.

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…

> I think it's a symptom of times changing. People don't want to code in vi/nano anymore. Not sure if that is true. Many people are still using vim for many newer languages. I think it depends on the language. Some languages are simply more IDE-reliant than others. Statically typed languages with a large vocabulary (Java, C#, Scala) tend to benefit more from IDEs than simple, dynamic languages like Python and Ruby. A…

All languages can benefit from a good IDE. It's not related to the language. However very few languages actually have good IDEs, either because they are designed in ways that are hostile to static analysis (scripting langs) or because they just don't invest in tooling (Go, Rust).

Kotlin is unusual because JetBrains invested heavily in their IDE support from the start and developed it hand in hand with their plugin, so there's nothing in the language that is hard to statically analyse in a fast way.

As a Kotlin user it makes it a very pleasant language to develop in. You should try it.

As for IDE agnostic language servers, I think you'll find they find it hard to compete with IntelliJ or similar advanced IDEs simply because the "protocol" for classical IDEs is very fast, high throughput and complex object APIs. The featureset of something like IntelliJ is enormous and they can iterate very quickly. It'll be a long time until there is strong competition to it especially with a standards based out of process server-type design.

Re: Kotlin 1.2.60 comes with native compiler binaries

#48
post #29

Earlier quoted context omitted.

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

Yes, but none of those IDEs were developed concurrently with the language by tightly integrated teams (well, except smalltalk).

Yes they were. Delphi and Visual Basic are the most obvious examples of IDE-centric languages. You couldn't even buy the compiler separately from the IDE.

Re: Kotlin 1.2.60 comes with native compiler binaries

#49
post #25

Tons of bug fixes with no new features makes me very happy

That's because it's a point release. See 1.3-M1: https://github.com/JetBrains/kotlin/releases/tag/v1.3-M1 (blog https://blog.jetbrains.com/kotlin/2018/07/see-whats-coming-i... )

That's true but JetBrains have been iterating the 1.2.x releases for a year now, and each one is like this - tons of bug fixes and small polishes. They add new IDE features but not new language features.

That said, the IDE plugin can still use some stability work.

Re: Kotlin 1.2.60 comes with native compiler binaries

#50
post #40

Earlier quoted context omitted.

That's true, Turbo Pascal was awesome. But to stay realist, it was rather an exception than the rule at the time.

There was also Turbo C/C++, Turbo Basic, Turbo Prolog. On the Microsoft side, there as Quick C, Quick Basic, etc. IDEs were the norm rather than the exception in the 80s and 90s for DOS machines. Writing code on DOS with a plain-text editor was a little unusual, whereas on Unix it was a norm.

Yes. This is one of the reasons that Windows stomped UNIX everywhere outside of big iron servers. Windows developers had access to much more advanced development environments that were very productive compared to vim+c and maybe a buggy C++ compiler if you're lucky, which is what UNIX vendors were offering at the time.

Visual Basic, Delphi, MS Access, Visual FoxPro, Visual Objects, Visual Studio, C++Builder, Macromedia Flash, even obscure stuff like REBOL - all supported very fast iteration on client side business CRUD apps that connected to a database.

It's only in recent times that we lost this and came to believe that buggy bloated text editors implemented in HTML plus a giant pile of pre-processors in which everything is coded by hand and the frameworks are obsoleted every six months is a good developer experience. Compared to what we had in the 90's the level of polish and integration is far, far lower in modern toolchains.

Post reply on HN