Kotlin: statically typed programming language that compiles to JVM & JavaScript | Hacker News Reader

Kotlin: statically typed programming language that compiles to JVM & JavaScript

kotlin.jetbrains.org

46 pointsamarsahinovic33 comments

I don't know why would I want to use this and not Scala. Sure, Scala might have some complexity, but it's easy to learn and for me it's as productive as Python.

I found this comparision: http://confluence.jetbrains.net/display/Kotlin/Comparison+to... so basically Kotlin seems to be a "watered" Scala.

For some people, after looking at Scala a bit, being "watered" might be a good thing. Kotlin doesn't have as many syntax surprises as Scala does.

That being said, the one really cool feature Kotlin has that Scala doesn't is the ability to build strongly-typed builder DSLs:

http://confluence.jetbrains.net/display/Kotlin/Type-safe+Gro...

You simply can't accomplish this in Scala with the same elegance.

What exactly is special about that DSL? I'm pressed for time, but it seems like it would be trivial to reproduce in Scala.

In Kotlin, you can write a function that takes, as its last argument, a function literal that is scoped to a specific class. Last I checked, function scoping does not work this way in Scala and you'd have to explicitly pass around objects to get the same result.

In the end, we end up with a builder DSL like this:

  div() {
      h1("header")
      p("paragraph")
      div() {
          p("another paragraph")
      }
      h2("another header")
  }

In Kotlin, each function call is properly scoped inside (unseen) classes for each level, allowing the code to generate the appropriate object tree.

In Scala, all functions would have to be visible in the local scope of the top-level function and we'd end up with a flat object tree instead.

To get the proper object tree in Scala, you'd need to pass explicit references to each containing object into the appropriate function literals, which makes it much more verbose and extremely error prone.

EDIT: not nearly as convincing without proper formatting...

That's not very hard to do with Scala. In fact, there's a few projects that have implemented whole other languages in Scala. Most languages that let you go near functional style do very well with DSLs and writing a DSL is one of the often highlighted strengths of Scala.

For a good example check out the Specs2 unit testing framework.

That Kotlin page calls them "Groovy-style", perhaps because many of those working on Kotlin (e.g. James Strachan, Alex Tkachman) used to develop the Groovy Language.

But doesn't Ruby also have those builders? Wouldn't it be easy enough for Scala to implement them in a library if they haven't already? Wouldn't Python also provide this type of syntax? E.g. a possible translation into Python from the Kotlin code on the linked page...

    html:
      head:
        title {"XML encoding with Python"}
      body:
        h1 {"XML encoding with Python"}
        p {"this format can be used as an alternative markup to XML"}
 
        // an element with attributes and text content 
        a(href = "http://python.org") {"Python"}

        // mixed content 
        p:
          "This is some" 
          b {"mixed"} 
          "text. For more see the" 
          a(href = "http://python.org") {"Python"} 
          "project" 
        p{"some text"} 
 
        // content generated by 
        p: 
          for (arg in args) arg

So what are they called "Groovy-style" builders for?

I program in Groovy daily. "Groovy-style" builders are just sugar over the Builder pattern via heavy use of closures - so in reality they can be used anywhere an Object needs to be constructed.

So yea, any language which supports closures should be able to do "Groovy-style" builders.

Presumably because, among the languages (and standard libraries) you mentioned that have implemented this pattern, Groovy is the language that is most tightly associated with the JVM (which Kotlin is obviously targeting).

> Groovy is the language that is most tightly associated with the JVM

That could've been very true 6 years ago, when Groovy 1.0 was released, but I'd have to challenge that for 2012 (and 2013).

Scala puts too much pressure on the GC to be a good candidate for Android development and the complexity of its syntax makes developing good tool support very difficult.

Since I only write Java for Android Kotlin is already way ahead of Scala on my list for both reasons.

Scala has very simple syntax. Most of the "complexity" is names of classes and methods in libraries.

Simple syntax is not the same as simple semantics.

Because Scala is a mess of a kitchen-sink language, a heap of both practical and academic features, a lot of sound and fury with no clear purpose or aim, and absolutely no opinions; it's the "yeah, why not? we'll throw that in, too"-language.

Most people who use Scala, use it simply as a better Java. Well, Kotlin is that better Java they've actually been looking for all along. And for anyone looking for a truly modern, opinionated language -- there's Clojure.

With Scala, it's often inconvenient when leaning how quickly code can become not just deprecated, but uncompilable because of the culture of whim.

Most people who end up hating Scala (or at least ruling out its use) seem to be unhappy with the tooling (mainly compile times or out of date IDE modules), rate of language change (either scala or even worse, scalaz), or the inconsistency of interfaces.

The obviously emphasis here with Kotlin is that you can also compile it to JavaScript. Which may be a smart move for Kotlin.

One reason why I chose Node.js over Scala for my current personal projects is that I prefer programming in the same language on the client and server.

That being said I've never used Kotlin and can't compare it with Scala, which I have used for my personal and commercial projects.

from the other direction, it looks like haxe [http://haxe.org] is planning on adding a java target. fantom [http://fantom.org] already does both java and js too. it's a pretty well-filled ecological niche.

also, if you like single-language stacks, give opa [http://opalang.org] a serious look. it's essentially based on ml, with a javascript skin, and offers strong static typing and easy integration of front-end and back-end code.

Besides those, there's ceylon, gosu, Xtend, probably some others, for JVM. My impression from the forum is that kotlin is not quite settled but I haven't written any code.

http://devnet.jetbrains.net/community/kotlin?view=discussion...

http://www.eclipse.org/xtend/

I'm glad you brought Opa up. I saw it a while ago and thought it was interesting, until I saw the license it used (AGPL).

Thankfully, your comment made me seek it out again and I saw they also added MIT for the framework part, so that apps can be licensed in any language. Will have to try it out now that they have given users that choice.

Doesn't look like something I would like to write me code in frankly. It does say it is for 'industrial' application whatever that means. I would think this would be for robots, but then why javascript?

Obviously I am not target group.

If this isn't a scientific targeted language, you should change that to "byte code" or better yet, "bytecode"

Code is a mass noun when talking to the computer profession.

The science professions still use the (now thought by the computer professions to be archaic) form "Codes"

I like this one! Superficially, the syntax looks like the marriage of Go and Scala.

or just wait for Java 8(coming in 2013); java 8 supposedly cuts down a lot verbosity and is sprinkled with functional programming features.

I think you can use Java 8 features in the latest build of the JDK. Not sure, though.

Language without proper IDE(Eclipse) support isn't worth much for me.

ps. i'm not cool enough to use notepad, vim etc.

It has IntelliJ support.

Just wanted to point that out, because you mentioned Notepad and VI. If you don't like IntelliJ, that's a whole other story.

This language is from the people who work on intellij, so it should have good IDE support in intellij. I haven't tried it myself though.

Jetbrains frustrations with implementing Scala support in IntelliJ were at least part of the motivation for Kotlin.

Since they've designed it with tool support in mind from the beginning I expect Kotlin to seriously outstrip the other JVM languages in IDE integration.

They're pretty honest by saying that the point of Kotlin is to drive IntelliJ IDEA sales (I did buy my licence 70% off during their doomsday special).

However it's a bit weird: they're creating a language that, basically, "needs" an IDE, so they can sell that IDE. I don't doubt they did put a lot of stuff in their language at which IDEA was good (e.g. @NotNull / @Nullable which IDEA was able to check in real-time on partial ASTs etc. which apparently made it into Kotlin right from the start).

I'm sure there's going to be quite some "refactor xxx to use pattern yyy", making IDEA "great" to work on Kotlin.

But are these really the features we want? A language that is "flawed" by design so that we can be sure we need an IDE to develop in it?

I'm still using IDEA and still doing some Java programming.

But I'm more and more investing time in Clojure / Emacs and, honestly, there's more pleasure to develop with these than with IDEA / Java. I don't know why IDEA / Kotlin would be any better.

To me it seems that, from the start, it's a language arguing for its own limitation.

P.S: what about concurrency? does it offer lock-free concurrency? Because there's no way I'm moving back to using explicit 'synchronized' keywords and having fun with deadlocks...

I wouldn't say that it needs an IDE; it certainly does not need it any more than Java, C, C++ or Scala for that matter. But, it can certainly benefit from an IDE, and I don't think that such a language is flawed or even "flawed" by design. It's simply different.

I, too, am a fan of Clojure, but I'm also a fan of Java, and Kotlin is probably the language best called "a better Java". Both kinds of languages have their place.

And as for concurrency -- I'm not sure, but I suspect that it follows the Java/C++/Scala model rather than adopt an opinionated vision of concurrency like Clojure and Erlang do. But if you'd ever need to write a new concurrent data structure for use by your Clojure app, you'll be able to do that with Kotlin rather than Java.

> A language that is "flawed" by design so that we can be sure we need an IDE to develop in it

All languages are flawed by design.

Assembly language is flawed so we need a higher level language like C, with easier to read syntax. C/C++ is flawed by requiring us to manage heap memory so we need a managed language like Java/C#. These and Kotlin are flawed because we need some visual help like name lookups and pattern refactorings.

"Flawed by design" doesn't mean "the design is flawed". It means "it is designed to be flawed".

You can write Smalltalk and Lisp outside of an IDE but you really wouldn't want to do so. You end up missing much of the power of the systems.

Think of the IDE as part of your exocortex. Leverage it for the junk you don't need so you can switch levels of abstraction as you desire.

Sorry for this test :(

Reply on news.ycombinator.com