It'll be interesting to see how Go will cope with Kotlin/Native (in technology preview stage right now)
Kotlin has no unsigned types (JVM language). In embedded / IoT applications that's a downside. It seems that unsigned types are the only major advantage Go has over Kotlin/Native.
What is there to cope? Go is winning in market pretty aggressively. Kotlin native has nothing to offer over languages which were designed free of JVM / Java baggage like Go/Rust/Swift.
Also Java 9+ itself is going to offer AOT compilation for those who have to use Java and want native too.
Kotlin may be fine language and Google added a low effort support to Android. It may get more popular on Android but it is about as old as Go but here is trend for the two in general:
https://trends.google.com/trends/explore?q=%2Fm%2F09gbxjr,Ko...
Kotlin also lacks value types necessary for efficient memory layout and high perf/low latency GC. Build system as gradle/maven might cut for Java but Go user are used to fast/inbuilt tools like go build/run/install etc.
On HN maybe, but in the wider world, and the enterprise, not so much (if at all).
>Kotlin native has nothing to offer over languages which were designed free of JVM / Java baggage like Go/Rust/Swift.
How about less complex than Rust, less associated with Apple than Swift, and better designed than Go? And with serious compatibility with Kotlin for the JVM -- which boosted by Android adoption will get quite big soon.
> How about less complex than Rust, less associated with Apple than Swift, and better designed than Go? And with serious compatibility with Kotlin for the JVM -- which boosted by Android adoption will get quite big soon.
How about a language that has every feature I want and slowly every feature that everyone else wants. If it has been tried and done successfully before, I have not seen results in commercial software realm.
Going by the hype of Kotlin on Android I am wondering it may end up becoming part of Daydream but without any VR.
Well, C++ and C# would be those kind of languages.
C++ does not even have a decent ADT and pattern matching support, you have to do some really kinky stuff to implement something that would at least resemble option type.
Ask this again in 8-10 years' time.
And I don't mean that as flippant, enterprise projects simply have insanely long lifecycles.
Not for my money. A few things Go does better than Kotlin:
1. No classes, inheritance, etc (let's dispense with the "you don't have to use it!" arguments; they don't prevent us from interacting with an ecosystem and std lib full of classes and inheritance) 2. Concurrency; Go has one model, goroutines. Goroutines != coroutines, and no worrying about whether some function blocks the thread with a sync call. 3. Real, first class value types. Easy reasoning about allocations and escape analysis, etc. 4. Tooling: most everything is simple and does the right thing by default. There is one build system to understand, and there are no build scripts to write or cargo cult. Oh, and it's fast.
Kotlin has generics which are nice, but in practice I spend zero time on runtime type errors; on the other hand, reasoning about performance and tooling consume quite a lot of my time. I'm happy that it's getting generics, but it has a long way to go before it's competitive with Go for my time.
This form of AOT doesn't free you from the JVM though. It's cached machine code but it still needs the VM to run.
https://blogs.oracle.com/darcy/unsigned-integer-arithmetic-a...
The reason why Java didn't got unsigned types was because Gosling went around Sun R&D offices asking about unsigned arithmetic and almost everyone got it wrong.
I miss them when in Java though.
Maybe R&D would be busy making cool demos of futuristic technology which could beat Microsoft's cool demos.
They killed the only innovative desktop they had, NeWS. And although Swing is quite powerful, the default configuration certainly isn't.
They also removed resources from JOGL, Java3D and JDI.
Also given the existance of so many Wirth influenced languages with AOT compilation to native code, at the time Java was released, I never understood why they were so religiously against AOT toolchains.
There is even a paper from Sun Research about writing Solaris drivers in Java, but instead of compiling AOT to native code, they ported the JVM into kernel space.
I wonder what would have they done if the partnership with NeXT regarding OpenSTEP had actually gone forward, instead of being the inspiration to Java.
Java 9 does have an AOT compiler, at least for Linux (they're using the platform native DLL formats unfortunately so the AOT compiler tool has to be manually ported to each platform). Unfortunately it isn't just saving the compiled hotspots. They compile everything without speculative opts and then you can make it re-JIT on the fly from native->native.
I am fully aware of Java 9 AOT compiler, including the facts that not only it is just for x64 Linux, it just supports compiling the java.base module and the result isn't distributable.
However all commercial third party JDKs that didn't suffer from Sun's dogmatic war against AOT compilation, do support fully compiling Java into native code ahead of time.
Sure Java 10 is supposed to make everything better, including supporting value types, which the above mentioned languages also supported by the time Java was designed, yet that is something that is still like 5 years away or even more.
Interesting. Intuitively, does not seem like such a good idea. On the other hand, there was (and I think still is) this company called Esmertec that was doing embedded Java stuff (from around 2001). And IIRC there was Jikes, which I think was a compiler for Java from IBM. Also saw your comment below about third-party JDKS with AOT compilation.
There are probably others in the embedded space, as Java is actually gaining some traction to more classical approaches.
And of course, there is also Android with ART.
This was the paper I was referring to, http://dl.acm.org/citation.cfm?id=1698145
I switched my current project from Dart to TypeScript. I think Dart is the better language, with a decent standard library, but getting interop working for various JavaScript languages was just sucking up too much time.
I'd love to have used Scala.js, especially since the rest of the project is written in Scala, but again, interop issues.