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

Kotlin/Native Tech Preview: Kotlin without a VM

blog.jetbrains.com

Post reply on HN
Print view View original

51–60 of 79 posts

Re: Kotlin/Native Tech Preview: Kotlin without a VM

#51

Post by mwcampbell »

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.

Re: Kotlin/Native Tech Preview: Kotlin without a VM

#53

Post by pjmlp »

saosebastiao wrote: post #42
jorgemf wrote: post #23

Earlier quoted context omitted.

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

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

> 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.

Re: Kotlin/Native Tech Preview: Kotlin without a VM

#54

Post by pjmlp »

mwcampbell wrote: post #10

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.

Re: Kotlin/Native Tech Preview: Kotlin without a VM

#55

Post by camgunz »

proyb2 wrote: post #13
meddlepal wrote: post #3

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/ .

Re: Kotlin/Native Tech Preview: Kotlin without a VM

#57

Post by coldtea »

pjmlp wrote: post #53
saosebastiao wrote: post #42

Earlier quoted context omitted.

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

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

>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?

Re: Kotlin/Native Tech Preview: Kotlin without a VM

#58

Post by coldtea »

deno wrote: post #35
hasenj wrote: post #15

Earlier quoted context omitted.

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 = Promise.resolve(null); const bar: Promise = 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.

Re: Kotlin/Native Tech Preview: Kotlin without a VM

#59

Post by coldtea »

adrianlmm wrote: post #30

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.

Re: Kotlin/Native Tech Preview: Kotlin without a VM

#60

Post by [deleted] »

coldtea wrote: post #58
deno wrote: post #35

Earlier quoted context omitted.

Typescript is nice but its type system is not the strongest selling point. For example this compiles without warnings: const foo: Promise = Promise.resolve(null); const bar: Promise = 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.

[deleted]
Post reply on HN