Hacker News new | past | comments | ask | show | jobs | submit login
Kotlin/Native Tech Preview: Kotlin without a VM (jetbrains.com)
159 points by essh on April 4, 2017 | hide | past | favorite | 77 comments



> This Technology Preview features automatic reference counting with a cycle collector on top, but what the final memory management solution(s) will look like is unknown at this point.

Same issue with Scala Native[1]. Both projects are a long way from being production ready wrt to targeting ios, android and desktop.

Probably at least a couple of years before either project delivers the one-language-to-rule-them-all.

[1] https://github.com/scala-native/scala-native


May they all do great. But I am sceptical that Scala/Kotlin and many others started in last decade stand chance against Java/Rust/Swift/Go. IMO these 4 are backed by powerful corporations and have large community momentum. They are going to keep >90% of all software work along with C/C++.


kotlin is backed by a tooling company. This is a very strong argument. The ones that are doing the best IDE for java (for a lot of people) are the ones that decided to create kotlin. Swift also has the tooling support of Apple, but I only read complains about tooling around Swift. Go and Rust are very niche compare to java or swift, while kotlin can replace java completely and now it is aiming for native backend projects.


> while kotlin can replace java completely

I am not sure it can be be concluded from any data. They have come up with just a tech preview. Doing better job than Rust/Swift/Java or Go to have high perf on native platforms is going to be a huge effort. Just having a binding via LLVM is a small start.

Hope they do better but for now it seems to me that hype around it is about 2-3 magnitudes higher than the actual amount of software written in it.


kotlin can replace java completely because it compiles to bytecode (as java does). And then it is the bytecode what is compiled/interpreted in the JVM.

The tech preview is about kotlin compiling directly to machine code. They already said they haven't done any optimization into that code. I guess they use some intermediate language for the compiler to translate it to machine code. (note that all the compilers translate the original input file into this intermediate language before compiling it to the final code, so they can do a lot of optimization and checks in this code which are shared among all languages)


I'm skeptical of the strategic advantage of being backed by a tooling company, because of the fact that tooling is often a preference that comes with holy wars attached. If Emacs sponsored a language, how many Vim users would jump ship? I know plenty of Java devs that actually prefer Eclipse (WTF?!?!?). Good luck getting an entire team onboard with a single IDE.

Throw in the fact that their IDE software is open source only until you need the most advanced features, and I can imagine Kotlin never picking up as much steam as Rust or Swift with their comparably inferior tooling ecosystems. I can imagine C# taking over java before Kotlin does.


>If Emacs sponsored a language

Emacs does sponsor a language (elisp), and it's most people's reason for using it.


> Good luck getting an entire team onboard with a single IDE.

Actually that is how many enterprise companies work.

I usually get to use what the IT department from our customers has decided as IDE for a specific project.

Anything else usually requires a change request with the necessary approvals at all levels, which means very few people ever bother to go through that pain, assuming that it will be approved in the end, because "I don't like X" won't work as reason.


>assuming that it will be approved in the end, because "I don't like X" won't work as reason.

How well does "else I quit, my code, my tools" works as a reason?


Good luck when you have a family and don't happen to live in places like Silicon Valley.

We are talking about enterprise here, there are plenty of people for that position, specially external consultants, no one would be stopping you from leaving.

In fact they might even help you taking your things out.


>We are talking about enterprise here, there are plenty of people for that position, specially external consultants, no one would be stopping you from leaving.

Well, if you're an external consultant, it's they that called you to get them out of some mess in the first place.

You didn't knock on their door to ask for work.


I always had this kind of experience even as internal dev.

The only time I had some kind of freedom, away from what IT says how things should be, was at a few startups.

Once those startups grew, the big boys from IT started to create a standard development environment.


> Good luck getting an entire team onboard with a single IDE.

Many companies mandate that you use Visual Studio to develop with because their entire toolchain is setup to build the project via VS tools. Deviating from that means that no one can help you, and you're probably polluting the repo with your own ad-hoc tooling.


Absolutely. I think Kotlin might settle in a specific Java platform tooling category where a bunch of code in Java can be concisely expressed in Kotlin.

With Scala being more than a decade old, its most popular usage is Apache Spark project which is not saying much. Kotlin would first have to reach beyond Scala which itself is small percentage point of Java.


