24 ms·

Kotlin: A Language with a Bright Future

adamnemecek 9y ago
I agree 100%. Kotlin compiles to JVM, JS and very soon also to native via LLVM. That means you can ship a web app (both backend & frontend) and mobile clients (for android and soon iOS) in one language. This is unprecedented. For JS, you can use all you favorite front-end frameworks like react (here's an example by JetBrains themselves https://github.com/Kotlin/kotlin-fullstack-sample https://github.com/Kotlin/kotlin-fullstack-sample) or cycle. And you can import typescript definitions. Also first class IDE integration. So yeah, bright future is an understatement. I guess clojure/clojurescript and scala.js are somewhat similar however I feel like Kotlin has an insane amount of momentum behind it right now.
- djm158 9y ago
  You could also do this with JavaScript correct? Node.js back end with whatever front end framework and then use something like react native for mobile?
  - deleted 9y ago
    [deleted]
  - swsieber 9y ago
    That's not quite there though - with React Native, your still running the js engine to run the JavaScript (but your at least using native widgets). With Kotlin you'll be running compiled code. If you wanted to right now though, you could (should be able to?) use Kotlin to build a React Native app with it's just target.
    - brango 9y ago
      I was looking into this yesterday. Apparently while there's support for transpiling Kotlin -> JS, more work would be needed to support transpiling for react native[1]. Not sure why. [1] https://blog.jetbrains.com/kotlin/2017/04/use-kotlin-with-npm-webpack-and-react/ https://blog.jetbrains.com/kotlin/2017/04/use-kotlin-with-np...
  - adamnemecek 9y ago
    But then you'd be writing JavaScript and who wants that. TypeScript is maybe ok-ish but TS is just putting a lipstick on a pig. Like, ignoring other issues, JVM at least has decent concurrency and with quasar, you get processes similar to erlang.
    - rictic 9y ago
      What about the other side of that coin. Does a small amount of idiomatic Kotlin compile down to a small amount of JS, or a large amount (in bytes, after gzip)?
      - adamnemecek 9y ago
        I don't have extensive experience with it but it's not too bad compared with other JS transpilers.
- qznc 9y ago
  > This is unprecedented. C/C++ can do that if you accept Emscripten. Java can do that if you accept GWT.
  - swsieber 9y ago
    Haxe can do it as well. Though I think what really sets it apart (on the web side) is that it interops pretty well with other js libs. I think what sets it apart is the interopability with it's current targets. Really slick Edit:fixed typo
  - adamnemecek 9y ago
    > C/C++ can do that if you accept Emscripten. Yeah, pls no. > Java can do that if you accept GWT. Yeah, I don't. Google abandoned it, you should too.
    - Finnucane 9y ago
      Still, they count as 'precedents'.
      - adamnemecek 9y ago
        Precedents are nice and all but I want something I can ship stuff in.
    - swsieber 9y ago
      Google still ships stuff using GWT - they just talk about it much.
      - adamnemecek 9y ago
        They maintain legacy stuff written in GWT, I dont know any new projects that use it.
        qznc 9y ago
        Vaadin is built on GWT and seems quite alive. https://vaadin.com/ https://vaadin.com/
- thomascgalvin 9y ago
  Kotlin is the first language I've gotten excited about in a long time. It's close enough to Java that I can get my engineers up to speed in a few hours, but it removed a lot of the bloat and tedium. The JNV / JS / Native targets are also really promising, though I haven't played around with them much. The JS and Native runtimes are a bit limited since they don't include the Java standard library, from what I can tell.
  - adamnemecek 9y ago
    > The JS and Native runtimes are a bit limited since they don't include the Java standard library, from what I can tell. I think that they ship with the Kotlin standard library which is close enough.
- pankajdoharey 9y ago
  Cross Compilation isnt unprecedented various lisps have been doing it for decades. There are many lisp solutions thats do it already. Including Clojure which ships to Backend Frontend and Mobile Apps. Nothing new here.
  - adamnemecek 9y ago
    Not talking about cross-compilation, I'm talking about having a industry-grade, production ready language that I can ship stuff in like yesterday. > various lisps have been doing it for decades There's an insanely long road from having a prototype of a language to having a production ready thing. There isn't a lisp where I could achieve the same experience.
    - pankajdoharey 9y ago
      >I'm talking about having a industry-grade, production ready language. It isnt a mature enough language to be trusted so soon, no body has a sufficient enough industry grade experience with it. Especially with large code bases.
      - adamnemecek 9y ago
        > It isnt a mature enough language to be trusted so soon, I mean, Google adopted it as a first class citizen language on android which counts for something. > no body has a sufficient enough industry grade experience with it. Especially with large code bases. There aren't really any "new" features in Kotlin, as in features you haven't seen before. If you've been programming Java and know some Haskell/Ocaml or idk what else, you are good to go.
        geodel 9y ago
        > I mean, Google adopted it as a first class citizen language on android which counts for something. Something but not much. It works on JVM, talk to all Java libs and tooling is taken care by Intellij. It is low or little effort from Google to support. Unlike other language fans who clamor for Android support from Google, here hard work is done by someone else. So Google support looks most like a co-branding deal.
- randomThoughts9 9y ago
  > This is unprecedented. Don't get me wrong, I like Kotlin, but Ceylon did the multi platform thing much better. They have real platform modules, built into the language (not just a build tool trick), and a language specification that was written from the start with multiple platforms in mind. But it never took off (yet), and Kotlin's support is good enough, so it will have to do I guess :).
