Kotlin 1.2.60 comes with native compiler binaries
github.comNot 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."
So it's the compiler that's native, not the output. Or?
The submission is about the compiler which is now shipped as native binaries that have been compiled using ExclesiorJET AOT.
There is also a compiler for Kotlin that builds native binaries instead of JVM bytecode. It is a different project from the same company.
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 Kotlin Native to do that — if your app doesn't depend on anything JVM-specific (apart from the small subset of basic things reimplemented in Native), of course.
You can use SubstrateVM to do that for free, if you don't use too much dynamic coding.
Jetbrains is like a new Borland. I hope they don’t end the same...
What does that mean?
They had their own "languages" - Turbo Pascal (Delphi) and Borland C++, while not "new" languages, they were both very specific to Borland in their own ways. Their IDE's were much better than just about anything else available at the time. Then they made mistakes and competition came in big time (Visual Studio iirc). Anyway, it was a "long" time ago and I don't remember all of the details, but that's the gist of it.
I'm sure someone will be happy to correct anything I got wrong :)
edit: I don't think this will happen to JetBrains. edit2: Forgot the "Delphi" name, but it was basically TP w/ libraries.
Your history is a little mixed up there. The original author of Turbo Pascal, and Chief Architect of Delphi, became the Lead Architect of C#. It’s not like Microsoft came out of nowhere and ate Borland’s lunch.
This
I'm going to guess it's a reference to a language that sells an IDE. Even though Delphi could feasibly be written in any text editor (It was really just Object Pascal) the VCL was the big selling point.
I've yet to write any Kotlin in anything other than Vim and Atom though... and Gradle built those apps just fine. So I'm not sure I see a real comparison here.
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.
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 plugins are becoming important part of language development, either through IDE specific plugins like IntelliJ ones or more generic solutions such as language servers.
> 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.
And there are newer languages like Go. Go was designed to not require an IDE while not being opposed to one.
I think the language server idea is a brilliant one and probably something we'll see more and more of, because it makes a language completely editor/IDE agnostic. It would allow folks using vim or VS code to debug or refactor as cleanly as full-blown IDEs. I suspect this will lead to a decline in the specialized IDE market (Jetbrains).
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.
I agree with GP. I do not want to use a language that does not at least have a plugin in IntelliJ. I remember the amount of dumb errors running the code has decreased tremendously after started using a serious IDE. Not going back as I'm dependent on it and feel scared of coding without its checks and utilities.
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.
In other words, you're intenionally limiting your horizon because of convenience?
Not really practically but yes in theory? The JVM is host to many languages with different paradigms and it is not like I don't futz around with other stuff. I refuse to write serious code in poorly tooled languages and at this point in my career there are also some areas of exploration I just don't care about (e.g. machine level programming with ASM or C/C++ and web dev with JavaScript).
Ah, okay. What I didn't quite get from your original post was that you were talking about professional-level coding. That makes sense, I guess.
To be fair, life is indeed too short to waste it trying to wrangle unusable tools, particularly when potential gains are slim to none.
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.
How big are your datasets?
A few petabytes in some cases. Some advanced balanced sampling in Spark must be used for testing the models.
Also, Kotlin is mostly developed by JetBrains, makers of IntelliJ.
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.
It's one of the reasons I like Java. People call it a "verbose" language, but it's such a simple language syntax-wise that the IDE knows most of the time exactly what's going on in the editor window. Static typing helps, too, of course.
I remember working with C++ in Visual Studio when that new refactoring plugin became popular (tomatoe something something? later bought by Microsoft) and although the plugin tried its best, it often stopped working with files with a lot of ifdefs and macros.
B removed some features from BCPL that were too expensive to implement. I never understood why they didn't continue that idea in C by applying it to the syntax as well. Wirth knew what he was doing.
I started programming with Turbo Pascal
https://en.m.wikipedia.org/wiki/Turbo_Pascal
and as far as I remember I never had to leave the IDE. The step-by-step debugger felt like magic.
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.
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.
He also created Turbo Pascal and Delphi, which both had pretty great tooling support in their respective heydeys.
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.
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++).
I think they were very much inspired by Delphi and other Borland products at the time. Delphi was pretty awesome in 1996/1997.
> I think they were very much inspired by Delphi and other Borland products at the time.
Inspired by is an understatement, the connection is more intimate: https://en.m.wikipedia.org/wiki/Anders_Hejlsberg
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).
If that was the case for C#/.NET, they really didn't have much to show for it at time of release. IntelliJ IDEA that came out a year later was a fancier, more 'integrated' IDE.
But beside smalltalk, there were lots of others. All the commercial Lisps, Dylan etc. Somewhat more mainstream-ish - the NeXT Objective C environment is a good and much earlier example.
There were lots of interesting things about .NET when it came out, the IDE-ness of it doesn't strike me as one of them at all.
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.
VB comes from the same lineage. Heck, even delphi does, obviously.
I do think it's great, but I'm worried that as Kotlin grows, so does Jetbrains hold on IntelliJ and the IDE market. IMO, any change that benefits IntelliJ should theoretically be applicable to NetBeans.
Maybe it's already this way? I'm really not sure, but I'd appreciate a NetBeans or IntelliJ dev to clarify. It'd be awesome if these changes were done collaboratively.
IntelliJ is "the" IDE market, but not the entire ecosystem.
Sure, as long there isn't much to improve in the language itself.
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.
I believe those fixes are for the IDE plugin they release in parallel with every Kotlin release.
Thanks!
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.
This is basically the idea behind the Language Server Protocol. The language toolchain provides a server and the IDE is a client.
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.
Go is a language like that, with e.g. the gorename tool for refactoring.
A language and an IDE are completely separate things.
Yeah. It used to be "choose IDE that supports your language", now it will be "choose a language that is supported by your IDE".
I mean it's sorta in the name "Integrated"
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.
An IDE is essentially an extended front-end for a compiler.