151–160 of 203 posts
Evaluated it but decided to go with C# because it didn't fix a few issues i have with java, specifically generics over value types and structs.
I've played a bit with Kotlin and have a much better knowledge of Scala, so I could be biased. I like Kotlin, it looks like Java should look like. Kotlin is "just" a better language and not a complete new World like Scala. In Scala it feels often wrong to use a Java lib instead of a Scala lib. So, Kotlin is a smooth upgrade for all Java developers. But Scala is much, much more powerful than Kotlin. Just look at Scala…
I admit to a little bias: I've tried to get into Scala several times, but the bad documentation and often overly complex approach puts me off. A lot of Scala features seem like workarounds for other features sometimes. For instance value types in Scala have so many restrictions that they are barely value types at all (e.g. they can have only one member!) and so their primary use case appears to be implementing overhead free extension methods. But Kotlin supports extension methods directly. So whilst implicits+value types may appear to be two features that Kotlin lacks, when you boil it down, it turns out that it has simpler and faster approaches to the same thing.
That said, real value classes (with JVM support) will be good when they arrive.
Earlier quoted context omitted.
FYI, I had taken "every opportunity to danger-danger-dragons-be-there" Scala — on record — years before I even dreamed of the database company that would one day have an open-source project which would end up competing with Akka (I'm talking 2009/10, while Quasar was first conceived in mid 2013). It was after leading an attempt to adopt Scala at a large organization, which failed because of what I saw as Scala's bait…
Interesting analogy, incredible how Spark drives the Scala helicopter like a car; they seem to have nailed parallel parking ;-) Seriously though, I doubt Kotlin would ever be the first choice for a project like Spark since Scala excels in the DSL department (really without rival on the JVM, and off, only Haskell comes close). Look through Spark source code [1] and you'll see: operator overloading, (sealed) ADTs, exha…
As an example, check out funKtionale. It's a library that adds various functional features like function currying and partial application to Kotlin, entirely by using its DSL features.
Earlier quoted context omitted.
It's worked out pretty well for them I'd say. Consider that any developer can write a plugin for it easily, that cannot segfault the entire app, and which runs on all the platforms the IDE supports. That's just one advantage. Higher productivity of feature development is probably another. To see how things could have been different, look at Visual Studio which is still a 32 bit program even in 2015. Users of it compl…
> Higher productivity of feature development is probably another. So productive that they had to invent a new language for the JVM platform?
Earlier quoted context omitted.
I doubt it. Java 10 is very, very unlikely to match even a fraction of the features Kotlin has. Oracle is very obviously continuing Sun's strategy of focusing on the JVM rather than the Java language. Their roadmap is pretty clear for the coming years, and it's all things like value types, better arrays, better APIs, modularity, performance, better ways to do "unsafe" stuff, etc. The only major change to the Java lan…
> Oracle is very obviously continuing Sun's strategy of focusing on the JVM rather than the Java language. Absolutely. Oracle's strategy is very simple: Java should serve as the assembly language for the server side. The JVM should be the de-facto runtime. Like pron suggests, they are actively encouraging alternative JVM languages and I wouldn't be surprised if they invest in the JRuby/Jython implementations for quic…
Earlier quoted context omitted.
There is a Haskell implementation for the JVM if you want a language like F# (it's called Frege). Kotlin has some FP features. You can easily make immutable data classes (one line definitions of struct like things), you have map/filter/reduce/etc with a much more efficient approach than Java 8's streams framework, the compiler knows about tail recursion, there's some basic forms of pattern matching. I suspect Kotlin…
Sorry, I think I was a bit unclear. I have no doubt the jvm can support a functional language - scala isn't bad and Kotlin looks really nice. My point is more that Java is constrained in how it can compete with functional jvm languages in much the same way c# is against functional clr ones. The linked article explains those limits a lot better than I could :)
We built Roll for Android ( http://tryroll.com ) in Kotlin -- we currently have ~17k lines and have been working on it since this Spring. We wanted to iterate on a lot of the software structure we came up with for our Swift iOS app, and for a bunch of pieces we needed a powerful type system. So rather than just stick with Java -- as others have said, it's way too verbose, we started looking at alternatives. We wanted…
Kotlin is great, but I would like to point out a few things: > Lambdas can be inlined! Kotlin's inline functions are meant to serve as a poor man's macro system (to implement simple control structures) and/or for argument type specialization -- not to save the "inner class overhead" because, guess what? There isn't one! While HotSpot's JIT will certainly not inline lambdas in every circumstance (though it's getting b…
Earlier quoted context omitted.
> What Kotlin still misses is somehow a good testing ability, to test it via Java Test Suites seems strange. Why? > I mean Maven really sucks Why? > Also these days a language needs Dependency Injection There's plenty of JVM libraries that provide it. Why does a language need to provide it?
> I mean Maven really sucks Why? I think after a while one gets tired of using XML as a configuration language. It's verbose and not the easiest to read. Beyond that, we used to find ourselves in dependency hell with maven pretty frequently, though that hasn't happened to me in a few years. The biggest problem, imho, is that it's inflexible. You can't just (easily) throw in a bit of functionality or make an unusual t…
"Probably"? "Thrown in"? Perhaps you can cut and paste build scripts between Gradle projects, but write anything more than "a few lines" in Groovy and you're looking at huge maintenance problems, like something that evaluated as ["abc", "defg", "hij"] suddenly becoming ['a', 'b', 'c'] for reasons that become apparent only after hours of printing debug messages.
Well, let's look at the JVM landscape. First of all Oracle has (finally) picked up the pace in terms of evolving Java and the JVM. This is a bit of a double edged sword for alternative JVM languages since on the one hand JVM improvements (like current SAMs and value types in Java 10) are a big win for all involved, but on the other, Java's evolution is very much a threat to Scala, Kotlin, and Ceylon in particular* Wh…
Gradle's bound to open up its build configuration as an API that any scripting language can use soon enough, so not sure where Groovy will be then as Android Studio ships Gradle with another default build language like JRuby, Jython, or even Clojure.