- beagle3 9y ago
  Nim doesn't have a JVM backend, but it does C, C++, Objective-C, JavaScript, LLVM (not yet ready for prime time, but almost there), iOS, Android, and more. Lisps have been doing this since forever (including the now defunct LinJ for Java which compiled into code that was very often mistaken for hand-written Java). Hell, Emscripten takes everything LLVMable and gives it that ability. > This is unprecedented. Only for sufficiently narrow "this".
- stewbrew 9y ago
  Since the kotlin runtime is rather small, you still have to deal with platform differences. I like kotlin for several reasons but this one isn't on the top of my list. If you like cross-platform development, you might want to check out haxe.
- venturis_voice 9y ago
  Hi, thanks for commenting on our recent blog post. We share and discuss all our content on Venturi’s Voice Slack group. Seeing as you know quite a bit about this topic it would be great if you joined the conversation on there. We’re a new community based around the blogs and podcasts we release everyday at Venturi. We aim to consistently deliver valuable content to our candidates - but we know there is always room for improvement, so your feedback would really help us out! The group’s pretty quiet at the moment whilst we’re building up the community but stick with us as we’re aiming to grow it rapidly. https://publicslack.com/slacks/https-venturisvoice-slack-com/invites/new https://publicslack.com/slacks/https-venturisvoice-slack-com...
meddlepal 9y ago
I have been using Kotlin in the backend (along with Python) since late 2015 at Datawire.io and it is a pleasure to work with.
- duiker101 9y ago
  May I ask you what frameworks and everything are you working with? I've been enjoying django for a while now but I am really looking for new excuses to use more kotlin
  - meddlepal 9y ago
    I like to keep it simple. I've never been a big fan of most big "mainstream" JVM frameworks like Spring. I much prefer using libraries and writing a small amount of glue code to keep it understandable rather than making others become framework competent before hopping on a project. For web services I use Sparkjava but I'm thinking of moving to Javalin or http4k because Sparkjava has really slow release cycles. JSON is either Gson or Jackson. I prefer Jackson just because I know it better but they're both great. I use JDBI for database work but I don't have too much of that in my backend right now. GRPC for cross service communication. Back in 2015/2016 I used Vert.x a bunch but I really didn't like the async programming model. YMMV. Generally I stick to using well known / common libraries written for Java and then later look for a Kotlin version if I have time to dick around a bit. I think this is what I love the most about Kotlin is the great interop with existing Java libraries.
kevinherron 9y ago
I love Kotlin. It's the sweet spot between Java and Scala. Been using it for backend stuff since it went 1.0. Coroutines are a game changer for a lot of the work I do. Really excited to see how Native progresses as well. I've got a handful of projects what would benefit from having the 90% core written in Kotlin with some JVM and Native portions plugged in, ultimately meaning the library is available on both JVM and Native.
ravirajx7 9y ago
Is the link broken?
- wootie512 9y ago
  Yea it is for me right now. Looks like the entire Venturi Group site is down.
- deleted 9y ago
  [deleted]
- thepratt 9y ago
  Have the same issue, it looks like someone deleted their entire site, or at least unlinked it.
- stareatgoats 9y ago
  downside of getting on the first page of HN I suppose
- mk321 9y ago
  Mirror: https://web.archive.org/web/20171120143056/http://www.venturi-group.com/blog/getting-started-kotlin/ https://web.archive.org/web/20171120143056/http://www.ventur... or: http://webcache.googleusercontent.com/search?q=cache%3Ahttp://www.venturi-group.com/blog/getting-started-kotlin/ http://webcache.googleusercontent.com/search?q=cache%3Ahttp:...
- venturis_voice 9y ago
  Hi sorry about that our website experienced some technical difficulties just after I posted this, typical I know. We're back up and running now though
mumphster 9y ago
Cached: http://webcache.googleusercontent.com/search?q=cache:http://www.venturi-group.com/blog/getting-started-kotlin/ http://webcache.googleusercontent.com/search?q=cache:http://...
pmelendez 9y ago
Honest question. I have been checking Kotlin since a while but haven't found a compelling case for me to start using it. All the features I have seen so far are syntactic sugar. Even the article quote something around those lines: “The syntax for Kotlin, like Apple’s Swift, is clean and modern. The reaction amongst developers learning Kotlin is not dissimilar to the initial experiences with Ruby years ago. The syntax is so intuitively designed that even without any previous exposure it’s almost possible to guess it.” The question would be: Am I missing something? Is syntax the only reason that makes people excited about it? or are there any new abstractions/ideas that are exclusive for Kotlin?
- jarym 9y ago
  Depends on your definition of syntactic sugar - for instance, the coroutines stuff is very intuitive and makes code far more readable and easier to work with. It all compiles down to stuff that a Java decompiler will be able to read back to Java. But that's just one example and a subjective one at that. Not everyone will feel the same way and for those who don't there's no compelling reason to 'start using Kotlin' - if what you have works then stick with it. There's also Kotlin native and Kotlin JS - allowing Kotlin code to be compiled to native binaries as well as to javascript is pretty compelling and will (imo) pay dividends. Both are still very much in development though.
