Kotlin M7(blog.jetbrains.com)
blog.jetbrains.com
Kotlin M7
http://blog.jetbrains.com/kotlin/2014/03/m7-release-available/?utm_source=twitterfeed&utm_medium=twitter&utm_campaign=Feed%3A+kotlin+%28Project+Kotlin%29
10 comments
I've been using Scala for years now, and have never really found compile times to be an issue. I spend most of my time writing the code and thinking about it. Compiling a few times an hour takes a few seconds each time. Most Scala tools these days use incremental compilation. My IDE (IntelliJ) underlines errors using a background thread, so by the time I hit compile I already know where the issues are. It doesn't feel very different to compiling Java code (which Kotlin is aiming to match the compile times of).
If you want to optimize for only the compile dimension then Go and Pascal have very fast compilers. Python removes the need for compiling completely if that's really important to you (much faster than waiting for javac).
If you want to optimize for only the compile dimension then Go and Pascal have very fast compilers. Python removes the need for compiling completely if that's really important to you (much faster than waiting for javac).
Sorry to disappoint, Scala incremental builds + sub projects = rapid dev, usually @1 second recompile, or a few seconds if several sources need recompilation.
These days the only area where the "Scala is slow" mantra holds any water is with full builds, there, yes, cup of coffee time if you've got a large project ;-)
I think Kotlin will be squeezed from both ends (Java 8 and Scala) for uptake; that is, whenever the 1.0 stable release comes out -- sometime in 2015, right?
If so, around that time Scala 2.12 will have been released and Java 8 will have seen more & more adoption.
Will be fun to find out regardless, lots happening in JVM land these days.
These days the only area where the "Scala is slow" mantra holds any water is with full builds, there, yes, cup of coffee time if you've got a large project ;-)
I think Kotlin will be squeezed from both ends (Java 8 and Scala) for uptake; that is, whenever the 1.0 stable release comes out -- sometime in 2015, right?
If so, around that time Scala 2.12 will have been released and Java 8 will have seen more & more adoption.
Will be fun to find out regardless, lots happening in JVM land these days.
Sounds like I need to give Scala another shot if compile times are a lot better.
A very useful tip: instead of invoking sbt on the command line (i.e, 'sbt compile') every time, first open the sbt shell (just type 'sbt') and from there you run 'compile', or better yet '~compile'. This way you will always have a warm jvm. Makes a lot of difference.
Does Kotlin have immutability though? You might also want to check out Rust.
I've written a fair bit in Kotlin of late and I've got to say it's a great and pragmatic language. The writers have done a fantastic job - please don't underestimate how hard it is to write a language never mind a very good one.
I would recommend all Java developers to give it a try, especially if you use Intellij.
I'd like to counter the childlike moaning about Java being old and creaky and dated - JavaScript has been around since 1995 and was pretty much a laughing stock 10 years. Things change.
Clothes go in and out of fashion - so it seems do languages.
JavaScript has changed minimally since 1995 - but the changes that we've seen have been important. If V8 hadn't been written I'm not sure JavaScript would have had this resurgence. I also wouldn't advise anyone to assume big changes are needed to make Java more modern. The right small changes are enough (e.g. objects to C, or lambdas to Java) - I suggest that Kotlin (and very possibly Ceylon) have made the right small changes.
Right, off to write some COBOL Server Pages now ...
I would recommend all Java developers to give it a try, especially if you use Intellij.
I'd like to counter the childlike moaning about Java being old and creaky and dated - JavaScript has been around since 1995 and was pretty much a laughing stock 10 years. Things change.
Clothes go in and out of fashion - so it seems do languages.
JavaScript has changed minimally since 1995 - but the changes that we've seen have been important. If V8 hadn't been written I'm not sure JavaScript would have had this resurgence. I also wouldn't advise anyone to assume big changes are needed to make Java more modern. The right small changes are enough (e.g. objects to C, or lambdas to Java) - I suggest that Kotlin (and very possibly Ceylon) have made the right small changes.
Right, off to write some COBOL Server Pages now ...
My biggest hope for Google IO '14 is the announcement of Kotlin as the Android language. Yes, you can already use Kotlin for Android actually but it's not well-supported and the community is small.
The benefit for Google and developers would be clear -- no more Java and Oracle shenanigans. Google already has a solid relationship with JetBrains due to the fact that Android Studio is just IntelliJ CE. They could hammer out details about who owns it, what the future looks like, etc. The transition would be easy since Kotlin already plays well with Java.
JetBrains would have a massive win as well since it would drive sales of IntelliJ like no other.
The benefit for Google and developers would be clear -- no more Java and Oracle shenanigans. Google already has a solid relationship with JetBrains due to the fact that Android Studio is just IntelliJ CE. They could hammer out details about who owns it, what the future looks like, etc. The transition would be easy since Kotlin already plays well with Java.
JetBrains would have a massive win as well since it would drive sales of IntelliJ like no other.
Or Dart. That is the only way I see Dart getting any real traction on the IT world at large.
But I agree with you given the move to Android Studio, Kotlin would be a possible candidate as well.
But I agree with you given the move to Android Studio, Kotlin would be a possible candidate as well.
I spent a few minutes searching GitHub for the number of repos in different languages. The query I came up with is:
https://github.com/search?q=stars%3A0..10000&type=Repositories&ref=advsearch&l=<lang>
Kotlin 200
Dart 2,836
Erlang 9,087
Groovy 11,515
Go 24,603
Scala 25,846
For comparison...
Top 10 languages:
Top 10 languages:
JavaScript 648,839
Ruby 512,620
Java 464,330
Python 323,857
PHP 319,106
C 169,390
C++ 165,497
CSS 141,254 //not Turing complete, but oh well
C# 111,748
Objective-C 107,682
Scala 25,854
Clojure 17,532
Groovy 11,520 //seems to be mostly picking up lone Gradle build scripts
Kotlin 200
Ceylon 60
Typescript 3,042 //search function only intermittently fails
Dart 2,888
Cobol 50What most companies around the world use has very little to do with Github top languages.
I never get this trend to use Github to measure anything.
I never get this trend to use Github to measure anything.
> I would include TypeScript in the above but unfortunately the language detection for it is broken
The broke seems to be intermittent only. The Groovy results seem to be permanently broken though - most of its results are multi-language projects where Groovy is used by a single Gradle build script.
The broke seems to be intermittent only. The Groovy results seem to be permanently broken though - most of its results are multi-language projects where Groovy is used by a single Gradle build script.
[deleted]
Kotlin would preserve Google's investment in Java in a way Dart wouldn't.
Dart requires a major redo of everything. Kotlin is a nice evolution with an easy and soft transition.
The inlining feature is great, if for no other reason than shooting down stuck-in-the-past devs that say "yeah but all those function calls are so expensive".
In my experience, at least for static languages, inline annotations are very useful in the hands of a skilled programmer; the compiler's inline heuristics are always static guesses at dynamic properties and as a result they fall down from time to time. (The JVM may be able to do better here though—it has the ability to inline functions at runtime via a recompile if they discover that they're being called a lot.)
Sadly, some devs are stuck with stuck-in-the-past compilers and still have to deal with this crap.
It reminds me a bit of new devs who end up on Sybase database project and expect that "modern optimizers" always pick the right indexes.
It reminds me a bit of new devs who end up on Sybase database project and expect that "modern optimizers" always pick the right indexes.
I'm really rooting for kotlin - it seems like a good runner up to scala without the poor compile times. Looking forward to a 1.0 release
Kotlin's brilliance is how much less it's trying to do. It's truly narrowly focused on fixing what's broken in Java—not introducing an entirely new language that happens to compile to the JVM. That'll make adopting it in organizations much easier, converting code to it much easier, and so on.
That said, I never figured out why Xtend (http://www.eclipse.org/xtend/) never caught on, and it delivered most of what Kotlin is now offering, but with an even more Java-like syntax right out-of-the-box. Since Kotlin and Xtend are very, very similar, I suspect that Kotlin's ability to genuinely succeed will be mostly based on JetBrains' popularity how strongly they push it.
That said, I never figured out why Xtend (http://www.eclipse.org/xtend/) never caught on, and it delivered most of what Kotlin is now offering, but with an even more Java-like syntax right out-of-the-box. Since Kotlin and Xtend are very, very similar, I suspect that Kotlin's ability to genuinely succeed will be mostly based on JetBrains' popularity how strongly they push it.
> I never figured out why Xtend (http://www.eclipse.org/xtend/) never caught on....
> ... with an even more Java-like syntax
I think you have your answer right there.
The other reason is that nobody likes the idea of having a language which compiles to Java source code.
> ... with an even more Java-like syntax
I think you have your answer right there.
The other reason is that nobody likes the idea of having a language which compiles to Java source code.
People have no real problem with languages that compile to C or JavaScript, so I'm not really convinced that's the problem as such. The lack of source maps/#line pragmas in Java didn't help, I'm sure, but these are solvable problems if there's interest (as demonstrated by #line and source maps).
> The other reason is that nobody likes the idea of having a language which compiles to Java source code.
Why not? It seems like a good thing if there is a possibility that you might have to go back to Java (if that make sense) or if some time down the road it is simpler for maintainers to go over to Java by reading the compiler output rather than dealing with xtend, if they don't know it. It could also be great if you want to quickly know what the equivalent of what you are writing in xtend is in java - just compile it. That seems more interactive than having to google or look up on StackOverflow.
Of course this assumes that the compiler output is actually readable.
Why not? It seems like a good thing if there is a possibility that you might have to go back to Java (if that make sense) or if some time down the road it is simpler for maintainers to go over to Java by reading the compiler output rather than dealing with xtend, if they don't know it. It could also be great if you want to quickly know what the equivalent of what you are writing in xtend is in java - just compile it. That seems more interactive than having to google or look up on StackOverflow.
Of course this assumes that the compiler output is actually readable.
I thing it's because of the pain you feel when you try to debug in Xtend (coz its compiling to Java)
To me Xtend seems like an ideal Java++. I actually like that it compiles down to Java.
The only hitch is that the Xtend is still very much a work in progress. It doesn't support inner classes and anonymous classes!
The only hitch is that the Xtend is still very much a work in progress. It doesn't support inner classes and anonymous classes!
Because we don't know what Eclipse wants to do with it.
I'm not really seeing the case for Kotlin. If I want the most powerful language possible on the JVM, I use Scala. If I want a clean and elegant language, I use Ceylon - I don't think you can get that from a language that keeps the Java standard library. Prior to Java 8 I could maybe see the case for a language that's just Java with lambda and a few other niceties, but now that Java 8's out, if I'm going to go to the trouble of switching to a new language I want a bigger return on that cost than Kotlin offers.
A good alternative for Java on Android given Google's fork and not so good support for Scala and Clojure on Dalvik/ART?
Oh, I just wrote my (one, rather simple) android app in Scala. Are there problems with it?
Executables are slower and bigger than Java even with ProGuard, specially given how outdated Dalvik GC/JIT are.
Maybe this will improve with ART.
Maybe this will improve with ART.
Maybe they are slower to some extend, but for most cases it won't matter too much. I wrote simple game in scala and it was easy to constantly get 55-60 fps on newer devices: https://github.com/pkukielka/stronghold-defense
That being said I agree that jars are bigger and scala generates much more anonymous classes. Even with ProGuard that could be a problem on Android 2.3 or older. And ProGuard is a bit slow (for my game it was taking 30+ seconds for every build). Also Typesafe doesn't have plans for making scala first class citizen of Android.
So while Android development with scala is certainly possible there are few inconveniences which one should be aware of.
That being said I agree that jars are bigger and scala generates much more anonymous classes. Even with ProGuard that could be a problem on Android 2.3 or older. And ProGuard is a bit slow (for my game it was taking 30+ seconds for every build). Also Typesafe doesn't have plans for making scala first class citizen of Android.
So while Android development with scala is certainly possible there are few inconveniences which one should be aware of.
Nice game!
It tends to generate lots of anonymous classes, which can make your jar bigger.
I think it's massively less ambitious, which is a good point in its favour.
It might be the least ambitious new language of the last ten years!
I think that trophy is won pretty handily by Go.
I wanted to say Go as well, but compared to any other possibly-mainstream languages, Go is very innovative - it has fibres/goroutines, channels, and structural typing/lack of class-based inheritance!
The bar for what counts as "innovation" in mainstream languages is strikingly low.
All of which are available in other languages...
In addition to the fact that none of it's features are particularly novel lets remember that Go's founding ambition was "compile faster than C++"
And people disparage them for it, which is nuts. Google had a problem that they determined could best be solved by creating Go. So they did it, and presumably, they've solved their problem. That seems like a perfectly good use of incremental improvement.
Which raises an interesting point: what to people on the outside looks like a paradoxical combination of insane hubris and deep technical conservatism is probably simply what to Google's eyes looks like steady-state, responsible technical problem-solving -- c.f., hhvm and Facebook for a similar approach.
Which raises an interesting point: what to people on the outside looks like a paradoxical combination of insane hubris and deep technical conservatism is probably simply what to Google's eyes looks like steady-state, responsible technical problem-solving -- c.f., hhvm and Facebook for a similar approach.
> Go's founding ambition was "compile faster than C++"
And Kotlin's is "compile faster than Scala"!
And Kotlin's is "compile faster than Scala"!
Actually, Go's fairly successful melding of static typing and duck-typed interfaces was a useful new trick. (Which doesn't completely excuse the "C++ tried that and it didn't work for them so WE WON'T" foot-dragging on other matters...)
>Go's fairly successful melding of static typing and duck-typed interfaces was a useful new trick
For those that don't know this feature is called structural typing: http://en.wikipedia.org/wiki/Structural_type_system
Also, OCaml uses structural typing too.
For those that don't know this feature is called structural typing: http://en.wikipedia.org/wiki/Structural_type_system
Also, OCaml uses structural typing too.
No it was not, there are lots of languages that offer similar capabilities.
The fact that mainstream developers don't know it, does not make it something that Go designers invented.
The fact that mainstream developers don't know it, does not make it something that Go designers invented.
OCaml already had structural typing. Scala does too.
Actually I think Hack might've just surpassed it.
You mean, except Dart.
Let's just agree that Google couldn't design a language even if its life depended on it.
How about "Google has a surprisingly conservative culture".
I wouldn't call "ignoring stuff from 1970" conservative.
They're using Java very widely, you don't get much more conservative than that.
Plus, its interoperation with Java is so seamless, that adoption is both gradual and natural.
Looks decent, but I find it difficult to get excited about. Perhaps I'm not the target audience since I'm very comfortable with Scala (and love what Jetbrains is doing with the Scala IntelliJ plugin).
I think of it not as a stand-alone language, but rather as a strong statement of position in the Java-the-language arguments about future direction. It's a way for the Jetbrains people to influence the way the language will evolve.
Agree. I'm always amazed by people who say "Kotlin is great because it doesn't try to do more than fix a few warts of Java!", ... did these people ever leave their Java bubble?
The world is moving on at a frightening speed when it comes to language design currently, largely thanks to Idris. The idea that some people think "hey, let's pick this language from 1995 and change it slightly" is going to cut it ... that's just mind-boggling.
The world is moving on at a frightening speed when it comes to language design currently, largely thanks to Idris. The idea that some people think "hey, let's pick this language from 1995 and change it slightly" is going to cut it ... that's just mind-boggling.
I find it completely reasonable, and the right course of action.
All those new ideas in language design, are exactly that: new and unproven (like the Hindley-Milner type system, which, while quite old already, has not been proven to be a major strength, and it is certainly complicated, esp. its undecipherable error messages).
"Languages from 1995" (I don't know why you picked that specific year; some very successful languages are much, much older) have been used to build really good software, while "new" languages (Heskell, 1990; OCaml, 1996; Scala, 2003) have not proven to completely change software quality in a way just justifies their arguably less intuitive (if only culturally) designs.
Where are all the bug-free Haskell operating systems, drivers and embedded controllers? Where are the OCaml scalable severs? Where are all the Scala complex enterprise apps? I'm not saying there isn't any really good software written in those languages, but not nearly enough to prove a significant qualitative advantage.
On the other hand, when Java came out in 1995, it took maybe 5 years for pretty much the entire software world to adopt it, and it wasn't just marketing: its advantages were palpable and immediately apparent. I think (though I'm not sure), that C and later C++'s adoption was about as fast. If 25 year old languages like Haskell, and even 10 year-old languages like Scala, haven't shown such an immediate and enthusiastic widespread adoption, maybe their advantages aren't that extreme. Instead of those languages' designers sitting mind-boggled, maybe they should think long and hard about what it is that they're solving exactly and how important it really is.
I think the problems tackled by more "modern" languages are either not important enough, or their solution is far from optimal. For example, it is quite possible that a good type system could help produce good software faster (though it isn't certain either), but that this type system is Hindley-Milner seems unlikely at this point. Pluggable type systems (like the ones recently introduced to that 1995 language, and, I believe, also supported by Kotlin) might actually be a better way to go forward. I also think that some more important advances in programming languages have come not from PL researchers, but from developers (Java, Erlang, Clojure).
All those new ideas in language design, are exactly that: new and unproven (like the Hindley-Milner type system, which, while quite old already, has not been proven to be a major strength, and it is certainly complicated, esp. its undecipherable error messages).
"Languages from 1995" (I don't know why you picked that specific year; some very successful languages are much, much older) have been used to build really good software, while "new" languages (Heskell, 1990; OCaml, 1996; Scala, 2003) have not proven to completely change software quality in a way just justifies their arguably less intuitive (if only culturally) designs.
Where are all the bug-free Haskell operating systems, drivers and embedded controllers? Where are the OCaml scalable severs? Where are all the Scala complex enterprise apps? I'm not saying there isn't any really good software written in those languages, but not nearly enough to prove a significant qualitative advantage.
On the other hand, when Java came out in 1995, it took maybe 5 years for pretty much the entire software world to adopt it, and it wasn't just marketing: its advantages were palpable and immediately apparent. I think (though I'm not sure), that C and later C++'s adoption was about as fast. If 25 year old languages like Haskell, and even 10 year-old languages like Scala, haven't shown such an immediate and enthusiastic widespread adoption, maybe their advantages aren't that extreme. Instead of those languages' designers sitting mind-boggled, maybe they should think long and hard about what it is that they're solving exactly and how important it really is.
I think the problems tackled by more "modern" languages are either not important enough, or their solution is far from optimal. For example, it is quite possible that a good type system could help produce good software faster (though it isn't certain either), but that this type system is Hindley-Milner seems unlikely at this point. Pluggable type systems (like the ones recently introduced to that 1995 language, and, I believe, also supported by Kotlin) might actually be a better way to go forward. I also think that some more important advances in programming languages have come not from PL researchers, but from developers (Java, Erlang, Clojure).
He picked 1995 because of, obviously, Java. He was talking about Java :)
> when Java came out in 1995, it took maybe 5 years for pretty much the entire software world to adopt it, and it wasn't just marketing: its advantages were palpable and immediately apparent. If 25 year old languages like Haskell, and even 10 year-old languages like Scala, haven't shown such an immediate and enthusiastic widespread adoption, maybe their advantages aren't that extreme.
Any number of companies are still using C++, which itself took decades to reach the level of popularity that it did; Java is the exception rather than the rule in that regard. (And if we're just comparing popularity, I don't know how it is in your corner of the industry, but Scala growth has been massive over the last few years where I've been looking - and that's not based on Sun's marketing millions, but on word of mouth from people who're using it and finding that it helps them write better programs)
Any number of companies are still using C++, which itself took decades to reach the level of popularity that it did; Java is the exception rather than the rule in that regard. (And if we're just comparing popularity, I don't know how it is in your corner of the industry, but Scala growth has been massive over the last few years where I've been looking - and that's not based on Sun's marketing millions, but on word of mouth from people who're using it and finding that it helps them write better programs)
I don't think I would call Scala's adoption "massive", but for the sake of this discussion, let's say I agree. Now, Scala has many features; which of them, do you think, are the largest contributors to that adoption? Hindley-Milner? Implicits? Type-safe macros?
I'd argue that it's lambdas, traits (both now in Java 8), and reduced boilerplate for Java beans; also, maybe pattern matching. Now, all of those features are in Kotlin, which has a far simpler (though less expressive, even though that hasn't been proven to be a major problem) type system and much, much smoother integration with Java.
I'd argue that it's lambdas, traits (both now in Java 8), and reduced boilerplate for Java beans; also, maybe pattern matching. Now, all of those features are in Kotlin, which has a far simpler (though less expressive, even though that hasn't been proven to be a major problem) type system and much, much smoother integration with Java.
> Hindley-Milner?
If you spent a few minutes actually using Scala instead of trying to bash and hate it in every thread, you'd know that Scala doesn't use HM.
Scala killer feature is the assurance that developers can express the things they want, unlike Java and C# where the compiler starts acting like an angry child as soon as I want to do anything slightly more elaborate.
That won't be changing anytime soon.
> a far simpler (though less expressive, even though that hasn't been proven to be a major problem) type system
The lack of typeclasses is a non-major problem? I would say it is an absolute dealbreaker.
Anyway, in what sense it is "far simpler"? Most of the complexity comes from dealing with Java's broken ideas. If Kotlin wants interop, it can't ignore that.
If you spent a few minutes actually using Scala instead of trying to bash and hate it in every thread, you'd know that Scala doesn't use HM.
Scala killer feature is the assurance that developers can express the things they want, unlike Java and C# where the compiler starts acting like an angry child as soon as I want to do anything slightly more elaborate.
That won't be changing anytime soon.
> a far simpler (though less expressive, even though that hasn't been proven to be a major problem) type system
The lack of typeclasses is a non-major problem? I would say it is an absolute dealbreaker.
Anyway, in what sense it is "far simpler"? Most of the complexity comes from dealing with Java's broken ideas. If Kotlin wants interop, it can't ignore that.
> Scala killer feature is the assurance that developers can express the things they want
If you mean "some developers" or alternatively "some of the things they want" (this set of things being strictly greater than the set of things available in Java), I'll agree with you.
If you mean "some developers" or alternatively "some of the things they want" (this set of things being strictly greater than the set of things available in Java), I'll agree with you.
Tuples, Pattern matching, Structural types, Implicits, Collections framework etc. etc.
One of the biggest advantages of Scala is the community. Java has a culture of excessive over-engineering, boilerplate and XML. The Scala community tends to think more in terms of a fresh start, rather than seeing themselves as a Java extension. The extreme resistance to change within the Java community and unwillingness to look beyond the only tool in their toolbox makes are also major issues. Every feature is unnecessary complexity and evil until it gets added to Java, and then suddenly the "evil" feature in C# or Scala is suddenly an amazing new "innovation".
One of the biggest advantages of Scala is the community. Java has a culture of excessive over-engineering, boilerplate and XML. The Scala community tends to think more in terms of a fresh start, rather than seeing themselves as a Java extension. The extreme resistance to change within the Java community and unwillingness to look beyond the only tool in their toolbox makes are also major issues. Every feature is unnecessary complexity and evil until it gets added to Java, and then suddenly the "evil" feature in C# or Scala is suddenly an amazing new "innovation".
> Now, Scala has many features; which of them, do you think, are the largest contributors to that adoption?
Low-boilerplate syntax is certainly a big plus, but I think the biggest feature of scala is that it makes it easier to handle cross-cutting concerns without stepping out of the language. Concretely: a consistent, natural syntax for async calls; better ways of handling errors (validation monad), dependency injection without reflection. And almost as important is the ability to construct DSLs in the language itself (e.g. spray's routing syntax); I know at least one company where this was the primary rationale for adopting scala.
So I think higher-kinded types are a key feature, even if to start with users are only using the libraries built on top of them (you can do specific bodges like C#'s async/await without them, but to have a consistent, extensible syntax that does collections, async calls, and error handling you really need the higher level of abstraction), as are implicits and dependent types (both vital for DSLs). And there were certainly times when I found myself wishing for macros before they existed. Some users might come for the syntax or the traits (though I think error-handling and good async abstractions are at least as appealing, particularly in finance where a lot of the adoption is happening), but you stay for the type system.
Low-boilerplate syntax is certainly a big plus, but I think the biggest feature of scala is that it makes it easier to handle cross-cutting concerns without stepping out of the language. Concretely: a consistent, natural syntax for async calls; better ways of handling errors (validation monad), dependency injection without reflection. And almost as important is the ability to construct DSLs in the language itself (e.g. spray's routing syntax); I know at least one company where this was the primary rationale for adopting scala.
So I think higher-kinded types are a key feature, even if to start with users are only using the libraries built on top of them (you can do specific bodges like C#'s async/await without them, but to have a consistent, extensible syntax that does collections, async calls, and error handling you really need the higher level of abstraction), as are implicits and dependent types (both vital for DSLs). And there were certainly times when I found myself wishing for macros before they existed. Some users might come for the syntax or the traits (though I think error-handling and good async abstractions are at least as appealing, particularly in finance where a lot of the adoption is happening), but you stay for the type system.
>I'd argue that it's lambdas, traits (both now in Java 8), and reduced boilerplate for Java beans
Those are the reasons people get in to scala from Java, but not the reason they stay.
Implicit conversion/parameters, higher kinds, and monadic comprehension are the reasons people stay in Scala.
Those are the reasons people get in to scala from Java, but not the reason they stay.
Implicit conversion/parameters, higher kinds, and monadic comprehension are the reasons people stay in Scala.
A sure sign that somebody has run out of arguments is bringing up "popularity" in language design topics.
The funny thing about your comment is that you could have made the exact comment in 1995 to dismiss Java. Sometimes it just takes very long for ideas to reach mainstream, but they can nevertheless become extremely successful.
The most important innovation in the Hindley-Milner type system was parametric polymorphism, since that is the thing that enables you to build more powerful abstractions. Since the release of Java 1.5 and C# 2.0 that is now fully mainstream, but it took more than 25 years.
The most important innovation in the Hindley-Milner type system was parametric polymorphism, since that is the thing that enables you to build more powerful abstractions. Since the release of Java 1.5 and C# 2.0 that is now fully mainstream, but it took more than 25 years.
Oh, I have nothing against new ideas in programming languages, and I think the more "researchy" programming languages are invaluable to the community in the insights they provide on what works and what doesn't. I was simply responding to the befuddlement that the industry prefers languages that adapt ideas slowly, rather than those that are cutting-edge.
> If 25 year old languages like Haskell, and even 10 year-old languages like Scala, haven't shown such an immediate and enthusiastic widespread adoption, maybe their advantages aren't that extreme.
Haskell advantages are so extreme they elude most.
What were Java first 5 years advantages ? Wasn't it all 'Java is client-side silver bullet' ?
ps: by Pluggable Types did you mean Type Annotation http://openjdk.java.net/projects/type-annotations/ or just the Checker Framework ? http://types.cs.washington.edu/jsr308/
Haskell advantages are so extreme they elude most.
What were Java first 5 years advantages ? Wasn't it all 'Java is client-side silver bullet' ?
ps: by Pluggable Types did you mean Type Annotation http://openjdk.java.net/projects/type-annotations/ or just the Checker Framework ? http://types.cs.washington.edu/jsr308/
Type annotations are the frontend to the pluggable type systems provided by Checker (but they were added to Java 8 in order to support Checker):
http://docs.oracle.com/javase/tutorial/java/annotations/type...
EDIT: I think Java's initial advantages were taking good C++ concepts, simplifying them, and running in a safe environment (GC memory, app can't just crash etc.).
http://docs.oracle.com/javase/tutorial/java/annotations/type...
EDIT: I think Java's initial advantages were taking good C++ concepts, simplifying them, and running in a safe environment (GC memory, app can't just crash etc.).
That amounts to Guy Steele quote about moving halfway to Lisp. Haskell is on that same road, just way further.
I think it's more people are excited about Kotlin because it gives you some of the best parts of Scala without the long tail of confusing stuff. Sure, it's not revolutionary, but if the base level for everyone is ratcheted up a notch or two, it makes the next move even easier.
It feels like a trial version of Scala with some of the juiciest features missing until you upgrade.
Well, it's not all about the language. For me, and others, who are aware and have dwelved in advanced languages (such as Scala, Haskell, Lisp family), Java is often our choice for even hobby projects. It's not that we cannot see other languages's benefits. It's that in our opinion it's the best choice all things considered (how efficiently one can write readable/refactorable code being one of the most important things).
Kotlin seems to be one very good alternative in the future.
Kotlin seems to be one very good alternative in the future.
Does anyone know of a specific production use-case where coding for eager evaluation (Idris, OCaml) is more straightforward and predictable when lazy evaluation could be cheaper on computing resources (Haskell)? When does lazy evaluation become too nondetermistic or painful that eager becomes more reliable? (Scala could probably go in either bucket.)
Well, I'd say most of the time... Where I find laziness (or "laziness implemented via iterators") worthwhile is when working with collections. But I much prefer the bits that care about such thing to explicitly return an iterator, the bits which don't to be able to operate either on iterators or concrete collections, and me to have a better idea of how much space and time will be consumed.
Kotlin homepage: http://kotlin.jetbrains.org/
I fail to see what it offers over Ceylon. http://ceylon-lang.org For the past two years I feel that Kotlin has gotten more hype than work put in it.
I think the main difference is that Kotlin fully embraces the current Java ecosystem, and makes integration with it seamless, while Ceylon rejects it and seeks to replace it with something new. Personally, I prefer Kotlin's gradual approach to Ceylon's revolutionary one.
It is done by JetBrains, a company with good experience doing amazing developer tools.
Their WebStorm IDE is partially done in Kotlin.
Android Studio is based on InteliJ and also supports Kotlin.
Ceylon is a me too JVM language from RedHat without eco-system around it.
Their WebStorm IDE is partially done in Kotlin.
Android Studio is based on InteliJ and also supports Kotlin.
Ceylon is a me too JVM language from RedHat without eco-system around it.
Kotlin, lets bring back the good old times.
It's a step back, lets me explain:
Like Scala, it's strongly(stringly) typed, needs IOC to get to work.
Modern langs used like node.js, rails, django, go, grovy are all dynamic.
Modern langs used like node.js, rails, django, go, grovy are all dynamic.
You downvote that? that's rich.
What Kotlin seems to be getting right so far is the useful side of functional programming features, IDE support, and a reasonably fast compiler. Compiler speed is something that Kotlin actually cares about, which last time I played with Scala, it was still dog slow to compile or even wait for it to decide to compile after you make a change.
Developer experience is very important to me and for the kind of software I want to build and the way I want to build it, Kotlin looks very promising.