Kotlin 1.1 Released with JavaScript Support, Coroutines and more(blog.jetbrains.com)
blog.jetbrains.com
Kotlin 1.1 Released with JavaScript Support, Coroutines and more
https://blog.jetbrains.com/kotlin/2017/03/kotlin-1-1/
88 comments
>Kotlin (1.0) works well with everything and is relatively succinct except for Mockito due to everything defaulting to 'final' - but it appears that Kotlin 1.1 fixes this with a compiler plugin.
It's worth pointing out that since Mockito 2.0, you've been able to opt into mocking final classes, making testing Kotlin pretty painless.
https://github.com/mockito/mockito/wiki/What's-new-in-Mockit...
It's worth pointing out that since Mockito 2.0, you've been able to opt into mocking final classes, making testing Kotlin pretty painless.
https://github.com/mockito/mockito/wiki/What's-new-in-Mockit...
Curious, if you were aiming at writing in a functional programming style, why didn't you try Clojure?
If I may jump in, here, for my 2 cents, I've never developed anything commercial with Closure, but I learned it, have played with it and have quite enjoyed it. Having never done any Lisp(-based language) programming before it didn't come... naturally. My guess is that the parent commentator didn't include it for that reason.
It doesn't have compile-time type checking. When many people say functional code they really mean code that can be and is strictly type checked at compile time. Clojure is functional, but it's not what most people want when they say "functional".
"It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." —Alan Perlis
Functional style in my opinion is about creating functions that operate on standardized data structures. Class based type systems actively discourage functional style, even when the language gives you a functional veneer over your OO code.
Haskell avoids this problem by using algebraic data types instead of class style types. Clojure avoids this problem by using dynamic typing.
I definitely do not associate 'functional' with static typing.
Functional style in my opinion is about creating functions that operate on standardized data structures. Class based type systems actively discourage functional style, even when the language gives you a functional veneer over your OO code.
Haskell avoids this problem by using algebraic data types instead of class style types. Clojure avoids this problem by using dynamic typing.
I definitely do not associate 'functional' with static typing.
Type-checking doesn't really have any bearing on weather a language is functional. Functional languages can be statically or dynamically typed.
It's one of the big differences between the lisp and ml types of functional languages I would say. Other than the parentheses that is of course :)
I've never been comfortable doing big projects - multiple files, more than a few hundred lines of code - in a dynamically typed language. It's the same reason were seeing the big uptake of typescript. Statically typed languages give us so many superpowers when we need to do refactoring or any changes at all to an existing codebase. Just changing a function name in a dynamically typed language can be hell. Rearranging the parameter order is even worse, cause you have such trouble finding all of the function uses and where you need to update. With statically typed languages you get editor support for simple stuff like this and it becomes automatic and a push of a button almost.
I've never been comfortable doing big projects - multiple files, more than a few hundred lines of code - in a dynamically typed language. It's the same reason were seeing the big uptake of typescript. Statically typed languages give us so many superpowers when we need to do refactoring or any changes at all to an existing codebase. Just changing a function name in a dynamically typed language can be hell. Rearranging the parameter order is even worse, cause you have such trouble finding all of the function uses and where you need to update. With statically typed languages you get editor support for simple stuff like this and it becomes automatic and a push of a button almost.
Static typing is great. My point is that whether a language is statically or dynamically typed has no bearing on whether it is functional.
What functinal techniques did you use? Only higher order functions or did you go all the way to applicatives, monads (maybe even free) etc.?
btw: is the source code available somwhere? Would be interesting to see a comparison between the languages.
btw: is the source code available somwhere? Would be interesting to see a comparison between the languages.
I'm interested in the comparison code as well if it's available.
> The Scala 2.12 compiler has at least one bug that appears to affect its interaction with Java 8 lambdas (in particular, in at least one case expr.method() and (expr).method() will not pass the compiler's typecheck
There are many many things that should be valid Scala but are not, due to type check limitation. All kinds of times you should be able to infer the type, but the compiler cannot and you have to start naming types. Not sure this is really a "bug" but more of a wart. Sure is annoying when they happen, but not a "unique" thing to Java8 lambdas by any measure.
There are many many things that should be valid Scala but are not, due to type check limitation. All kinds of times you should be able to infer the type, but the compiler cannot and you have to start naming types. Not sure this is really a "bug" but more of a wart. Sure is annoying when they happen, but not a "unique" thing to Java8 lambdas by any measure.
> all within a single Gradle project. [...] Groovy [...] worked with everything, though.
Given that Gradle was originally designed with Apache Groovy as its only language for writing its build config files, I'd say you should try again with the build system relevant to each language, such as SBT for Scala, Leiningen for Clojure, etc.
Given that Gradle was originally designed with Apache Groovy as its only language for writing its build config files, I'd say you should try again with the build system relevant to each language, such as SBT for Scala, Leiningen for Clojure, etc.
Kotlin for me is Java made right. It's not complex, it has awesome interoperability with Java, it uses JDK, not reinventing its own wheels and it has everything I need from modern language.
But it seems that Jetbrains has its own vision for Kotlin being a completely independent language. So while it works for me right now, I'm not sure if it will work in the future. They are going native and it'll bring a lot of changes, for sure. Honestly I would prefer it to stay as Java enhancer, as I'm not interested in Native and I need very little JavaScript interoperability, if any (probably just translating some common code between backend and frontend).
But we will see, I don't want to sound too pessimistic. Kotlin is the best language I've used so far.
But it seems that Jetbrains has its own vision for Kotlin being a completely independent language. So while it works for me right now, I'm not sure if it will work in the future. They are going native and it'll bring a lot of changes, for sure. Honestly I would prefer it to stay as Java enhancer, as I'm not interested in Native and I need very little JavaScript interoperability, if any (probably just translating some common code between backend and frontend).
But we will see, I don't want to sound too pessimistic. Kotlin is the best language I've used so far.
Even with Kotlin Native in mind, we have no plans to break Kotlin's backwards compatibility guarantees, and we do plan to support the new JVM features such as value types. So if Kotlin works well as a Java enhancer for you today, it will only work better in that role in the future.
Perhaps the bigger issue here is fragmentation. Here you are, a young language with a lot of promise whose primary appeal is Java interop and whose target market is enterprise Java and already you're dividing your efforts to offer something which your target market will likely have zero interest in. Why not wait until you have real market share in the job market and only then worry about native? Kotlin is a very niche language. That's it's appeal.
One of the niches where it's found a lot of popularity is Android development, which naturally leads developers to thinking about sharing code with the iOS version of their app. This is where Kotlin Native fits in, I think.
Also (just dreaming here) if Kotlin Native were to use some kind of Swift-like reference counting rather than a traditional GC, it could be really nice for interfacing with COM on Windows, where you need to be able to release references to COM objects immediately and possibly in a specific order. In a language with GC, your objects might not be collected soon enough, which leaves the references alive and the process hosting the COM object unable to shut down.
Also (just dreaming here) if Kotlin Native were to use some kind of Swift-like reference counting rather than a traditional GC, it could be really nice for interfacing with COM on Windows, where you need to be able to release references to COM objects immediately and possibly in a specific order. In a language with GC, your objects might not be collected soon enough, which leaves the references alive and the process hosting the COM object unable to shut down.
I agree with you about the potential of Kotlin Native. And I, too, would like reference counting, at least as an alternative to GC.
But I think that for really smooth interop with the host platform, it won't be good enough to have just one generic Kotlin Native, that compiles to native code with a cross-platform compiler infrastructure like LLVM. It would be much better to have multiple Kotlin native implementations that integrate well with various host platforms. For example:
* Kotlin for Apple platforms: Every Kotlin object is an ObjC object, and ObjC APIs can be used with minimal glue code in optimized builds. All Kotlin strings are NSStrings and vice versa. Same with collections (NSArray, NSDictionary, and their mutable counterparts); Kotlin's separation of read-only and mutable interfaces is a good match for this platform.
* Kotlin for Universal Windows Platform: UWP, being COM-based, doesn't have a root object type like the Apple platforms. Still, we'll want to be able to call UWP APIs and implement UWP interfaces with minimal runtime glue. And UWP has a reference-counted immutable string type (HSTRING), so all HSTRINGs should be Kotlin strings and vice versa. I don't recall how collections work on UWP.
* Kotlin for classic Win32 + COM: Similar to UWP, but the situation with strings is more complicated. BSTR isn't reference counted, so on this platform, Kotlin would probably need to have its own string implementation, with bridging to and from BSTR for COM interfaces.
But I think that for really smooth interop with the host platform, it won't be good enough to have just one generic Kotlin Native, that compiles to native code with a cross-platform compiler infrastructure like LLVM. It would be much better to have multiple Kotlin native implementations that integrate well with various host platforms. For example:
* Kotlin for Apple platforms: Every Kotlin object is an ObjC object, and ObjC APIs can be used with minimal glue code in optimized builds. All Kotlin strings are NSStrings and vice versa. Same with collections (NSArray, NSDictionary, and their mutable counterparts); Kotlin's separation of read-only and mutable interfaces is a good match for this platform.
* Kotlin for Universal Windows Platform: UWP, being COM-based, doesn't have a root object type like the Apple platforms. Still, we'll want to be able to call UWP APIs and implement UWP interfaces with minimal runtime glue. And UWP has a reference-counted immutable string type (HSTRING), so all HSTRINGs should be Kotlin strings and vice versa. I don't recall how collections work on UWP.
* Kotlin for classic Win32 + COM: Similar to UWP, but the situation with strings is more complicated. BSTR isn't reference counted, so on this platform, Kotlin would probably need to have its own string implementation, with bridging to and from BSTR for COM interfaces.
.NET and .NET Native work perfectly fine with COM, in spite of having a GC.
Only if you make sure to call Marshal.ReleaseComObject on all your objects, which requires you to hang on to explicit references to all of them, which is not very convenient for many COM APIs, e.g.
Python works much better with COM, in my experience, because of its more primitive but more predictable reference counting.
Application.Database.Classes.Item("MyClass").Refresh()
Python works much better with COM, in my experience, because of its more primitive but more predictable reference counting.
I use .NET since pre-alpha days and never used it, RCW and CCW take care of that.
Unless you are talking about manually loading them.
Also, are you aware that UWP and .NET Native are built on COM?
Unless you are talking about manually loading them.
Also, are you aware that UWP and .NET Native are built on COM?
I have run into this problem in two cases:
1. When writing a COM add-in for a host application. When the application wants to shut down, the add-in must release all references to the objects of the host application, otherwise the process doesn't shut down. (At least with the application I'm currently writing an add-in for!)
2. When using out-of-process COM servers such as Excel from another application. This tends to leave lots of "excel.exe" processes running unless you explicitly release everything.
See for example: https://www.add-in-express.com/creating-addins-blog/2013/11/...
Here is Microsoft describing how they ran into this problem when mixing COM and .NET in Visual Studio, how they solved it using Marshal.ReleaseComObject, how that itself caused other problems later when they combined it with CCW, and ... I'm not sure what their ultimate correct solution was:
https://blogs.msdn.microsoft.com/vcblog/2006/09/19/mixing-de...
https://blogs.msdn.microsoft.com/visualstudio/2010/03/01/mar...
I am aware of UWP bringing COM back into fashion again, which is why I'm interested in potentially using Kotlin Native with it. :)
1. When writing a COM add-in for a host application. When the application wants to shut down, the add-in must release all references to the objects of the host application, otherwise the process doesn't shut down. (At least with the application I'm currently writing an add-in for!)
2. When using out-of-process COM servers such as Excel from another application. This tends to leave lots of "excel.exe" processes running unless you explicitly release everything.
See for example: https://www.add-in-express.com/creating-addins-blog/2013/11/...
Here is Microsoft describing how they ran into this problem when mixing COM and .NET in Visual Studio, how they solved it using Marshal.ReleaseComObject, how that itself caused other problems later when they combined it with CCW, and ... I'm not sure what their ultimate correct solution was:
https://blogs.msdn.microsoft.com/vcblog/2006/09/19/mixing-de...
https://blogs.msdn.microsoft.com/visualstudio/2010/03/01/mar...
I am aware of UWP bringing COM back into fashion again, which is why I'm interested in potentially using Kotlin Native with it. :)
I've run into this kind of problem while implementing a Windows screen reader that needs to use COM-based accessibility APIs, both in-process and out-of-process. I naively chose, some 12 years ago, to use Lua, even for the in-process component. Lua, of course, uses tracing garbage collection, not reference counting.
Thanks for the explanation and links.
I guess the reason for never bumping into it was that all use cases I encountered so far, the controls were in-process and died when the application terminated.
I guess the reason for never bumping into it was that all use cases I encountered so far, the controls were in-process and died when the application terminated.
Hold on a second there... I am primarily a Java developer, although I dabble in some functional languages like Erlang, and usually mix some Lua in here and there). I've followed Kotlin for a long time waiting for a clear sign that Kotlin is worth learning after being burned by Scala. With co-routines I feel it's worth it, although I would desperately love being able to compile to native! That for me would be a killer feature. Currently I am learning Rust after dismissing Go for the task (love the simple concurrency, don't like the basicness of the language), and Swift (what a mess, I prefer ObjC!). Although I'll probably keep with Rust anyway because it's too impressive to not, the non-GC nature of Rust isn't important to my use-case, I basically just want a native Java. A native Kotlin would be perfect, as long as I can get high quality Gnome bindings. In fact, the main thing I would want out of a native Kotlin is around the native-code-interopt, and in my case that would be the libraries needed for native Gnome desktop application development.
I suspect some combination of
1) It's hard for a new language to get traction. Lower odds that a new startup! They see so many ruby and python shops adding Go to their stack and want to compete in that space. Kotlin's biggest market seems to be android devs and competing with Go puts them in the datacenter.
2) IDEA's IDEs have a better value proposition to devs working with statically typed languages. Appealing to current Java devs builds the Kotlin ecosystem, but appealing to dynamic language devs expands IDEA's customer base more.
1) It's hard for a new language to get traction. Lower odds that a new startup! They see so many ruby and python shops adding Go to their stack and want to compete in that space. Kotlin's biggest market seems to be android devs and competing with Go puts them in the datacenter.
2) IDEA's IDEs have a better value proposition to devs working with statically typed languages. Appealing to current Java devs builds the Kotlin ecosystem, but appealing to dynamic language devs expands IDEA's customer base more.
I completely agree.
Kotlin is close to the ideal language for me because it is just Java done right. If they want to go native and can do it without impairing any of the JVM usability, I guess go for it. But I don't see the point behind it. I don't develop native apps so maybe I just don't know enough, but it seems like Go and Rust have already satisfied the desire for modern natively compiled languages.
I feel the same way about the Kotlin compiling to Javascript ability. I write both the frontend and backend of web apps so I theoretically should be the exact target market for Kotlin to Javascript but I have no interest in it. ES6 and/or Typescript work better there and have an entire ecosystem around them. And even if they didn't work for me I'd prefer Dart which targets the frontend first instead of being an extra like Kotlin Javascript.
My advice to Kotlin: Stick with what you do best. Kotlin is on the exact right track on the JVM but I think all these different modes are going to make people more cautious about adopting it in any of them because they'll worry it's a jack of all trades but master of none.
Kotlin is close to the ideal language for me because it is just Java done right. If they want to go native and can do it without impairing any of the JVM usability, I guess go for it. But I don't see the point behind it. I don't develop native apps so maybe I just don't know enough, but it seems like Go and Rust have already satisfied the desire for modern natively compiled languages.
I feel the same way about the Kotlin compiling to Javascript ability. I write both the frontend and backend of web apps so I theoretically should be the exact target market for Kotlin to Javascript but I have no interest in it. ES6 and/or Typescript work better there and have an entire ecosystem around them. And even if they didn't work for me I'd prefer Dart which targets the frontend first instead of being an extra like Kotlin Javascript.
My advice to Kotlin: Stick with what you do best. Kotlin is on the exact right track on the JVM but I think all these different modes are going to make people more cautious about adopting it in any of them because they'll worry it's a jack of all trades but master of none.
In my eyes going native is nice for the distribution of command line apps (if they are static binaries), but also for avoiding the startup time of the jvm.
>[...] but it seems like Go and Rust have already satisfied the desire for modern natively compiled languages
Not for me. Go's type system is too primitive, and Rust is maybe too low level if you don't need the advantages compared to languages with a GC. So a language like Kotlin with a better type system (than go) fits nicely in between the two (that might change if Rust get's a GC type). Especially since it will probably have (or has already?) better tooling considering that Jetbreains is behind it.
>[...] but it seems like Go and Rust have already satisfied the desire for modern natively compiled languages
Not for me. Go's type system is too primitive, and Rust is maybe too low level if you don't need the advantages compared to languages with a GC. So a language like Kotlin with a better type system (than go) fits nicely in between the two (that might change if Rust get's a GC type). Especially since it will probably have (or has already?) better tooling considering that Jetbreains is behind it.
> but also for avoiding the startup time of the jvm.
Funny enough, all commercial JDKs do support AOT compilation to native code, and Oracle is slowly adding support for it as well.
Funny enough, all commercial JDKs do support AOT compilation to native code, and Oracle is slowly adding support for it as well.
Personally I'm intrigued by Kotlin Native as a replacement for Python and Go tools without requiring the JVM.
I find it's a fundamentally better language than both and so being able to write CLI tools and other smaller stuff in it would be nice while still being able to leverage Kotlin + JVM on the backend would also be nice.
I find it's a fundamentally better language than both and so being able to write CLI tools and other smaller stuff in it would be nice while still being able to leverage Kotlin + JVM on the backend would also be nice.
Same - a common language for JVM, JS, Native is both unique and intriguing to me. These are three really big targets. It's not that it would be unique in being a higher level compiled language or a language making Java development more fun to me, but being a common languge for among the most popular targets besides .NET today.
Scala already does that with scala.js (production-ready) and scala-native (don't know if production-ready, probably not since it's only at 0.1 and they want to implement a better GC instead of relying on boehm like now).
Just wanted to point that out in case you didn't know that already.
Just wanted to point that out in case you didn't know that already.
Fair enough, I might be wrong and there might more of a desire for Kotlin Native than I thought there would be.
Kotlin native sounds great to me! There is a big world outside the bloated JVM!
We've seen 1/10 the memory usage on golang vs java with similar performance, so properly executed there is a big opportunity in the native space.
We've seen 1/10 the memory usage on golang vs java with similar performance, so properly executed there is a big opportunity in the native space.
And the fact that it has a rather small standard library with JVM 6 compatibility means it's very very easy to adopt it into existing Java 6 (Android!) projects.
Kotlin is not just for android apps.
Kotlin is getting first class support on next generation Spring web framework with functional programming support - https://speakerdeck.com/sdeleuze/functional-web-applications...
it's almost done with first class support for vert.x which is a high-performance reactive webframework https://github.com/vert-x3/vertx-kotlin-common
The reactor project (erlang for the jvm?) is building first class support for kotlin https://github.com/reactor
I think its going to be a great year for building backend systems on jvm.
Kotlin is getting first class support on next generation Spring web framework with functional programming support - https://speakerdeck.com/sdeleuze/functional-web-applications...
it's almost done with first class support for vert.x which is a high-performance reactive webframework https://github.com/vert-x3/vertx-kotlin-common
The reactor project (erlang for the jvm?) is building first class support for kotlin https://github.com/reactor
I think its going to be a great year for building backend systems on jvm.
Kotlin is the best option for Android apps.
There are many languages for backends and tons of libraries. But there is hardly any substitute of Java in Android(if you don't consider JS solving every problem in this planet). If JetBrains only concentrate on building an ecosystem for android, it can become "the real Swift for android".
I built a dummy app for android in Kotlin. It was great. The same thing I tried in Scala(it didn't go very well).
There are many languages for backends and tons of libraries. But there is hardly any substitute of Java in Android(if you don't consider JS solving every problem in this planet). If JetBrains only concentrate on building an ecosystem for android, it can become "the real Swift for android".
I built a dummy app for android in Kotlin. It was great. The same thing I tried in Scala(it didn't go very well).
What I like about Kotlin is it's what you might call a "pragmatic Scala", and could find a sweet spot between Java and Scala where its added expressiveness allows it to shine, but Scala's complexity and performance issues aren't in evidence to scare the development managers into staying with Java.
Scala's complexity and performance issues
Is Kotlin really faster than Scala?
Is Kotlin really faster than Scala?
Scala's build times are legendarily horrible. Kotlin has similar compile times to Javac.
They are working on improving them though, specially with Dotty.
In any case they aren't as bad as C++ (at least until modules arrive).
In any case they aren't as bad as C++ (at least until modules arrive).
> In any case they aren't as bad as C++
Speaking as a fan of Scala, I find that scalac takes a noticeable amount of time even to compile trivial Hello World-type programs. Huge C++ codebases like Chromium or Boost take ages to compile, but I seriously doubt a comparable Scala codebase would be faster.
Speaking as a fan of Scala, I find that scalac takes a noticeable amount of time even to compile trivial Hello World-type programs. Huge C++ codebases like Chromium or Boost take ages to compile, but I seriously doubt a comparable Scala codebase would be faster.
I only dabbled a few times in Scala, but I do regularly use C++ on some side projects.
Do Scala compilation times get measured in hours?
Just the other day I gave up compiling Cocos2D-X, after it crossed the one hour threshold on my humble dual core, 8GB.
Do Scala compilation times get measured in hours?
Just the other day I gave up compiling Cocos2D-X, after it crossed the one hour threshold on my humble dual core, 8GB.
I also haven't used Scala at scale enough to say; the incremental compilation story is much better than templated C++ but I think compiling a large codebase from scratch would be quite slow, and slower than templated C++.
I think any design for generics that provides the same guarantees as C++ templates (type-safe, resolved at compile-time, value types aren't boxed) is necessarily going to cause long compilation times. The only other implementation I know of that checks all three boxes is Rust's, and so far generic Rust is even slower to compile than templated C++.
I think any design for generics that provides the same guarantees as C++ templates (type-safe, resolved at compile-time, value types aren't boxed) is necessarily going to cause long compilation times. The only other implementation I know of that checks all three boxes is Rust's, and so far generic Rust is even slower to compile than templated C++.
> I think compiling a large codebase from scratch would be quite slow, and slower than templated C++
It very much depends on which features of Scala you use. If you restrict yourself to the features available in Kotlin or other "better Java" languages, Scala compiler isn't much slower. Where Scala compiler gets really slow are implicits - so if you try to write Scala as if it were Haskell then you are probably in trouble.
It very much depends on which features of Scala you use. If you restrict yourself to the features available in Kotlin or other "better Java" languages, Scala compiler isn't much slower. Where Scala compiler gets really slow are implicits - so if you try to write Scala as if it were Haskell then you are probably in trouble.
> I think any design for generics that provides the same guarantees as C++ templates (type-safe, resolved at compile-time, value types aren't boxed) is necessarily going to cause long compilation times.
This isn't true of Ada, Modula-3 or Eiffel generics.
As for Rust, yes their compilation story still needs some improvements, but they still need to enable incremental compilation and cargo is yet to be able to handle binary dependencies across projects.
Where I suffered more in C++ compilation times was building the latest versions from either Swift or Rust, LLVM just takes ages to compile.
Thankfully I mostly use C++ as helping hand for Java/.NET.
This isn't true of Ada, Modula-3 or Eiffel generics.
As for Rust, yes their compilation story still needs some improvements, but they still need to enable incremental compilation and cargo is yet to be able to handle binary dependencies across projects.
Where I suffered more in C++ compilation times was building the latest versions from either Swift or Rust, LLVM just takes ages to compile.
Thankfully I mostly use C++ as helping hand for Java/.NET.
> This isn't true of Ada, Modula-3 or Eiffel generics.
I'm not familiar with those languages, but it appears that Eiffel and Modula-3 generics only work with boxed (implemented as pass-by-reference) types, and Eiffel doesn't have pass-by-value types at all.
It does look like Ada generics fulfil those three conditions.
I'm not familiar with those languages, but it appears that Eiffel and Modula-3 generics only work with boxed (implemented as pass-by-reference) types, and Eiffel doesn't have pass-by-value types at all.
It does look like Ada generics fulfil those three conditions.
In Eiffel, a value type is known as an expanded class and it can be given as default class attribute, or when declaring a variable. So generic instantiation will do the right thing depending on the class attributes.
Modula-3 supports value types just like any Algol language, you just need to provide the types you want when instatiating a generic module interface. Modula-3 generics work at module level.
Here is an example for numeric types, with a generic module for all numeric operations:
https://github.com/modula3/cm3/blob/d31f6ca184c66755317ba990...
Specialized to LONGINT.
https://github.com/modula3/cm3/blob/d31f6ca184c66755317ba990...
https://github.com/modula3/cm3/blob/d31f6ca184c66755317ba990...
It is a bit convoluted, but it isn't easy to track down a simple example.
Modula-3 supports value types just like any Algol language, you just need to provide the types you want when instatiating a generic module interface. Modula-3 generics work at module level.
Here is an example for numeric types, with a generic module for all numeric operations:
https://github.com/modula3/cm3/blob/d31f6ca184c66755317ba990...
Specialized to LONGINT.
https://github.com/modula3/cm3/blob/d31f6ca184c66755317ba990...
https://github.com/modula3/cm3/blob/d31f6ca184c66755317ba990...
It is a bit convoluted, but it isn't easy to track down a simple example.
Well Scala programs only get half compiled at command time, the other half is JIT at runtime.
But no not hours bad.. but say a 3 minute partial compile for a 1 line change is enough to kill your dev cycle. (Not sure it is 3 minutes bad for most projects these days, but its very hard to have a 2 second Scala compile)
But no not hours bad.. but say a 3 minute partial compile for a 1 line change is enough to kill your dev cycle. (Not sure it is 3 minutes bad for most projects these days, but its very hard to have a 2 second Scala compile)
You get much better compile times if you keep scala compiler running in daemon mode (in SBT or IDEA; AFAIK Gradle can't do this yet), so it gets more benefits from JVM HotSpot. It makes a tremendous difference (up to 10x) on larger code bases and in fact, I often get 1-5s incremental compile times on a 20 kLOC codebase. Another trick is to modularize the project and enable parallel compilation to speed up compiling everything from scratch.
As for C++ compile times, the major culprit are templates. Changing a single line of the implementation of a template requires to recompile all code using that template. Scala does not have this problem, because it has generics for most of the things that C++ templates are used, and generics support separate compilation.
As for C++ compile times, the major culprit are templates. Changing a single line of the implementation of a template requires to recompile all code using that template. Scala does not have this problem, because it has generics for most of the things that C++ templates are used, and generics support separate compilation.
Daemon does help a bit.
Gradle definitely has a daemon: https://docs.gradle.org/current/userguide/gradle_daemon.html
I think in Scala you can do similar "must recompile all" if you do things like change a global implicit.
> I often get 1-5s incremental compile times on a 20 kLOC codebase
20k is still toy project size though. Try incremental compile with 100k or 200k LOC. It gets bad.
Gradle definitely has a daemon: https://docs.gradle.org/current/userguide/gradle_daemon.html
I think in Scala you can do similar "must recompile all" if you do things like change a global implicit.
> I often get 1-5s incremental compile times on a 20 kLOC codebase
20k is still toy project size though. Try incremental compile with 100k or 200k LOC. It gets bad.
Gradle has a daemon, but I have some doubts if it really keeps scalac hot in memory. Last time I tried Gradle was weirdly slow with scala incremental compilation, while SBT worked like a breeze.
As for compiling 200k LOC - just split it into modules with sane dependencies and then you don't have that problem.
> I think in Scala you can do similar "must recompile all" if you do things like change a global implicit.
But there is a world of a difference between changing a signature of an implicit than changing an implementation of a template. If you change the implementation of an implicit, the only thing that needs recompiling is the class defining the implicit, nothing more.
As for compiling 200k LOC - just split it into modules with sane dependencies and then you don't have that problem.
> I think in Scala you can do similar "must recompile all" if you do things like change a global implicit.
But there is a world of a difference between changing a signature of an implicit than changing an implementation of a template. If you change the implementation of an implicit, the only thing that needs recompiling is the class defining the implicit, nothing more.
So it is not Delphi, but I still find it quite fast.
I get what you're saying, but I wouldn't refer to that as a performance issue without any context.
It hasn't been a big issue for me so far, but Kotlin often favours fast and compact where Scala favours generic and beautiful.
For example, in Scala, nullable references are just another monad object implemented in plain Scala, while in Kotlin they have a special syntax around Java's null pointer.
For example, in Scala, nullable references are just another monad object implemented in plain Scala, while in Kotlin they have a special syntax around Java's null pointer.
I wonder how Kotlin's JavaScript backend compars to Scala.js in Li Haoyi's list of fundamental reasons for betting on Scala.js:
http://www.lihaoyi.com/post/FromfirstprinciplesWhyIbetonScal...
I have a few concerns about Kotlin's JS backend:
How much can the complete JS bundle be optimized by an advanced whole-program optimizer like the Google Closure Compiler?
Kotlin for JS has no reflection, and I think JetBrains should not look into that as they said they are. But is there powerful compile-time code generation instead, e.g. through annotation processors?
Is there, or will there be, a healthy ecosystem of pure-Kotlin libraries that can be used with both the JVM and JS?
http://www.lihaoyi.com/post/FromfirstprinciplesWhyIbetonScal...
I have a few concerns about Kotlin's JS backend:
How much can the complete JS bundle be optimized by an advanced whole-program optimizer like the Google Closure Compiler?
Kotlin for JS has no reflection, and I think JetBrains should not look into that as they said they are. But is there powerful compile-time code generation instead, e.g. through annotation processors?
Is there, or will there be, a healthy ecosystem of pure-Kotlin libraries that can be used with both the JVM and JS?
> How much can the complete JS bundle be optimized by an advanced whole-program optimizer like the Google Closure Compiler?
JavaScript backend generates code understandable by static analyzers so it can be optimized. Anyway, we going to continue works in this area in near future.
> Kotlin for JS has no reflection, and I think JetBrains should not look into that as they said they are. But is there powerful compile-time code generation instead, e.g. through annotation processors?
Why do you think that reflection is a bad idea? Honestly, we don't have a final decision about it, it requires investigations and discussions. Note it's very important for us to have an ability to provide good tools (e.g IDE support) for features.
> Is there, or will there be, a healthy ecosystem of pure-Kotlin libraries that can be used with both the JVM and JS?
We will work on it.
JavaScript backend generates code understandable by static analyzers so it can be optimized. Anyway, we going to continue works in this area in near future.
> Kotlin for JS has no reflection, and I think JetBrains should not look into that as they said they are. But is there powerful compile-time code generation instead, e.g. through annotation processors?
Why do you think that reflection is a bad idea? Honestly, we don't have a final decision about it, it requires investigations and discussions. Note it's very important for us to have an ability to provide good tools (e.g IDE support) for features.
> Is there, or will there be, a healthy ecosystem of pure-Kotlin libraries that can be used with both the JVM and JS?
We will work on it.
> Why do you think that reflection is a bad idea?
OK, reflection isn't necessarily a bad idea. Clearly development tools need it, including future tools that run in the browser (e.g. an in-browser IDE). But I think that applications that are not development tools should not use reflection, because it interferes with static optimization, as the article that I linked in my original comment explains. So most libraries should probably not use reflection either. That means we need an alternative to reflection. For example, chapter 10 of _Kotlin in Action_ uses reflection to implement a serialization library. I think it would be better to use build-time code generation for that, even outside the JS use case (e.g. reflection interfers with optimization of Android app packages with ProGuard).
Edit: By the way, thanks for taking the time to respond.
OK, reflection isn't necessarily a bad idea. Clearly development tools need it, including future tools that run in the browser (e.g. an in-browser IDE). But I think that applications that are not development tools should not use reflection, because it interferes with static optimization, as the article that I linked in my original comment explains. So most libraries should probably not use reflection either. That means we need an alternative to reflection. For example, chapter 10 of _Kotlin in Action_ uses reflection to implement a serialization library. I think it would be better to use build-time code generation for that, even outside the JS use case (e.g. reflection interfers with optimization of Android app packages with ProGuard).
Edit: By the way, thanks for taking the time to respond.
For fun, I've been working on a simple hobby web server in Kotlin that wraps Jetty: https://github.com/danneu/kog
I think Kotlin is the statically-typed language I've been waiting for, especially with the team's interest in native and JS targets.
I think Kotlin is the statically-typed language I've been waiting for, especially with the team's interest in native and JS targets.
Do you have any opinions on Kotlin vs Clojure? are you liking Kotlin more?
I think static typing + solid IDE support is too useful to pass up, and that's what Kotlin has.
But Kotlin also has simplicity that, for example, Scala doesn't. I tried Clojure after spending a couple months with Scala and giving up, and then I used Clojure fulltime for 3+ years.
Eventually, I felt like I was hitting a ceiling with Clojure since it lacked good static analysis. I moved to Node because I felt like, if I'm going to use a dynamically-typed language, I might as well use the ubiquitous one. Also, Clojure was a hard sell to other developers I would meet.
What Clojure does have is an ecosystem of simplicity that I hope the Kotlin ecosystem will adopt.
For example, compare ztellman's http://aleph.io/ (Clojure) to Java's Netty or to the somewhat mind-numbing https://docs.oracle.com/javase/8/docs/api/java/util/concurre.... And compare Clojure's Ring to any Java web framework.
Even Spark, Java's simplest option afaict, doesn't have real middleware, just before/after "filters". That's why I went with the `(Request) -> Response` signature over the `(Request, Response) -> Unit` signature.
There's also ClojureScript's integration and tooling which are pretty impressive these days while Kotlin's JS support is still fledgling.
Though these are the impressions of someone who has only been using Kotlin for a few months without a Java background. And it's not like anyone should be using my lil framework in production, it's just a hobby.
But Kotlin also has simplicity that, for example, Scala doesn't. I tried Clojure after spending a couple months with Scala and giving up, and then I used Clojure fulltime for 3+ years.
Eventually, I felt like I was hitting a ceiling with Clojure since it lacked good static analysis. I moved to Node because I felt like, if I'm going to use a dynamically-typed language, I might as well use the ubiquitous one. Also, Clojure was a hard sell to other developers I would meet.
What Clojure does have is an ecosystem of simplicity that I hope the Kotlin ecosystem will adopt.
For example, compare ztellman's http://aleph.io/ (Clojure) to Java's Netty or to the somewhat mind-numbing https://docs.oracle.com/javase/8/docs/api/java/util/concurre.... And compare Clojure's Ring to any Java web framework.
Even Spark, Java's simplest option afaict, doesn't have real middleware, just before/after "filters". That's why I went with the `(Request) -> Response` signature over the `(Request, Response) -> Unit` signature.
There's also ClojureScript's integration and tooling which are pretty impressive these days while Kotlin's JS support is still fledgling.
Though these are the impressions of someone who has only been using Kotlin for a few months without a Java background. And it's not like anyone should be using my lil framework in production, it's just a hobby.
Clojure and Kotlin are, for me, the brightest stars in the JVM sky. However, I fear Clojure adoption has peaked at its current low rate probably because it was never aimed at the corporate Java world as Kotlin is. Clojure appeals more to the software artisan which is a valuable niche in itself but its syntax, which is its strength, is so different from Java's that I think it is rarely seen as an alternative to Java.
I wouldn't touch Java if I could write something in Kotlin instead. I'm using Swift on a daily base and while it still has it's issues (compile times, breaking changes) it's a great language to work in and extremely similar to Kotlin.
Better type safety means less crashes.
Better type safety means less crashes.
I've been very happy writing Kotlin backend code for the last fourteen months or so.
Definitely excited. It's an awesome JVM language.
Definitely excited. It's an awesome JVM language.
I'm investigating Kotlin. Do you have references, blogs etc to suggest ?
Through this blog
https://antonioleiva.com/kotlin/
And his book I was able to become fairly productive in the language in only a few weeks. I was familiar with Scala however.
The automatic conversion of java to Kotlin in Intelli J's IDEs also helped immensely.
For the most part I found the official Kotlin reference documentation to be excellent and more than enough to move from a strong Java and Groovy background.
I follow /r/kotlin as well. Advanced idioms and stuff I've just picked up looking through GitHub repositories.
What I really like about Kotlin is just about everything "works" as it should or you can usually write a Google search that will reference Stack Overflow. I don't have to dig much to find answers and in the absolute worst case I can just drop back to Java and do it the classic way.
I follow /r/kotlin as well. Advanced idioms and stuff I've just picked up looking through GitHub repositories.
What I really like about Kotlin is just about everything "works" as it should or you can usually write a Google search that will reference Stack Overflow. I don't have to dig much to find answers and in the absolute worst case I can just drop back to Java and do it the classic way.
what backend framework are you using ? i have been pretty interested in trying out spring boot 5 or vertx
Vert.x though recently I switched back to Dropwizard for a prototype... it works mostly fine, but I think I've kinda fallen in love with Vert.x
I think the only thing I find really annoying about Vert.x is the lack of built-in JSON -> object binding. I've written some cheap glue code to fix that though.
I think the only thing I find really annoying about Vert.x is the lack of built-in JSON -> object binding. I've written some cheap glue code to fix that though.
are you using Jackson or gson to do this ? I have heard lots of conflicting advice on this... so am curious on what you are doing
I use Jackson. I am much more familiar with it and the Jackson Kotlin module works nicely out of the box (https://github.com/FasterXML/jackson-module-kotlin). Also Vert.x is using Jackson under the hood so one less critical dependency to think about.
I think Gson is more common on the Android side of things where Kotlin has (I believe) a lot more popularity than on the backend.
I think Gson is more common on the Android side of things where Kotlin has (I believe) a lot more popularity than on the backend.
The post specifically mentions using Kotlin Javascript to develop React applications. Are there any simple examples out there showing this? I'm not seeing any after a quick google search and look through the docs.
Developing a modern frontend app is complex enough with Javascript or Typescript. It's pretty hard to ask people to figure it out from scratch in Kotlin by just saying that it's possible but not showing how.
Developing a modern frontend app is complex enough with Javascript or Typescript. It's pretty hard to ask people to figure it out from scratch in Kotlin by just saying that it's possible but not showing how.
It was mentioned on the Kotlin slack that Jetbrains would make some examples available within a few weeks on using Kotlin JS including using it with React.
kotlinjs is very interesting to me - anyone have experience with writing kotlin and typescript and can compare?
Why couldn't they have used "func" for functions, like so many languages do, instead of "fun"?
I don't think of 'func' as a standard. Off the top of my head, you can see "defun", "fn", "def", "function", and on and on in various languages. I don't see much agreement across the board.
does anyone know of a place that compares syntax like this across languages? I've found myself often wondering if there is consensus for certain features or syntax.
Not exactly, but on rosettacode.org (http://rosettacode.org/wiki/Rosetta_Code) you can see tons of languages implementing the same toy programs, so they will often be using comparable language features in the process.
If using 4 wide space/tabs, the function body will line up with the function name when using "fun". Maybe not the reason, but it is a reason.
Because it's fun.
Does this mean we can now build a full React Native app using only Kotlin?
We going to publish more materials about JavaScript in the next few weeks. Including with using React.
Will there be anything about angular?
Also, is it possible to set up kotlin source code in gradle to compile both to JS and the JVM at the same time? I'm specificially thinking that it'd be nice to "share" code between front and backend for some logic and data model definitions.... I think that'd be a killer feature.
Also, is it possible to set up kotlin source code in gradle to compile both to JS and the JVM at the same time? I'm specificially thinking that it'd be nice to "share" code between front and backend for some logic and data model definitions.... I think that'd be a killer feature.
If you can, make sure you write your Gradle build scripts in Kotlin also (possible since Gradle 3.0 was released 6 months ago) instead of Apache Groovy, then Kotlin will be the only language you need for anything!
The only significant sources of variance were the following:
a) Groovy's support for functional programming is starting to show its age. It worked with everything, though.
b) The Scala 2.12 compiler has at least one bug that appears to affect its interaction with Java 8 lambdas (in particular, in at least one case expr.method() and (expr).method() will not pass the compiler's typecheck, but { val x = expr; x.method() } does. (All three pass IntelliJ's typechecker for Scala.) Outside of this (aggravating) issue and slower build times, it did work.
c) Java works well with everything but ends up being quite verbose, especially in regards to a functional programming style (no surprise there).
d) Kotlin (1.0) works well with everything and is relatively succinct except for Mockito due to everything defaulting to 'final' - but it appears that Kotlin 1.1 fixes this with a compiler plugin.
Based on my experience with all four languages, I would definitely try adding Kotlin to projects. It seems to be surprisingly mature and stable given how much less time it has spent in development (relative to the other three languages.)