- lmm 9y ago
  To have a clean/nice/familiar syntax in a language with a semi-decent type system is actually a pretty big deal. What're the other options? Java and C# are pretty cumbersome, Haskell and OCaml (and to a certain extent F# and Rust) look weird, Swift/C#/F# are to a certain extent tied to proprietary platforms, and while Scala actually has a nice core syntax the culture of its libraries tended to hide that away under a pile of sigils.
  - pron 9y ago
    What feels cumbersome to some may not feel cumbersome to others, or they may not care as much about this, because, for example, they can feel that concrete code is less important than design, and considering that a minor reduction (at best) in the time spent working with code translates to negligible (or even negative) overall contribution to the project, and may certainly not justify sacrificing the many other conveniences that come with using a hugely popular, familiar and well-tooled language.
lmm 9y ago
As a Scala programmer, Kotlin always feels like a language that frustratingly almost gets it, but is infuriatingly unwilling to listen to experience of what works in large codebases. Look at the examples on https://philipnilsson.github.io/Badness10k/escaping-hell-with-monads/ https://philipnilsson.github.io/Badness10k/escaping-hell-wit... - I think Kotlin has literally every one of those ad hoc solutions built into the language, but stubbornly avoids making the generalisation. In small examples ad hoc solutions look great, but to succeed in large codebases a language needs a generality and consistency that Kotlin lacks. E.g. already there's no way to reuse logic between code paths that operate on Kotlin nullable types, Java Options (needed for compatibility with Java streams or more generally other JVM libraries), or rust-style Result types (for which there are several Kotlin libraries already, because it's a very useful concept and the language mostly has the facilities to support it), even though all three behave almost identically and you would often want to do the same thing in all three cases. But since the language won't let you represent what these types have in common, your only option is to copy/paste the code.
- pron 9y ago
  > but is infuriatingly unwilling to listen to experience of what works in large codebases. I don't think so. Java has been used successfully in large codebases, probably more so than Scala, and Kotlin, like Go, is a language following Java philosophy. > I think Kotlin has literally every one of those ad hoc solutions built into the language, but stubbornly avoids making the generalisation. 1. Ask yourself why does it stubbornly avoid making such generalizations. There are very, very good reasons. 2. Kotlin has delimited continuations, which express anything monads can (with a minor, unimportant caveat, which has to do with the particular features of Kotlin coroutines), in a way that blends much more nicely with imperative languages features that abound in both Kotlin and Scala, and composes much more nicely than monads (although that requires a feature currently absent an Kotlin's coroutines, but the feature is largely unnecessary for the kind of code Kotlin aims at). > already there's no way to reuse logic between code paths that operate on Kotlin nullable types, Java Options That's not really accurate. Kotlin does this blending at least as well if not better than Java. Java options are not really intended to be used in the same way they're used in Scala. > or rust-style Result types (for which there are several Kotlin libraries already, because it's a very useful concept and the language mostly has the facilities to support it) Those are not idiomatic in Kotlin, and some (like me) think that the Kotlin idioms are better, at least for the kind of code it aims to support. > But since the language won't let you represent what these types have in common, your only option is to copy/paste the code. I don't think it is a language's job to support all idioms out there, even if they can be useful in some circumstances. Languages following the Java philosophy -- as opposed to Scala -- aim to be at least somewhat opinionated, and encourage similar coding patterns in all cases, even if some idiom can be marginally better suited in some specific case. It's a tradeoff between code homogeneity and being "multi-paradigm", which can only be settled by the values of the language. There is no right or wrong answer here. Kotlin's values are very, very different from Scala (even if many features are shared), which is why Kotlin was created in the first place. Its designers wanted a modern language in the Java tradition (I know that from directly talking to them), not in the Scala tradition.
pankajdoharey 9y ago
To me Kotlin feels like the most overrated copy of Scala.
rb808 9y ago
I like Kotlin, but I'm thinking of just concentrating on Java and giving up on Scala and Kotlin. Scala was much better than Java but now the gap has closed and while its still nice to work with, I feel most applications would be better to stick to mainstream Java. Kotlin is interesting but after Scala experience I'm reluctant to invest all over again. Is it worth it?
- taesis 9y ago
  May I ask where you invested your time in learning Scala (e.g. reading the red book, studying type theory, syntax + stdlib + collections, etc.)? I found I could read simple Kotlin in a couple afternoons, and after a couple weekends, I felt pretty comfortable with it. The only difficult concepts to wrap your head around, I'd say, are type safe builders [1] and coroutines [2], but you certainly don't need to know those to be productive in the language. To answer your specific question, however, if you're doing Android development it's worth it :) otherwise, it's up to you/your specific situation. [1]: https://kotlinlang.org/docs/reference/type-safe-builders.html https://kotlinlang.org/docs/reference/type-safe-builders.htm... [2]: https://kotlinlang.org/docs/reference/coroutines.html https://kotlinlang.org/docs/reference/coroutines.html