backed by a tooling company means that the language was designed with tooling in mind and that there are going to be quality tools for the language. It doesn't mean there is only going to be one alternative.

Intellij Idea as IDE is a great choice. Android developers were forced to move from Eclipse to Idea and I haven't seen any resistance to avoid it. I have heard iOS developers complaning about tooling around swift. So, I think it is a strong point.


> If Emacs sponsored a language

I think you've missed something here...


This is a great point and I wonder if JetBrains released a free IDE for individual programmers it would help adopt their technologies wherever these programmers work.

Yesterday I took a look at their tools and they are all absolutely great but I didn't download a single one since they are all 30-day trial and I am as poor as fuck.

So tease me, convert me, let me use your tools for years and when the time comes I am ready for an enterprise I'd take my knowledge with me, and my tools.

JetBrains are you listening?


IntelliJ IDEA Community Edition is free(cero cost) and Open Source.

I believe it includes Kotlin Support.

https://www.jetbrains.com/idea/#chooseYourEdition


Community version of IntelliJ works just fine for Kotlin development.


Check out their open source license.

https://www.jetbrains.com/buy/opensource/


Intellij IDEA has a free community edition, but yeah, nothing free for commericial development. https://www.jetbrains.com/idea/download/


It is important to note that they don't prohibit commercial development on the community edition.

They just do not promote the community edition for commercial development.

I, for instance, could choose to use PyCharm community since I rarely use any of the tooling that comes with the 'pro edition', but when I do need something---like Cython debugging---its damned useful.


Depends on how you define commercial development.

You can certainly do commercial applications using Intellij IDEA CE, if you don't need Java EE, Spring, GWT, Grails, etc deep integration in the IDE.


Some of these corporations are experts in shooting in the foot.

I wanted to read 'The Swift Programming Language (Swift 3.1 Edition)'. It is just an epub, just distributed via Apple iBooks, right?

When trying to open in on an Android tablet, I found out that it is DRM-ed. Why on earth would you put DRM on a publication you want to circulate as widely as possible? Why would anyone have to read reference docs for multi platform language on a single platform?

That certainly dampened my enthusiasm for Swift.


No, it is distributed on the open source site since it exists.

https://swift.org/documentation/

I never had any issue reading it on Aldiko, even the Apple versions.


I have it from iBooks, because in the past, it wasn't on the site yet. Since then, I just update it via iBooks. The previous editions didn't have DRM either.


I would think it is an oversight. From their website:

> This ePub document is made available under a Creative Commons Attribution 4.0 International (CC BY 4.0) License.

They should make PDF/html available to all.


Hopefully, it might be oversight.

The (non-DRM) epub is fine too, it is just a bunch of of html files, zipped.


The download link from swift.org doesn't seem to be DRM'd. I can open it just fine in my ePub reader. Maybe its an iBooks thing?

https://swift.org/documentation/TheSwiftProgrammingLanguage(...


Maybe iBook thing. The 3.0 edition wasn't DRM-ed, though.


Just the same as the book: https://developer.apple.com/library/content/documentation/Sw...


I'm not sure. How much does Mozilla actually invest in Rust? Same with Google and Go. I would guess over the past 15 years that Sun/Oracle (Java) and Microsoft (C#/.NET) each annually spend more on language / platform development than everyone else put together does over 5 or 10 years.


Yes, I missed C#. C#/Java were largely developed in-house. So they would need huge teams and infrastructure. Rust/Go have huge community momentum so not all development is done by people paid by Google or Mozilla.


C# has a growing community momentum now, too. Very interesting to watch.


FWIW, C# also has compiled into native executables/libs for many years via `mkbundle`[1] and into JS via several projects like Bridge.NET [2].

[1] https://linux.die.net/man/1/mkbundle

[2] https://github.com/bridgedotnet/Bridge


> I am sceptical that Scala/Kotlin and many others started in last decade stand chance against Java/Rust/Swift/Go

In contrast to Scala, Kotlin has a much stronger focus on Java interop so its able to much better leverage the JVM ecosystem. In particular, Kotlin hits a really good sweet spot for Android development, where it can still be compatible with older JVM versions, the language features can really increase readability and reduce bugs, and the overhead isn't too dramatic.

