Kotlin: Statically typed programming language targeting the JVM and JS
kotlinlang.org
kotlinlang.org
I find it to be a drawback when they aren't required, because it introduces unnecessary ambiguity. If I have to wrap a long line, then there's extra syntax I have to remember to make sure the language realizes that this is all "really" a single line.
I write LiveScript and never had a problem with this.
I prefer lesser symbols on screen.
On the other hand, LS has syntactically significant whitespace which lets you indent wrapped stuff so the compiler sees that it still belongs to the previous command, in many cases.
Sorry if that's not that specific. I just in general prefer semi-colons being required, because then it fails fast rather than producing subtle bugs later.
fun main(args : Array<String>) {
println("Hello, world!")
val Kotlin = 0
will result in a type error
See this demo and try using the arrow keys to move the turtle: http://elm-lang.org/edit/examples/Intermediate/Turtle.elm
More info here: http://blog.andresteingress.com/2013/12/13/programming-andro...
And there: http://blog.jetbrains.com/kotlin/2013/08/working-with-kotlin...
The JVM is fine for multiple programming languages, as Kotlin nicely proves. And Kotlin targets Java 6 so it should work fine on Android, even though now Android supports Java 7 language features. The missing parts are the Java 7 API's: unfortunately the class library, being based on Apache Harmony (a dead project) does not move forward on Android. However this does not have any effect on Kotlin.
Compiling to native code does not change the fact the languages need to be able to interact with ART ABI, which requires Java semantics.
This is no different from the old days when OS had multiple system programming languages and C ABI != OS ABI.
I personally have yet to use Haxe, but the people I know who use it love it. I'm keeping it in mind for a good use case! Such as sharing application logic across applications, though in practice last time I did that things got very messy, it was easier just to duplicate application logic across applications. Kotlin/Haxe would be great for cross platform libraries though.
Both Kotlin and Haxe do have GADT, which is a feature I'm finding harder to live without :D Also Kotlin appears to have record types!
As far as I know, Kotlin does not have algebreic data types. It does have the nullable type `T?` which is basically Option or Maybe, but you can't define your own.
Haxe's enums are algebreic types, but I don't think it has full support for generalized algebreic data types.
Haxe is pretty awesome once you start working a server/client app from a single code base. You save so much mental energy not having to do context switching on a language, and you're not afraid to make drastic changes to logic or data structures because you're making both changes at the same time.
You can later take a Xtend-generated Java-method and start manually modifying it if needed.
I just wish Xtend had more support from others besides Eclipse. Also I hope it gets its Ant -support to a better shape, maybe it already is. It is simply a smarter simpler way to write Java. And you don't need to go Java 8 to benefit from "Lambdas".
https://github.com/spullara/java-future-jdk8/blob/master/src...
The basic idea is that if you have a bunch of Futures you can flatMap them all together and have only a single exception handling block if that is what you want. Or you can handle the exceptions at any level and convert them. Makes it very nice to handle partial failures and the like.
- Block a thread again on that promise - Keep chaining out more promises
The former choice works, but limits scalability just like the poorly parallelized code we're trying to escape from. The latter choice is infectious: it keeps pushing the inversion of flow and scheduling concerns farther and farther out.
Using Quasar's fibers to call code that's "blocking" (but secretly just jumps back into use via the scheduler) scales the same way async callbacks do -- threads are always doing real work instead of blocking -- but it doesn't have the "viral" problem. When you take a stacktrace, it's exactly the same as your old blocking code: it's an actual record of how you got here! Callback based code invariably loses that feature of stacktraces, no matter how fine of an implementation of future/promise patterns is wrapped around it.
Incidentally, lest this read as a pitch for Quasar in particular, I should mention that this entire comment could all be regex'd into a pitch for Golang's goroutines and scheduler. Quasar is just the only good implementation of it for the JVM I'm currently aware of. (Other libraries have implemented some of the backing components, like Apache JavaFlow as long ago as 2006, but I experimented with it once and found it to be a far cry from the high-level APIs I actually want to use.)
try {
var a = await Function1Async()
var b = await Function2Async(a);
try {
var c = nonAsync(a,b);
await AnotherThingAsync(c);
} catch { ... }
} catch {
...
}
finally {
...
}
Function1Async() .flatMap(a -> a, Function2Async(a)) .map( (a, b) -> nonAsync(a, b)) .flatMap(c -> AnotherThingAsync(c)) .error(e -> catch) .complete( finally );
The real code would be a little more complicated but not much.
http://jetbrains.github.io/kotlin/versions/snapshot/apidocs/...
It would also be nice to see examples of how to embed kotlin-based JavaScript in a web page, how to call JavaScript from kotlin, and how to expose a callback function to JavaScript.
A good way to help web developers get started might be to port the examples from the React front page to Kotlin.
http://hadihariri.com/2013/10/16/writing-kotlin-in-the-brows...
which discusses usage, interop and getting started.
Related, Grails 2.4 adds support for using @CompileStatic in controllers and services, whereas previously you had to keep that in separate classes in src/groovy.
1. http://groovy.codehaus.org/InvokeDynamic+support 2. http://docs.codehaus.org/display/GroovyJSR/GEP+10+-+Static+c...
Groovy's for gluing together Java and JVM apps, testing Java objects, scripting for Grails, 20-line Gradle build scripts, and what not, anything that doesn't scale.
Perhaps Kotlin will be for building large software systems is a bit more accurate.
As for Groovy, Grails performs surprisingly well[1] with Groovy as the primary language (i.e. that the developer uses to create controllers, models, etc.). Would have expected it to fall on its face with a dynamic language in use, but no, hangs in there right around the middle of the pack.
[1] http://www.techempower.com/benchmarks/#section=data-r9&hw=pe...
Are you arguing over what tense I used? When Jetbrains first announced it was building Kotlin, they wrote it would be designed to be used with IntelliJ, and that they'd then use it for their own internal software product builds. So it is for building large systems, that's its purpose.
When Groovy's creator announced Groovy, it was to be used to script Java. When Graeme Rocher took it over, he put in a MOP so it could be used with Grails, and later a DSL syntax for Gradle and a static compilation mode because it was there.
Swift, I think, is strongly influenced by design trends in modern programming languages. I didn't see a whole that in it that was new though.
data class Customer(val name: String, val email: String)
fun main(args: Array<String>){
val customer = Customer("John Smith", "john.smith@somewhere.com")
println(customer)
println("Hello Kotlin")
}
Which is quite good, given the language that shall not be named, and is quite upvoted at HN.
Earlier submission here - https://news.ycombinator.com/item?id=8036515
What we should care about is if we have interesting articles to read -- and if people that might have missed something in the past have a chance to see it, that's for the better.
There have beens lots of very lively discussions on the 3rd and 4th posting of the same story, and I wouldn't want those people to miss the post entirely, or those conversations to never happen.
As for the duplicate poster getting points from something he knows will be popular again, well, nobody cares if he does get the points. HN is not some silly high score competition.
If anything, the "duplicate submission logic" is not needed, except if we're talking about real abuse (tons of postings of the same thing that interests noone).
Reposts of items marked [dead] are generally not permitted, for obvious reasons. We won't bury this one, though.
Something we can quantitatively take away from the slur of new languages is that new languages are easier now than ever to create/implement. This should be a good thing. This means faster iteration can occur. Even if that iteration is not necessarily taking place, the creation of new languages verifies this ability.
You can't discourage people from experimenting with new languages, frameworks, design patterns, etcetera, just because some people might use it and fail.
We actually learn a lot more from failures than successes.
The problem that I see is that developers only want to work on what is new. They don't want to work with C++ because it's old. They don't want to work with Java because it's old. They don't want to work with Ruby because even it is old. It's the same thing with frameworks. There has been an explosion of frameworks because developers can't be caught dead working on something older than 6 months.
If one's intention is to rewrite entire applications every year, knock yourself out. But if you're writing apps for customers who expect it to be solid and remain in the field for a useful amount of time, then you need the reliability of C++ or Java or C. Not some language someone whipped together in a handful of weekends.
Another commenter mentioned beginning development because it was fun. I did too. It still is, but I also grew to care about the products I develop. And no, it's not fun to chase issues with immature technology when a customer is wanting answers.
I'd say that C++, Erlang and perhaps Haskell are the most recent languages to bring anything new to the table in a way that's at least somewhat usable in practice. And they're decades old at this point.
C++ helped make OO and generic programming feasible. Erlang helped with developing concurrent, distributed, fault-tolerant software. Haskell brought pure functional programming and laziness to a wider audience.
Otherwise, the widely-hyped languages of today, including Scala, Ruby, JavaScript, Go, Rust and even Kotlin generally just rehash what C++, Erlang, Haskell and other languages offered several decades ago.
Some of those languages, like JavaScript and even Go, are arguably worse in many ways than languages developed in the 1980s or way earlier.
At best, we're seeing small, incremental improvements. More realistically, we're just seeing old ideas rehashed again and again, with minor syntactic differences. Thus we aren't really seeing real "experimentation", and we aren't witnessing much "progress".
That said, ignoring the JVM in this conversation is near criminal. High performance GC, JIT, standardized profiling, etc. are all major steps forward. Are they language improvements? No, but they proved that a VM is a viable target platform and that was under serious debate in the late 90s.
Various types of VMs predated it by decades, including ones that used various forms of GC and JIT compilation. See some of the Pascal and Smalltalk implementations from decades ago as an example of these systems. These did see a fair amount of use, in practice.
The JVM isn't particularly portable. It may support most of the major mainstream OSes used today, but it's not like portable C or C++ code (including other language implementations for Perl, Python, and so forth) that can run on all sorts of obscure and ancient systems.
Its performance isn't particularly remarkable, either, even with all of the effort that some very large companies have put into it. Its been pretty much relegated to server-side use at this point, and even then we're seeing more and more effort made to move away from it. People are realizing that it's often better to go native, as we're seeing with newer languages like Go and Rust.
The JVM did get a lot of hype, and has seen a lot of use, but it's mediocre at best. There's nothing particularly earth-shattering about it.