- parmesan 9y ago
  If you're familiar with Java, adopting Kotlin is just a matter of setting it up and reading the docs frequently for a week or so. If you want to, Kotlin can be practically Java without the over-verbosity and some nice extra features. In time you'll be writing less Java-Kotlin and more Kotlin-Kotlin, if you get what I mean. To me the syntax and structure is so resembling to Java that I haven't really had any confusions at all, most of my gotta-read-the-docs moments involve the concepts that you can use that aren't present in Java (along with the `when` version of `switch` which I've grown to love).
deleted 9y ago
[deleted]
bencollier49 9y ago
As a Python and Java programmer, Kotlin hits the sweet spot for me with the type safety of Java (+ ecosystem) together with a clean and modern syntax. All whilst avoiding adding clever/stupid things (cf. Scala, Go, Rust).
pankajdoharey 9y ago
Does anyone remember Groovy this is just a fad Kotlin would be forgotten with time, i fail to see the real technical innovation in Kotlin.
- nerdponx 9y ago
  Since you seem to have some technical expertise in this area and strong opinions, it would be nice if you explained why you felt that way, for the benefit of us who are not experts. AFAIK Groovy is currently in use at lots of very major companies.
- pjmlp 9y ago
  At least for Android development it will be quite an improvement. Google made their Java fork, for Java 7 and 8 they only cherry picked features, even after migrating to OpenJDK. The newly introduced bytecodes are not supported and the situation will only get worse with Java 9 and the new OpenJDK release schedule. Specially given the lack of updates across the Android eco-system. So only something like Kotlin allows to enjoy modern JVM languages while targeting Android.
edpichler 9y ago
Could someone tell me if Kotlin and TypeScript are similar solutions? I put both on my "next reads" list.
- lmm 9y ago
  TypeScript has a marginally weaker type system (it's structural and has soundness issues with variance) and is more focused on being close to JS; it has very good ecosystem penetration (e.g. a lot of libraries publish typescript definitions even if they're not written in typescript). Kotlin is intended as a general-purpose language that can also compile to JS. So I'd say it depends on how web-oriented you are.
  - edpichler 9y ago
    Got it, thanks for your summary.
lobo_tuerto 9y ago
Woops 404 on the link.
- venturis_voice 9y ago
  Hey sorry about that annoyingly our website went down not long after I posted the link, it's working again now though if you wanna dive back in
rdsubhas 9y ago
I'm neither pro nor con with Kotlin, but let's look at history and parallels. At its peak, Eclipse released Xtend. At that point, Eclipse was the IntelliJ of today, everyone assumed Xtend would be the next Java with full support of Eclipse tooling. Today, well, anyone remembers it? But its still there, check the features: http://www.eclipse.org/xtend/documentation/index.html http://www.eclipse.org/xtend/documentation/index.html. You will see thousands of articles on kotlin vs java, but only a handful on kotlin vs xtend, because of the cycle. Groovy. Same cycle, same result. Javascript has a large share of syntactic forks. All of them had this hype-cycle. Coffeescript was "de-facto way" to write cross-browser eloquent javascript at one point. There are few lessons from history: Syntactic language forks are what they are - forks. It takes equal amount of tooling and expertise to maintain them. When the next two versions of Java releases, the hype cycle will again turn tides. "X is the better Y", "Groovy is the better Java" - never, there is only one Java, there is no better Java. The best approach is to make the language itself extensible. Look at ES-next and babel. Every language addition is a proposal, and proposals can be implemented as language plugins with stages 3/2/1/0. This effectively rendered most syntactic forks almost meaningless and unnecessary. Have an idea? Extend to the language directly! The most important part - tooling - which is eslint, AST parsing, intermediate representations, code formatting, etc - have been shifted to work on top of language plugins. Now some of you will talk against babel, and how different projects use different babel settings - but given all the history, babel is the best way to pragmatically evolve a language we've ever had so far. Java has a longer mature JSR and language proposal process, just like ES. I really regret that Jetbrains decided to create yet another language fork, while being in the position to create the next babel for java. Will Kotlin be different from all the previous cycles? Only real 2020 will tell, but until then, the only reference available is history.
russellbeattie 9y ago
This may not be the most educated opinion, but I tend to think of "languages" that compile to the JVM as just elaborate macros. My reasoning is that in order to use Kotlin (or Scala, Groovy, etc.), you will inevitably have to know Java very well, as most of the language is just syntactic sugar, and you'll almost always have to interact with standard libraries and SDKs written for use with Java. A language isn't a "real" language unless you can live in it and be blissfully ignorant of anything else. I don't need to know C in order to use Go, or Python. I don't need to know Ruby in order to use JavaScript. But it'll be relatively impossible to write code in Kotlin without interacting with Java constantly. Which means context switching and maybe even bugs.
iLemming 9y ago
I skimmed through the comments, looked at code examples - they hurt my eyes. Read arguments of Scala people. Read about C# vs Java. For the life of me I don't get it. Why people simply wouldn't use Clojure?
venturis_voice 9y ago
Hi all, thanks for commenting on our recent blog post. We share and discuss all our content on Venturi’s Voice Slack group. Seeing as you know quite a bit about this topic it would be great if you joined the conversation on there. We’re a new community based around the blogs and podcasts we release everyday at Venturi. We aim to consistently deliver valuable content to our candidates - but we know there is always room for improvement, so your feedback would really help us out! The group’s pretty quiet at the moment whilst we’re building up the community but stick with us as we’re aiming to grow it rapidly. https://publicslack.com/slacks/https-venturisvoice-slack-com/invites/new https://publicslack.com/slacks/https-venturisvoice-slack-com...

I agree 100%. Kotlin compiles to JVM, JS and very soon also to native via LLVM. That means you can ship a web app (both backend & frontend) and mobile clients (for android and soon iOS) in one language. This is unprecedented. For JS, you can use all you favorite front-end frameworks like react (here's an example by JetBrains themselves https://github.com/Kotlin/kotlin-fullstack-sample https://github.com/Kotlin/kotlin-fullstack-sample) or cycle. And you can import typescript definitions. Also first class IDE integration. So yeah, bright future is an understatement. I guess clojure/clojurescript and scala.js are somewhat similar however I feel like Kotlin has an insane amount of momentum behind it right now.

djm158 9y ago
You could also do this with JavaScript correct? Node.js back end with whatever front end framework and then use something like react native for mobile?
- deleted 9y ago
  [deleted]
- swsieber 9y ago
  That's not quite there though - with React Native, your still running the js engine to run the JavaScript (but your at least using native widgets). With Kotlin you'll be running compiled code. If you wanted to right now though, you could (should be able to?) use Kotlin to build a React Native app with it's just target.
  - brango 9y ago
    I was looking into this yesterday. Apparently while there's support for transpiling Kotlin -> JS, more work would be needed to support transpiling for react native[1]. Not sure why. [1] https://blog.jetbrains.com/kotlin/2017/04/use-kotlin-with-npm-webpack-and-react/ https://blog.jetbrains.com/kotlin/2017/04/use-kotlin-with-np...
- adamnemecek 9y ago
  But then you'd be writing JavaScript and who wants that. TypeScript is maybe ok-ish but TS is just putting a lipstick on a pig. Like, ignoring other issues, JVM at least has decent concurrency and with quasar, you get processes similar to erlang.
  - rictic 9y ago
    What about the other side of that coin. Does a small amount of idiomatic Kotlin compile down to a small amount of JS, or a large amount (in bytes, after gzip)?
    - adamnemecek 9y ago
      I don't have extensive experience with it but it's not too bad compared with other JS transpilers.
qznc 9y ago
> This is unprecedented. C/C++ can do that if you accept Emscripten. Java can do that if you accept GWT.
- swsieber 9y ago
  Haxe can do it as well. Though I think what really sets it apart (on the web side) is that it interops pretty well with other js libs. I think what sets it apart is the interopability with it's current targets. Really slick Edit:fixed typo
- adamnemecek 9y ago
  > C/C++ can do that if you accept Emscripten. Yeah, pls no. > Java can do that if you accept GWT. Yeah, I don't. Google abandoned it, you should too.
  - Finnucane 9y ago
    Still, they count as 'precedents'.
    - adamnemecek 9y ago
      Precedents are nice and all but I want something I can ship stuff in.
  - swsieber 9y ago
    Google still ships stuff using GWT - they just talk about it much.
    - adamnemecek 9y ago
      They maintain legacy stuff written in GWT, I dont know any new projects that use it.
      - qznc 9y ago
        Vaadin is built on GWT and seems quite alive. https://vaadin.com/ https://vaadin.com/
thomascgalvin 9y ago
Kotlin is the first language I've gotten excited about in a long time. It's close enough to Java that I can get my engineers up to speed in a few hours, but it removed a lot of the bloat and tedium. The JNV / JS / Native targets are also really promising, though I haven't played around with them much. The JS and Native runtimes are a bit limited since they don't include the Java standard library, from what I can tell.
- adamnemecek 9y ago
  > The JS and Native runtimes are a bit limited since they don't include the Java standard library, from what I can tell. I think that they ship with the Kotlin standard library which is close enough.
pankajdoharey 9y ago
Cross Compilation isnt unprecedented various lisps have been doing it for decades. There are many lisp solutions thats do it already. Including Clojure which ships to Backend Frontend and Mobile Apps. Nothing new here.
- adamnemecek 9y ago
  Not talking about cross-compilation, I'm talking about having a industry-grade, production ready language that I can ship stuff in like yesterday. > various lisps have been doing it for decades There's an insanely long road from having a prototype of a language to having a production ready thing. There isn't a lisp where I could achieve the same experience.
  - pankajdoharey 9y ago
    >I'm talking about having a industry-grade, production ready language. It isnt a mature enough language to be trusted so soon, no body has a sufficient enough industry grade experience with it. Especially with large code bases.
    - adamnemecek 9y ago
      > It isnt a mature enough language to be trusted so soon, I mean, Google adopted it as a first class citizen language on android which counts for something. > no body has a sufficient enough industry grade experience with it. Especially with large code bases. There aren't really any "new" features in Kotlin, as in features you haven't seen before. If you've been programming Java and know some Haskell/Ocaml or idk what else, you are good to go.
      - geodel 9y ago
        > I mean, Google adopted it as a first class citizen language on android which counts for something. Something but not much. It works on JVM, talk to all Java libs and tooling is taken care by Intellij. It is low or little effort from Google to support. Unlike other language fans who clamor for Android support from Google, here hard work is done by someone else. So Google support looks most like a co-branding deal.
randomThoughts9 9y ago
> This is unprecedented. Don't get me wrong, I like Kotlin, but Ceylon did the multi platform thing much better. They have real platform modules, built into the language (not just a build tool trick), and a language specification that was written from the start with multiple platforms in mind. But it never took off (yet), and Kotlin's support is good enough, so it will have to do I guess :).
beagle3 9y ago
Nim doesn't have a JVM backend, but it does C, C++, Objective-C, JavaScript, LLVM (not yet ready for prime time, but almost there), iOS, Android, and more. Lisps have been doing this since forever (including the now defunct LinJ for Java which compiled into code that was very often mistaken for hand-written Java). Hell, Emscripten takes everything LLVMable and gives it that ability. > This is unprecedented. Only for sufficiently narrow "this".
stewbrew 9y ago
Since the kotlin runtime is rather small, you still have to deal with platform differences. I like kotlin for several reasons but this one isn't on the top of my list. If you like cross-platform development, you might want to check out haxe.
venturis_voice 9y ago
Hi, thanks for commenting on our recent blog post. We share and discuss all our content on Venturi’s Voice Slack group. Seeing as you know quite a bit about this topic it would be great if you joined the conversation on there. We’re a new community based around the blogs and podcasts we release everyday at Venturi. We aim to consistently deliver valuable content to our candidates - but we know there is always room for improvement, so your feedback would really help us out! The group’s pretty quiet at the moment whilst we’re building up the community but stick with us as we’re aiming to grow it rapidly. https://publicslack.com/slacks/https-venturisvoice-slack-com/invites/new https://publicslack.com/slacks/https-venturisvoice-slack-com...

meddlepal 9y ago

I have been using Kotlin in the backend (along with Python) since late 2015 at Datawire.io and it is a pleasure to work with.

duiker101 9y ago
May I ask you what frameworks and everything are you working with? I've been enjoying django for a while now but I am really looking for new excuses to use more kotlin
- meddlepal 9y ago
  I like to keep it simple. I've never been a big fan of most big "mainstream" JVM frameworks like Spring. I much prefer using libraries and writing a small amount of glue code to keep it understandable rather than making others become framework competent before hopping on a project. For web services I use Sparkjava but I'm thinking of moving to Javalin or http4k because Sparkjava has really slow release cycles. JSON is either Gson or Jackson. I prefer Jackson just because I know it better but they're both great. I use JDBI for database work but I don't have too much of that in my backend right now. GRPC for cross service communication. Back in 2015/2016 I used Vert.x a bunch but I really didn't like the async programming model. YMMV. Generally I stick to using well known / common libraries written for Java and then later look for a Kotlin version if I have time to dick around a bit. I think this is what I love the most about Kotlin is the great interop with existing Java libraries.

kevinherron 9y ago

I love Kotlin. It's the sweet spot between Java and Scala. Been using it for backend stuff since it went 1.0. Coroutines are a game changer for a lot of the work I do. Really excited to see how Native progresses as well. I've got a handful of projects what would benefit from having the 90% core written in Kotlin with some JVM and Native portions plugged in, ultimately meaning the library is available on both JVM and Native.

ravirajx7 9y ago

Is the link broken?

wootie512 9y ago
Yea it is for me right now. Looks like the entire Venturi Group site is down.
deleted 9y ago
[deleted]
thepratt 9y ago
Have the same issue, it looks like someone deleted their entire site, or at least unlinked it.
stareatgoats 9y ago
downside of getting on the first page of HN I suppose
mk321 9y ago
Mirror: https://web.archive.org/web/20171120143056/http://www.venturi-group.com/blog/getting-started-kotlin/ https://web.archive.org/web/20171120143056/http://www.ventur... or: http://webcache.googleusercontent.com/search?q=cache%3Ahttp://www.venturi-group.com/blog/getting-started-kotlin/ http://webcache.googleusercontent.com/search?q=cache%3Ahttp:...
venturis_voice 9y ago
Hi sorry about that our website experienced some technical difficulties just after I posted this, typical I know. We're back up and running now though

mumphster 9y ago

Cached: http://webcache.googleusercontent.com/search?q=cache:http://www.venturi-group.com/blog/getting-started-kotlin/ http://webcache.googleusercontent.com/search?q=cache:http://...

pmelendez 9y ago

Honest question. I have been checking Kotlin since a while but haven't found a compelling case for me to start using it. All the features I have seen so far are syntactic sugar. Even the article quote something around those lines: “The syntax for Kotlin, like Apple’s Swift, is clean and modern. The reaction amongst developers learning Kotlin is not dissimilar to the initial experiences with Ruby years ago. The syntax is so intuitively designed that even without any previous exposure it’s almost possible to guess it.” The question would be: Am I missing something? Is syntax the only reason that makes people excited about it? or are there any new abstractions/ideas that are exclusive for Kotlin?

jarym 9y ago
Depends on your definition of syntactic sugar - for instance, the coroutines stuff is very intuitive and makes code far more readable and easier to work with. It all compiles down to stuff that a Java decompiler will be able to read back to Java. But that's just one example and a subjective one at that. Not everyone will feel the same way and for those who don't there's no compelling reason to 'start using Kotlin' - if what you have works then stick with it. There's also Kotlin native and Kotlin JS - allowing Kotlin code to be compiled to native binaries as well as to javascript is pretty compelling and will (imo) pay dividends. Both are still very much in development though.
lmm 9y ago
To have a clean/nice/familiar syntax in a language with a semi-decent type system is actually a pretty big deal. What're the other options? Java and C# are pretty cumbersome, Haskell and OCaml (and to a certain extent F# and Rust) look weird, Swift/C#/F# are to a certain extent tied to proprietary platforms, and while Scala actually has a nice core syntax the culture of its libraries tended to hide that away under a pile of sigils.
- pron 9y ago
  What feels cumbersome to some may not feel cumbersome to others, or they may not care as much about this, because, for example, they can feel that concrete code is less important than design, and considering that a minor reduction (at best) in the time spent working with code translates to negligible (or even negative) overall contribution to the project, and may certainly not justify sacrificing the many other conveniences that come with using a hugely popular, familiar and well-tooled language.

lmm 9y ago

As a Scala programmer, Kotlin always feels like a language that frustratingly almost gets it, but is infuriatingly unwilling to listen to experience of what works in large codebases. Look at the examples on https://philipnilsson.github.io/Badness10k/escaping-hell-with-monads/ https://philipnilsson.github.io/Badness10k/escaping-hell-wit... - I think Kotlin has literally every one of those ad hoc solutions built into the language, but stubbornly avoids making the generalisation. In small examples ad hoc solutions look great, but to succeed in large codebases a language needs a generality and consistency that Kotlin lacks. E.g. already there's no way to reuse logic between code paths that operate on Kotlin nullable types, Java Options (needed for compatibility with Java streams or more generally other JVM libraries), or rust-style Result types (for which there are several Kotlin libraries already, because it's a very useful concept and the language mostly has the facilities to support it), even though all three behave almost identically and you would often want to do the same thing in all three cases. But since the language won't let you represent what these types have in common, your only option is to copy/paste the code.

pron 9y ago
> but is infuriatingly unwilling to listen to experience of what works in large codebases. I don't think so. Java has been used successfully in large codebases, probably more so than Scala, and Kotlin, like Go, is a language following Java philosophy. > I think Kotlin has literally every one of those ad hoc solutions built into the language, but stubbornly avoids making the generalisation. 1. Ask yourself why does it stubbornly avoid making such generalizations. There are very, very good reasons. 2. Kotlin has delimited continuations, which express anything monads can (with a minor, unimportant caveat, which has to do with the particular features of Kotlin coroutines), in a way that blends much more nicely with imperative languages features that abound in both Kotlin and Scala, and composes much more nicely than monads (although that requires a feature currently absent an Kotlin's coroutines, but the feature is largely unnecessary for the kind of code Kotlin aims at). > already there's no way to reuse logic between code paths that operate on Kotlin nullable types, Java Options That's not really accurate. Kotlin does this blending at least as well if not better than Java. Java options are not really intended to be used in the same way they're used in Scala. > or rust-style Result types (for which there are several Kotlin libraries already, because it's a very useful concept and the language mostly has the facilities to support it) Those are not idiomatic in Kotlin, and some (like me) think that the Kotlin idioms are better, at least for the kind of code it aims to support. > But since the language won't let you represent what these types have in common, your only option is to copy/paste the code. I don't think it is a language's job to support all idioms out there, even if they can be useful in some circumstances. Languages following the Java philosophy -- as opposed to Scala -- aim to be at least somewhat opinionated, and encourage similar coding patterns in all cases, even if some idiom can be marginally better suited in some specific case. It's a tradeoff between code homogeneity and being "multi-paradigm", which can only be settled by the values of the language. There is no right or wrong answer here. Kotlin's values are very, very different from Scala (even if many features are shared), which is why Kotlin was created in the first place. Its designers wanted a modern language in the Java tradition (I know that from directly talking to them), not in the Scala tradition.