The network effects also amplify its usefulness; JetBrains continues improving the language and its tooling; Android Studio is based on IntelliJ so the integration is also strong; more developers use the language and produce more libraries, frameworks, and ensure compatibility is excellent.

By design you can begin using Kotlin in a Java project slowly (there's even a Java->Kotlin converter), so if you are developing on a Java stack, Kotlin is worth investigating!


I'm curious about it without even the mobile story. But just compiling command-line apps for easy distribution, similar to GoLang.


They might reach there quickly. But having a state of the art GC like Java or low memory profile like Rust/Go and high performance might take a long time.


This is great! I've adopted Kotlin as my go-to JVM language but being able to write code that outputs native binaries for things like CLI tools would be huge and may serve as a strong competitor to Go as a pragmatic, but well designed language.


In addition I feel SCADE.io uses Swift has more production quality than Go. I tested Unsafepointer C in Swift is significantly faster in version 3.1. It is in some case is faster than Go, Ruby, GCC and Java just for fun in benchmark.

Kotlin to LLVM is amazing idea and risky if it will break in Android. Only time will tell.


A little OT but something called SCADE already exists: http://www.esterel-technologies.com/products/scade-suite/ .


I think using ARC for memory management is smart. However, the cycle collector isn't going to work when you start doing interop with native objects. So I think Kotlin is going to need a "Weak" annotation in the standard library, which will be a no-op on the JVM and JS.


Or it needs to pin it.


Is there a spec?

They talk about modules and I am curious about their syntax (if any). If we are to support a new multi-platform ecosystem, we should make sure it is built on a stable foundation.

For example, I really like scala, but I can't convince myself to try scala-js due to the unsoundness of the platform. Some scala libraries work, some libraries compile but won't work as expected and some libraries need porting. And you don't really know which is which.

https://www.scala-js.org/doc/semantics.html


For really smooth interop between Kotlin and a host platform, I don't think there can be just one Kotlin Native. Perhaps it would be better to target just one platform initially. Here's what my ideal Kotlin for iOS would look like:

The compiler wouldn't compile to native code using LLVM, but would produce Objective-C source code, to be compiled with Apple's clang compiler. That way, no matter what crazy requirements Apple throws at us tomorrow (similar to 64-bit and bitcode), we don't have to wait on JetBrains.

Kotlin's Any type should be synonymous with NSObject.

Kotlin's String type should be synonymous with NSString.

Kotlin shouldn't define its own concrete collection classes on this platform, but should use NSArray, NSDictionary, NSSet, and their mutable counterparts.

The standard library should be the intersection of the Kotlin JVM and JS standard libraries. Nothing more, at least at first.

Any reflection facilities should be in a separate, optional library. I want to be able to ship an app without the slightest hint of run-time dynamism, to keep Apple happy.

Memory management should be ARC. Period. This means we'll need a Weak annotation.

Edit:

The ability to export Kotlin classes to ObjC, with control over the names of classes and methods, and support for ObjC properties.

Basically, I want J2ObjC for Kotlin, but with no concrete collection classes of its own, and generally much less of a runtime library.


Using kotlin in web pages, client side and server side could be a big win. You could be able to use exactly the same language in all you stack. Although programming for the frontend will be different than programming for the backend, the fact that any of them can review the code of the others is great. You could also move resources in peak times to help a little.


I still prefer TypeScript for web frontend code, because it fits a lot nicer into that ecosystem (React, MobX, webpack, etc.) and the structural typing also feels better suited for that environement.

Kotlin could however be awesome for cross-platform mobile dev, targeting both iOS and Android with a lot of shared code and truly native apps on both.


TypeSript is more mature and better option for frontEnd now, but I hope kotlin will catch up.

I wouldn't use kotlin for cross-platform mobile dev. There are few things Android and iOS share, you end up having to codebases in the same language (which it is good in its way). If you want to do truly native apps, just avoid sharing code because you will use different patterns and different libraries and apis. You could share the business logic but that is something I think should be on the server not in the app. The app is only the frontend.


In my experience, there is a lot of opportunity for sharing code between mobile platforms that doesn't have any real downsides. Things like:

- data structures for your domain objects

- network code (just plug in an appropriate platform-specific driver)

- like you said, business logic - especially if the app has to work offline

- if you're using something like https://realm.io/, you could avoid a lot of duplication

Anything to do with the UI then has to be platform-specific of course.


> - data structures for your domain objects

not sure there are a problem since you have data classes in kotlin. I bet swift provides something similar.

> - network code

In Android you must use okhttp, and I guess there are similar powerful libraries in swift for this.

> - if you're using something like https://realm.io/

Last time I checked it I decided to keep using SQLite as it allows me to do everything I want. Realm doesn't support "complex" SQL queries.

Again, just business logic. But there is no too much apart from field validation or simplex operations to show the data (or it should be much more). Complex things must be in the server, that is the best way to share business logic among all your apps in all the platforms.


For anyone not that familiar with Android, "must use okhttp" refers to the fact that it is the best solution, not that it's the only solution.


> use exactly the same language in all you stack

isn't this what people are doing with JavaScript?


It is, but the problem with that is that they're doing it in JavaScript.

Kotlin could offer better performance and certainly offers strong type safety throughout the stack, which I at least certainly believe gives a better programming experience.


Have you tried TypeScript?


Typescript is nice but its type system is not the strongest selling point.

For example this compiles without warnings:

   const foo: Promise<string|null> = Promise.resolve(null);
   const bar: Promise<string> = foo;

   bar.then((value) => value.toString()); // runtime null error


That's because null is an acceptable value for a string object.

Which is the same thing as in Java and plenty of other languages.


Not in Kotlin, though. You have to make it explicitly nullable if you want it to be null.


You can enable strict null checking.


You can replace string|null with string|number in this example.


A bit. It's an improvement, but if you're writing Kotlin on the backend then Kotlin/JS starts to look tempting on the basis that it's the same language everywhere.

Although using the same language in different environments obviously feels a bit different.


you don't have co-routines in JavaScript, you cannot use java libraries in JavaScript, the tooling support for java/kotlin is much better than for JavaScript, Javascript is weakly typed,... In general I think kotlin is much better language. JavaScript has a lot of issues


The problem with Javascript can't handle complex computation where Swift could run on both Android, iOS, embedded, cloud, Linux and web server and majority of C/C++ libraries. Soon they might found way to implement Rust memory model, concurrency and Coroutine like Go. It will be nearly perfect or as good without writing 4 different languages.

Kotlin could run on all supported platforms and reuse Java libraries.


You have coroutines in kotlin! and the support for native executables has started. Swift is also a very nice language, with a couple of issues: the tooling support and its instability in the first versions. But I also miss one thing from swift in kotlin: its memory model (maybe Rust one is better but I don't know it)


I know Microsoft contributed Coroutines to LLVM and now experimental in 4.0.0 and .Net core.

Which is even awesome for Microsoft to adopt LLVM.


As someone who learned Kotlin for work and then started using it in personal projects, I'm really excited for its future. I'm surprised more Java shops aren't espousing or even trying it.


Is Kotlin used outside of the web dev community?

(Real question)


The most popular use is allegedly Android development, so... yes?


If ARC is a concern, I wasn't sure how they will work on Android whereas SCADE.io use Swift to compile native app to Android and iOS is more production ready with Swift built on LLVM and Clang.


Jetbrains is trying to chew to much, from Kotlin for the JVM, Kotling for javascript and Kotling native, soon or later, it will implode and it won't be nice.


>it will implode and it won't be nice.

Hyperbolic much? At worst, it will fail to gain much traction.


We disagree, "it won't be nice" is not a hyperbolic statement.


The whole phrase "it will implode and it won't be nice" implies some kind of big mess or even the company collapsing or whatever...

Whereas it's just one of the things the company does, not even a profitable one, and at worst it will just fail to catch.

Sure, that "wont be nice either". But hardly the kind of "not nice" to be really concerned with...


You're feeding a known troll. Look at their post history.


I didn't know that not falling for the Jetbrains marketing machine was catalogued as being a troll. I beg to differ.


The "Jetbrains marketing machine"? I could spend my whole life, visiting tons of programming forums and websites, and hardly see a Jetbrains ad ever.


You are wrongly assuming that their marketing team only use ads.


That's your opinion, not mine.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: