new language "Kotlin" from jetbrains

[Paul Phillips]

Maybe I'm the last guy to hear about things (it happens enough) but
there's this language here which looks like a more credible effort to be
a better/simpler scala than most:

http://confluence.jetbrains.net/display/Kotlin/Welcome

The "What Kotlin has that Scala has not" list does read like a list of
things I would not mind having:

http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala

It makes me sad to see another whole implementation's worth of effort
being poured into something new -- come on guys, you won't be enough
better than scala. I know everyone wants their own baby, but just
imagine what we might accomplish if we didn't all keep re-running the
same opening mile. The scenery up here on mile two, it's nice, you
should come give it a look.

P.S. First mile is long.

[Russ Paielli]

I'll bet you loved this:

There're other "new" languages. Why not them?

In short:

• Scala is too complex and it's very hard to make a good tooling support for it

--Russ P.

--
http://RussP.us

[Nikita Ivanov]

It's primarily a dig at Groovy and Groovy++ rather than Scala (despite of proclamation otherwise). Agree - kind of sad we have a whole mess w/Kotlin/Ceylon coming online. 

In the same time it underscores the need for 1st class Eclipse/IDEA tooling - probably #1 reason for slow-than-expected Scala adoption. 

Best,

--

Nikita Ivanov, CEO

GridGain Systems

www.gridgain.com

On Tue, Jul 19, 2011 at 4:29 PM, Paul Phillips <pa...@improving.org> wrote:

[Tony Morris]

I share the lament.

--
Tony Morris
http://tmorris.net/

[Jim Balter]

JetBrains knows a little something about that subject, so their
comment shouldn't be taken lightly.

On the broader issue ... designing new programming languages is all
the rage now, with Go, Vala, Rust, BitC, Closure, Plaid, Agda, Coq,
Nemerle, Kotlin ... some of the reasons for doing so are better than
others, but in any case it's going to continue. Hopefully lessons will
be learned from all these efforts.

-- Jim

[Russ Paielli]

Kotlin seems similar enough to Scala that I'm wondering why they didn't just fork Scala (assuming that the Scala license allows forking). If you just want add and subtract a few features, I would guess that forking could save you one hell of a lot of time compared to starting from scratch. It would also make the language a lot more familiar to current Scala users, thereby encouraging adoption. Who wants to learn a whole new language just for a few different features? But maybe the language differs from Scala more than I realize, since I only briefly skimmed the list of differences.

--Russ P.

On Tue, Jul 19, 2011 at 4:29 PM, Paul Phillips <pa...@improving.org> wrote:

--
http://RussP.us

[Jim Powers]

On Tue, Jul 19, 2011 at 9:16 PM, Russ Paielli <russ.p...@gmail.com> wrote:

Kotlin seems similar enough to Scala that I'm wondering why they didn't just fork Scala (assuming that the Scala license allows forking). If you just want add and subtract a few features, I would guess that forking could save you one hell of a lot of time compared to starting from scratch. It would also make the language a lot more familiar to current Scala users, thereby encouraging adoption. Who wants to learn a whole new language just for a few different features? But maybe the language differs from Scala more than I realize, since I only briefly skimmed the list of differences.

From: http://confluence.jetbrains.net/display/Kotlin/FAQ

Does it have IDE support?

Yes. The compiler is developed as an IntelliJ IDEA plugin, and user-facing IDE features are there from the very beginning (we make good use of them while debugging and testing). 

I expect that the compiler will be pretty fast, and very much designed for interactive IDE use.

--

Jim Powers

[Jim Powers]

I think that the only rational response to this challenge is for TypeSafe to announce a new IDE: 'Intelli/S Notion' completely written in Scala.

--

Jim Powers

[Srirangan]

LOL

--
Srirangan  |  About  Blog  GitHub  LinkedIn  Twitter

[Nikita Ivanov]

I think the tooling support became an intrinsic feature of the language (if not one of the most important one). I won't be surprised to see tooling support be a part of the language specifications in the future. 

JetBrains has an enormous advantage on that (naturally). I think Scala has ~12-18 months before Kotlin hits the 1.0.

--

Nikita Ivanov, CEO

GridGain Systems

www.gridgain.com

On Tue, Jul 19, 2011 at 4:29 PM, Paul Phillips <pa...@improving.org> wrote:

[Rex Kerr]

They've only gone (or planned) a few hundred yards in a direction that Scala hasn't already been.