pankajdoharey 9y ago

To me Kotlin feels like the most overrated copy of Scala.

rb808 9y ago

I like Kotlin, but I'm thinking of just concentrating on Java and giving up on Scala and Kotlin. Scala was much better than Java but now the gap has closed and while its still nice to work with, I feel most applications would be better to stick to mainstream Java. Kotlin is interesting but after Scala experience I'm reluctant to invest all over again. Is it worth it?

taesis 9y ago
May I ask where you invested your time in learning Scala (e.g. reading the red book, studying type theory, syntax + stdlib + collections, etc.)? I found I could read simple Kotlin in a couple afternoons, and after a couple weekends, I felt pretty comfortable with it. The only difficult concepts to wrap your head around, I'd say, are type safe builders [1] and coroutines [2], but you certainly don't need to know those to be productive in the language. To answer your specific question, however, if you're doing Android development it's worth it :) otherwise, it's up to you/your specific situation. [1]: https://kotlinlang.org/docs/reference/type-safe-builders.html https://kotlinlang.org/docs/reference/type-safe-builders.htm... [2]: https://kotlinlang.org/docs/reference/coroutines.html https://kotlinlang.org/docs/reference/coroutines.html
parmesan 9y ago
If you're familiar with Java, adopting Kotlin is just a matter of setting it up and reading the docs frequently for a week or so. If you want to, Kotlin can be practically Java without the over-verbosity and some nice extra features. In time you'll be writing less Java-Kotlin and more Kotlin-Kotlin, if you get what I mean. To me the syntax and structure is so resembling to Java that I haven't really had any confusions at all, most of my gotta-read-the-docs moments involve the concepts that you can use that aren't present in Java (along with the `when` version of `switch` which I've grown to love).

deleted 9y ago

[deleted]

bencollier49 9y ago

As a Python and Java programmer, Kotlin hits the sweet spot for me with the type safety of Java (+ ecosystem) together with a clean and modern syntax. All whilst avoiding adding clever/stupid things (cf. Scala, Go, Rust).

pankajdoharey 9y ago

Does anyone remember Groovy this is just a fad Kotlin would be forgotten with time, i fail to see the real technical innovation in Kotlin.

nerdponx 9y ago
Since you seem to have some technical expertise in this area and strong opinions, it would be nice if you explained why you felt that way, for the benefit of us who are not experts. AFAIK Groovy is currently in use at lots of very major companies.
pjmlp 9y ago
At least for Android development it will be quite an improvement. Google made their Java fork, for Java 7 and 8 they only cherry picked features, even after migrating to OpenJDK. The newly introduced bytecodes are not supported and the situation will only get worse with Java 9 and the new OpenJDK release schedule. Specially given the lack of updates across the Android eco-system. So only something like Kotlin allows to enjoy modern JVM languages while targeting Android.

edpichler 9y ago

Could someone tell me if Kotlin and TypeScript are similar solutions? I put both on my "next reads" list.

lmm 9y ago
TypeScript has a marginally weaker type system (it's structural and has soundness issues with variance) and is more focused on being close to JS; it has very good ecosystem penetration (e.g. a lot of libraries publish typescript definitions even if they're not written in typescript). Kotlin is intended as a general-purpose language that can also compile to JS. So I'd say it depends on how web-oriented you are.
- edpichler 9y ago
  Got it, thanks for your summary.

lobo_tuerto 9y ago

Woops 404 on the link.

venturis_voice 9y ago
Hey sorry about that annoyingly our website went down not long after I posted the link, it's working again now though if you wanna dive back in

rdsubhas 9y ago

I'm neither pro nor con with Kotlin, but let's look at history and parallels. At its peak, Eclipse released Xtend. At that point, Eclipse was the IntelliJ of today, everyone assumed Xtend would be the next Java with full support of Eclipse tooling. Today, well, anyone remembers it? But its still there, check the features: http://www.eclipse.org/xtend/documentation/index.html http://www.eclipse.org/xtend/documentation/index.html. You will see thousands of articles on kotlin vs java, but only a handful on kotlin vs xtend, because of the cycle. Groovy. Same cycle, same result. Javascript has a large share of syntactic forks. All of them had this hype-cycle. Coffeescript was "de-facto way" to write cross-browser eloquent javascript at one point. There are few lessons from history: Syntactic language forks are what they are - forks. It takes equal amount of tooling and expertise to maintain them. When the next two versions of Java releases, the hype cycle will again turn tides. "X is the better Y", "Groovy is the better Java" - never, there is only one Java, there is no better Java. The best approach is to make the language itself extensible. Look at ES-next and babel. Every language addition is a proposal, and proposals can be implemented as language plugins with stages 3/2/1/0. This effectively rendered most syntactic forks almost meaningless and unnecessary. Have an idea? Extend to the language directly! The most important part - tooling - which is eslint, AST parsing, intermediate representations, code formatting, etc - have been shifted to work on top of language plugins. Now some of you will talk against babel, and how different projects use different babel settings - but given all the history, babel is the best way to pragmatically evolve a language we've ever had so far. Java has a longer mature JSR and language proposal process, just like ES. I really regret that Jetbrains decided to create yet another language fork, while being in the position to create the next babel for java. Will Kotlin be different from all the previous cycles? Only real 2020 will tell, but until then, the only reference available is history.

russellbeattie 9y ago

This may not be the most educated opinion, but I tend to think of "languages" that compile to the JVM as just elaborate macros. My reasoning is that in order to use Kotlin (or Scala, Groovy, etc.), you will inevitably have to know Java very well, as most of the language is just syntactic sugar, and you'll almost always have to interact with standard libraries and SDKs written for use with Java. A language isn't a "real" language unless you can live in it and be blissfully ignorant of anything else. I don't need to know C in order to use Go, or Python. I don't need to know Ruby in order to use JavaScript. But it'll be relatively impossible to write code in Kotlin without interacting with Java constantly. Which means context switching and maybe even bugs.

iLemming 9y ago

I skimmed through the comments, looked at code examples - they hurt my eyes. Read arguments of Scala people. Read about C# vs Java. For the life of me I don't get it. Why people simply wouldn't use Clojure?

venturis_voice 9y ago

Hi all, thanks for commenting on our recent blog post. We share and discuss all our content on Venturi’s Voice Slack group. Seeing as you know quite a bit about this topic it would be great if you joined the conversation on there. We’re a new community based around the blogs and podcasts we release everyday at Venturi. We aim to consistently deliver valuable content to our candidates - but we know there is always room for improvement, so your feedback would really help us out! The group’s pretty quiet at the moment whilst we’re building up the community but stick with us as we’re aiming to grow it rapidly. https://publicslack.com/slacks/https-venturisvoice-slack-com/invites/new https://publicslack.com/slacks/https-venturisvoice-slack-com...