Web-based editor for Kotlin, JetBrains' new JVM language(kotlin-demo.jetbrains.com)
kotlin-demo.jetbrains.com
Web-based editor for Kotlin, JetBrains' new JVM language
http://kotlin-demo.jetbrains.com/
2 comments
If it compiles faster than Scala I will use it!
From reading the language specs it seems much more pragmatic than Scala (as does ceylon http://www.ceylon-lang.org/ or fantom http://fantom.org/).
I think if JetBrains thought that Scala was a better Java they would be using it instead of creating their own language.
From reading the language specs it seems much more pragmatic than Scala (as does ceylon http://www.ceylon-lang.org/ or fantom http://fantom.org/).
I think if JetBrains thought that Scala was a better Java they would be using it instead of creating their own language.
It's unfortunate that Scala is fatally flawed because it was bound to the JVM. Having java interop is both a blessing and a curse. The sheer scale of the language implemented as a java library pretty crippled compile time.
Why do you link being based on JVM and long compile times?
Java is one of the fastest languages to compile (1000 files with ten megs worth of code would take something under 10 seconds), while C++ and Haskell are both very slow to compile even if they're not JVM based.
Java is one of the fastest languages to compile (1000 files with ten megs worth of code would take something under 10 seconds), while C++ and Haskell are both very slow to compile even if they're not JVM based.
The specific way Scala is bound to the JVM (as a 8mb class library that needs to be loaded every time) is the reason it is slow to compile and by implication, slow-er startup.
I suppose we do need to take account of language features. C++ is a difficult language to parse, and with a bit of template magic, and heavy compiler optimizations that can be applied. Haskell has type inference and is statically typed, that has to cost it some what.
Scala has a 8mb JVM library to load, and also type inference. It gets a double whammy. However I'm willing to bet is the JVM is contributing a significant portion of startup time, with both JVM startup time, loading java libraries, then loading scala library. If the JVM wasn't part of the problem, then there is no need for people to create tools like fsc to speed up compile time.
I suppose we do need to take account of language features. C++ is a difficult language to parse, and with a bit of template magic, and heavy compiler optimizations that can be applied. Haskell has type inference and is statically typed, that has to cost it some what.
Scala has a 8mb JVM library to load, and also type inference. It gets a double whammy. However I'm willing to bet is the JVM is contributing a significant portion of startup time, with both JVM startup time, loading java libraries, then loading scala library. If the JVM wasn't part of the problem, then there is no need for people to create tools like fsc to speed up compile time.
Plain old Java compiles way faster than Scala I don't believe the JVM is the main contributor to the slowdown.
Scala compilation is complex, partly due to its extremely sophisticated type system, it is also quite resource intensive - I have got the type checker to run out of memory on multiple occasions I have never seen a Java compilation fail due to lack of memory. fsc and incremental compilation do speed things up but it is still slower than compiling an equivalent amount of Java.
Scala compilation is complex, partly due to its extremely sophisticated type system, it is also quite resource intensive - I have got the type checker to run out of memory on multiple occasions I have never seen a Java compilation fail due to lack of memory. fsc and incremental compilation do speed things up but it is still slower than compiling an equivalent amount of Java.
Since Kotlin runs on the JVM surely it's also "fatally flawed" by your reckoning?
Scala also targets LLVM: http://greedy.github.com/scala-llvm/ and .NET: http://www.scala-lang.org/node/10299
Scala also targets LLVM: http://greedy.github.com/scala-llvm/ and .NET: http://www.scala-lang.org/node/10299
The authors of Kotlin has explicitly said that fast compilation is a key feature.
It's also one of the key features of Turbo Pascal.
I was quite interested in Kotlin, but Xtend is already out, and does most of the interesting stuff.
I think there's definitely room for a "better Java" - most Java devs should be able to pick up Kotlin or Xtend and be more productive very quickly.
With regard to FP, I think the presence of closures is enough to do a large proportion of the things you'd want.. What do you see lacking in these?
I think there's definitely room for a "better Java" - most Java devs should be able to pick up Kotlin or Xtend and be more productive very quickly.
With regard to FP, I think the presence of closures is enough to do a large proportion of the things you'd want.. What do you see lacking in these?
I'd like to see greater integration into the libraries and commonly used types. Strings in Scala for example let you perform all manner of filtering and other functional operations. Collections in Scala also support operations like map, filter and partition etc. Scala feels more like a fusion between functional and object-oriented programming, rather than a slightly prettier Java with closures.
Kotlin is in preview. They explicitly said they plan to extend java types like String and add a lot of stdlib stuff. Just don't forget that scala is 10 years old, while Kotlin is 6 months.
I think Xtend has extension methods for any Iterable that do what you want: http://download.eclipse.org/modeling/tmf/xtext/javadoc/2.0.1...
Point taken on Strings though - in this situation you'd want String to extend Iterable but it doesn't for historical reasons.
Point taken on Strings though - in this situation you'd want String to extend Iterable but it doesn't for historical reasons.
it has more than sugar - for example, the type system is extended to include handle nulls correctly - http://confluence.jetbrains.net/display/Kotlin/Null-safety - and it has extension functions (to solve (some of) the same kind of problems as scala's implicit conversions)
jetbrains is an interesting company. they have managed to produce a successful product (intellij idea) despite being in competition with a hugely successful open source project (eclipse). i was thinking about this just last night, when i gave up using eclipse in despair (maven nested projects, fwiw) and decided to upgrade my idea licence to the new release - it's impressive how much better it is. so they must have some smart people; i hope this works out.
jetbrains is an interesting company. they have managed to produce a successful product (intellij idea) despite being in competition with a hugely successful open source project (eclipse). i was thinking about this just last night, when i gave up using eclipse in despair (maven nested projects, fwiw) and decided to upgrade my idea licence to the new release - it's impressive how much better it is. so they must have some smart people; i hope this works out.
System.out?
Really?
Really?
That's exactly the type of verbosity in Java that new languages should avoid. I'm a bit disappointed by Kotlin in general to be honest.
Was expecting a Scala competitor, but found a slightly better Java with some syntax sugar. It's "nice", but not really different enough to warrant the effort of switching to another language. As a Java dev for 10+ years Scala was an eye opener on what a language could really be, Kotlin is "nice", but sadly not that interesting.
Minor pet peave is they have retained even Java's verbosity for outputting text:
Kotlin: System.out?.println("Hi") Java: System.out.println("Hi") Scala: println("Hi") Ruby: puts("Hi")