The key ones to my eye are

  (1) Extension functions.  Much cleaner syntax and better performance than the Pimp My Library pattern using implicits.

  (2) NotNull support

  (3) Delegation/proxying (without a plugin).

I'm pretty sure I wouldn't miss everything else, although inline string interpretation would be nice without having to go through XML.

Some of the design choices seem downright perplexing if one wants something simpler than Scala.  Having to remember 30 rules to know which method corresponds to which operator?  Extension functions extending anything anywhere?  Pattern matching syntax even more complicated than Scala's?

  --Rex

[Tony Morris]

On 20/07/11 12:16, Rex Kerr wrote:
> (2) NotNull support
This is a step backwards.

[Jim Powers]

On Tue, Jul 19, 2011 at 10:11 PM, Nikita Ivanov <niv...@gridgain.com> wrote:

I think the tooling support became an intrinsic feature of the language (if not one of the most important one). I won't be surprised to see tooling support be a part of the language specifications in the future. 

Compiler support for the IDE was a first-class consideration when MS was developing the initial .NET language suite (C#, C++, and VB). I recall reading a blog post (from MS) about how compiler design has been fundamentally changed as a result of taking into account the IDE as the primary consumer of the compiler's functionality.

 

JetBrains has an enormous advantage on that (naturally). I think Scala has ~12-18 months before Kotlin hits the 1.0.

Agreed that JB has a massive advantage in the IDE arena, but getting to a 1.0 for a new language is still pretty far from attaining wide-spread adoption, Scala is not Kotlin's only competitor.

 

-- 

Jim Powers

[Rex Kerr]

On Tue, Jul 19, 2011 at 10:17 PM, Tony Morris <tonym...@gmail.com> wrote:

On 20/07/11 12:16, Rex Kerr wrote:
> (2) NotNull support
This is a step backwards.

It's a step sideways.  If you have to put up with null anyway, which we do with Java interop, and that will last until all Java libraries of great utility have Scala wrappers, then it's nice to have the compiler help you check when things might be null and might not.  Any time the compiler can tell me when my assumptions are wrong, I count it as a step forward.

Of course, this can lead to the increased use of nulls instead of more powerful concepts, which would be a step backwards.

  --Rex

[Cédric Beust ♔]

On Tue, Jul 19, 2011 at 4:53 PM, Nikita Ivanov <niv...@gridgain.com> wrote:

It's primarily a dig at Groovy and Groovy++ rather than Scala (despite of proclamation otherwise).

You think so? Well, let's see the quote again:

"Scala is too complex and it's very hard to make a good tooling support for it"

Now, what could possibly make you think they actually meant Groovy?

It's simple, really. Martin is the first to admit that tooling for Scala (especially IDE support) is hard, and he's throwing resources at the problem. Now you have IDEA, the creators of one of the most popular IDE's today, say the same thing, and you still choose to ignore it.

What will it take?

Agree - kind of sad we have a whole mess w/Kotlin/Ceylon coming online. 

I don't find it sad, I'm pretty excited. Every language brings its own contribution to the edifice, be it small or big. I'm looking forward to seeing what an IDE company can come up with.

 

In the same time it underscores the need for 1st class Eclipse/IDEA tooling - probably #1 reason for slow-than-expected Scala adoption. 

Violent agreement here.

-- 

Cédric

[Jim Balter]

NotNullable is the default ... you have to append '?' to a type to
make it Nullable. That seems to me a step forward from both Java and
Scala, where all reference types are always Nullable ... although I do
see the point about the psychology that, since '?' is a language
feature, you're expected to do things that way. But at least, if you
do use the feature, your code is typechecked and you can't get runtime
NPE's from Kotlin (as opposed to interop) code except for
initialization order problems.

-- Jim

[Cédric Beust ♔]

On Tue, Jul 19, 2011 at 6:16 PM, Russ Paielli <russ.p...@gmail.com> wrote:

Kotlin seems similar enough to Scala that I'm wondering why they didn't just fork Scala (assuming that the Scala license allows forking).

Besides the the license concern, isn't it obvious? Writing programming languages is fun, and if you are an IDE company, it's a no-brainer to create a language from scratch so that the language and the tools can move forward in lockstep.

 

Who wants to learn a whole new language just for a few different features?

"A few different features" is what makes or breaks a language from a mainstream adoption perspective. You don't know which ones will work until you really try.

-- 

Cédric

[John Nilsson]

On Wed, Jul 20, 2011 at 4:16 AM, Rex Kerr <ich...@gmail.com> wrote:

  (3) Delegation/proxying (without a plugin).

In the spirit of Scala I guess the feature missing here is a good macro system to solve the general case.

Take a look at MorphJ: http://code.google.com/p/morphing/wiki/MorphJ


Besides that. The module as compilation unit thing sounded like a good thing too...


BR,
John

[Cédric Beust ♔]

On Tue, Jul 19, 2011 at 7:37 PM, Jim Balter <J...@balter.name> wrote:

NotNullable is the default ... you have to append '?' to a type to
make it Nullable. That seems to me a step forward from both Java and
Scala, where all reference types are always Nullable ...

Agreed. I use this all the time in Fantom and it's really nice. The only downside is that question marks soon become overwhelming in code that is relies a lot on null. I guess it's one more incentive to drop the practice.

-- 

Cédric

[Jim Balter]

2011/7/19 Cédric Beust ♔ <ced...@beust.com>:

Rust has done away with nulls altogether, with the cost that
initialization is restricted. From
https://github.com/graydon/rust/wiki/Language-FAQ

"
Data values in the language can only be constructed through a fixed
set of initializer forms. Each of those forms requires that its inputs
already be initialized. A dataflow analysis (the typestate system used
elsewhere) ensures that local variables are initialized before use.
"

[Paul Hudson]

On 20 July 2011 01:03, Jim Balter <J...@balter.name> wrote:

On the broader issue ... designing new programming languages is all
the rage now, with Go, Vala, Rust, BitC, Closure, Plaid, Agda, Coq,
Nemerle, Kotlin ... some of the reasons for doing so are better than
others, but in any case it's going to continue. Hopefully lessons will
be learned from all these efforts.

I think today's XKCD might explain some of this http://xkcd.com/927/ :)

[Francois Armand]

Le 20/07/2011 04:38, Cédric Beust ♔ a écrit :
> On Tue, Jul 19, 2011 at 6:16 PM, Russ Paielli <russ.p...@gmail.com

[...]

> "A few different features" is what makes or breaks a language from a
> mainstream adoption perspective. You don't know which ones will work
> until you really try.

And I would add that the theory beside Scala and Kotlin is quite
different, and so it does not seems to be like "a few different
features", but much more like "some core fundation features are different"

--
Francois Armand
http://fanf42.blogspot.com

[martin odersky]

On Wed, Jul 20, 2011 at 1:53 AM, Nikita Ivanov <niv...@gridgain.com> wrote:

It's primarily a dig at Groovy and Groovy++ rather than Scala (despite of proclamation otherwise). Agree - kind of sad we have a whole mess w/Kotlin/Ceylon coming online. 

In the same time it underscores the need for 1st class Eclipse/IDEA tooling - probably #1 reason for slow-than-expected Scala adoption. 

Yes, exactly.

It looks like a language that has taken ideas from C#, Java, and Scala and blended them. I do not really see any tradeoffs that would make it simpler than Scala. Maybe a bit simpler to compile, and fewer opportunities for mis-use (no implicits, no symbolic operators) but not simpler to spec or program in. On the other hand it will have to prove that it's as good for library and framework abstractions as Scala is.

The things it has on top of Scala (nullablity and delegation) both seem to be designed well. But everything adds to the language footprint.

Cheers

 -- Martin

[Sergei]

Hmm. Interesting. 

The fundamental strength of JetBrains twelve or so years back when it was founded was outstanding output/compensation ratio of Eastern European programmers. I recall marveling at the sheer numbers and pedigrees of JetBrain programmers willing to work for so relatively little. That advantage is mostly gone now, as large Eastern European cities became ones of the most expensive in the world to live in, with corresponding salary requirements. 

Secondary advantage was strong higher education system built in the Soviet times, pumping out humble and consistently productive local talent. It severely deteriorated since then, as education funding was ruthlessly cut and the whole generation of would-be-professors and star students left Eastern European countries in the last couple of decades. Interestingly enough, a virtual carbon-copy of that system is still operational and thriving in India, which partially explains India's increasing strength in software development.

Indication of JetBrains increasing weakness for me personally was the way that the three major Scala IDEs were evolving for the last couple years. I was really surprised that just one person could develop a more useful Scala plugin for NetBeans than the whole mighty JetBrains could for IDEA. 

I'm not sure to what degree that phenomenon could be explained by the fresher, better organized NetBeans code base, the differences in talent of corresponding developers, and lack of strategic vision on the JetBrains part, yet the subjective fact for me was that JetBrains seriously dropped the ball on this one. There was a two-three-year period of Scala IDE vacuum than they utterly failed to fill.

And now they are throwing in the towel completely, probably being scared by the TypeSafe's progress on Eclipse-based Scala IDE. In general, they are seriously squeezed by the successes of Eclipse-based IDEs and continuing evolution of Visual Studio and XCode. Maybe coming up with the language they can control is a wise competitive response to that situation. Or maybe it is a futile attempt to turn things around, driven mostly by emotion. Frankly, I don't know at this point. Time will tell...

[martin odersky]

On Wed, Jul 20, 2011 at 4:16 AM, Rex Kerr <ich...@gmail.com> wrote:

On Tue, Jul 19, 2011 at 7:29 PM, Paul Phillips <pa...@improving.org> wrote:

Maybe I'm the last guy to hear about things (it happens enough) but
there's this language here which looks like a more credible effort to be
a better/simpler scala than most:

 http://confluence.jetbrains.net/display/Kotlin/Welcome

The "What Kotlin has that Scala has not" list does read like a list of
things I would not mind having:

 http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala

It makes me sad to see another whole implementation's worth of effort
being poured into something new -- come on guys, you won't be enough
better than scala.  I know everyone wants their own baby, but just
imagine what we might accomplish if we didn't all keep re-running the
same opening mile.  The scenery up here on mile two, it's nice, you
should come give it a look.

P.S. First mile is long.

They've only gone (or planned) a few hundred yards in a direction that Scala hasn't already been.

The key ones to my eye are

  (1) Extension functions.  Much cleaner syntax and better performance than the Pimp My Library pattern using implicits.

Extension functions are shortsighted because they only make a class get new methods but do not let it implement new interfaces. In any mature framework, the primary reason for a method to exist is to implement some interface. Extension functions don't scale up to that usage.

Cheers

 -- Martin

[Naftoli Gugenheim]

The things it has on top of Scala (nullablity and delegation) both seem to be designed well. But everything adds to the language footprint.

Cheers

 -- Martin

What precisely is the value or purpose of a small language footprint?

[Rex Kerr]

On Wed, Jul 20, 2011 at 3:02 AM, martin odersky <martin....@epfl.ch> wrote:

On Wed, Jul 20, 2011 at 4:16 AM, Rex Kerr <ich...@gmail.com> wrote:

On Tue, Jul 19, 2011 at 7:29 PM, Paul Phillips <pa...@improving.org> wrote:

The "What Kotlin has that Scala has not" list does read like a list of
things I would not mind having:

 http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala

It makes me sad to see another whole implementation's worth of effort
being poured into something new

 

The key ones to my eye are

  (1) Extension functions.  Much cleaner syntax and better performance than the Pimp My Library pattern using implicits.

Extension functions are shortsighted because they only make a class get new methods but do not let it implement new interfaces. In any mature framework, the primary reason for a method to exist is to implement some interface. Extension functions don't scale up to that usage.

I don't think that all features must "scale" in order to be worthwhile.  While loops don't scale very well to complex collection manipulations, but Scala without them would be unusable for high-performance tasks.  Operators don't scale beyond 3 or 4 characters before they're indecipherable gibberish, but Scala that required "a plus b" would be awkward to use.  Tuples don't scale to large numbers of items, but that doesn't mean that they should be discarded in favor of HLists.

Even if we granted that scalability was a very high priority, I don't think the "mature framework" where your job is to glue together interfaces is the only or even the most interesting direction for scalability.  Another area of scalability is to manage large quantities of runtime data, e.g. with millions of objects.  GC is a pain in such situations, and there, I'd argue that PML is the one that doesn't scale (not unless escape analysis is perfect), because the cost-per-object gets increasingly expensive as the object churn goes up, while extension functions have fewer limits.  There's also scalability in terms of number-of-lines-of-code, and right now the volume of boilerplate per PML pattern is more than an extension function would require (if you just need to add the capability, not the interface).

I'm not saying to get rid of implicit conversions.  They're very useful, and if I had to pick one, I'd pick them.  But there are cases, including cases where scalability is important, where using implicit conversions for PML is a mediocre substitute for extension functions.

  --Rex

[Francois]

On 20/07/2011 04:16, Rex Kerr wrote:

On Tue, Jul 19, 2011 at 7:29 PM, Paul Phillips <pa...@improving.org> wrote:

[..]

It makes me sad to see another whole implementation's worth of effort
being poured into something new -- come on guys, you won't be enough
better than scala.  I know everyone wants their own baby, but just
imagine what we might accomplish if we didn't all keep re-running the
same opening mile.  The scenery up here on mile two, it's nice, you
should come give it a look.

P.S. First mile is long.

They've only gone (or planned) a few hundred yards in a direction that Scala hasn't already been.

Well, it's only my personnal interpretation, but I think that in the first mile, Paul also take into account the "adoption" factor.
Scala is now known and used in application deployed for several years, it has started to be an option for new projects... How much time and effort before Kotlin (or any other new Scala-alike language) reaching that state ?

I, too, share Paul (or Tony and others) sadness on that. On the other hand, being on a "every cloud has a silver line" mood, I will say that all these languages (and COT ;) are a good matrix for Scala 3.0.

-- 
Francois ARMAND
http://fanf42.blogspot.com
http://www.normation.com

[martin odersky]

Well a lot of people complain that "Scala is too complex". I personally don't believe that, and note that most of the criticism comes from people who are designing or supporting competing languages, not people who learn Scala. But I take the point very seriously. How do you measure  complexity? The best I know is to look how many features does a language have, and how many tricky interactions between these features. By that measure C# is a far more complex language than Scala and the jury is still out whether Kotlin or Ceylon or Groovy++ or any of the other "better Java" languages will me more or less complex (my guess is: probably in the same ballpark).

There's another dimension to complexity, which is what people typically do with a language. Again, I find the average Scala code pleasantly simple, but it's true that some of the best published code is complex, in that it solves very abstract tasks. Scalaz has a lot of great ideas embedded in it, but if we want Scala to succeed we need to publish more of the simple kind of code!

Best,

 -- Martin

[martin odersky]

On Wed, Jul 20, 2011 at 9:33 AM, Rex Kerr <ich...@gmail.com> wrote:

On Wed, Jul 20, 2011 at 3:02 AM, martin odersky <martin....@epfl.ch> wrote:

On Wed, Jul 20, 2011 at 4:16 AM, Rex Kerr <ich...@gmail.com> wrote:

On Tue, Jul 19, 2011 at 7:29 PM, Paul Phillips <pa...@improving.org> wrote:

The "What Kotlin has that Scala has not" list does read like a list of
things I would not mind having:

 http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala

It makes me sad to see another whole implementation's worth of effort
being poured into something new

 

The key ones to my eye are

  (1) Extension functions.  Much cleaner syntax and better performance than the Pimp My Library pattern using implicits.

Extension functions are shortsighted because they only make a class get new methods but do not let it implement new interfaces. In any mature framework, the primary reason for a method to exist is to implement some interface. Extension functions don't scale up to that usage.

I don't think that all features must "scale" in order to be worthwhile.  While loops don't scale very well to complex collection manipulations, but Scala without them would be unusable for high-performance tasks.  Operators don't scale beyond 3 or 4 characters before they're indecipherable gibberish, but Scala that required "a plus b" would be awkward to use.  Tuples don't scale to large numbers of items, but that doesn't mean that they should be discarded in favor of HLists.

Even if we granted that scalability was a very high priority, I don't think the "mature framework" where your job is to glue together interfaces is the only or even the most interesting direction for scalability.  Another area of scalability is to manage large quantities of runtime data, e.g. with millions of objects.  GC is a pain in such situations, and there, I'd argue that PML is the one that doesn't scale (not unless escape analysis is perfect), because the cost-per-object gets increasingly expensive as the object churn goes up, while extension functions have fewer limits.  There's also scalability in terms of number-of-lines-of-code, and right now the volume of boilerplate per PML pattern is more than an extension function would require (if you just need to add the capability, not the interface).

It's pretty straightforward to optimize these wrappers away, either in the compiler or in the JVM. I have so far resisted making them a special case (which we could) because I think that a decent general purpose optimizer should be able to eliminate the object creation and call indirection, generating in effect the same code as an extension method. Scala optimizers evolve more slowly than I would like, but it's no reason to give up and instead throw more features into the language.

 -- Martin