Why couldn't they have used "func" for functions, like so many languages do, instead of "fun"?
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.
Kotlin 1.1 Released with JavaScript Support, Coroutines and more
81–89 of 89 posts
Re: Kotlin 1.1 Released with JavaScript Support, Coroutines and more
#82Earlier quoted context omitted.
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…
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.
Re: Kotlin 1.1 Released with JavaScript Support, Coroutines and more
#83Earlier quoted context omitted.
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 time…
> 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…
> 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.
Re: Kotlin 1.1 Released with JavaScript Support, Coroutines and more
#84Earlier quoted context omitted.
> 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…
> 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.
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.
Re: Kotlin 1.1 Released with JavaScript Support, Coroutines and more
#85A few weeks ago I wrote the same application four times in four different JVM languages: Java, Groovy, Scala, and Kotlin, with a particular focus on the application using functional techniques and types as well as being reactive. I also included as goals complete test coverage with a preferred test framework from each language and complete build tooling, all within a single Gradle project. The only significant source…
> 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.
Re: Kotlin 1.1 Released with JavaScript Support, Coroutines and more
#86Earlier quoted context omitted.
Curious, if you were aiming at writing in a functional programming style, why didn't you try Clojure?
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.
Re: Kotlin 1.1 Released with JavaScript Support, Coroutines and more
#87Does 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.
Re: Kotlin 1.1 Released with JavaScript Support, Coroutines and more
#88Earlier quoted context omitted.
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.
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!
Re: Kotlin 1.1 Released with JavaScript Support, Coroutines and more
#89Earlier quoted context omitted.
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 nich…
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.