@spasi did. I personally like var / val, but I think you’re missing the point others were making - a language shouldn’t need a specific IDE to be adequately grokked (it’s like there’s a link between Kotlin and Intellij or something! ;D )
Nice! Does remind me of one thing I really dislike though - I hate removal of [icode]new[/icode]
I don’t mind the removal of new at all but I find myself asking, why do we even need the var / val keywords? BASIC never needed them for starters, and what is the purpose of const when you’ve got val? Or does const mean “immutable”?
Switching on types the “java way” would bother me because it’s asking for maintenance woes later on. Add a class and boom! The only recourse you have is a default case. What switching on types needs is a construct that looks exactly like try/multi-catch.
switch (clazz) {
case Camera | Light: // Union type
...
case RootNode:
...
}
or somesuch.
Cas 
I beg to differ. I started to look into building some small DSL with Kotlin, and I find it incredibly helpful to get that much assistance.
Kotlin wins over Scala (and Clojure) also (or I’d say especially) because of this
You never had, in the computer programming history, a brand new language with a first class IDE support.
Be careful to not underestimate it, an excellent support decreases the learning curve, easiers the usage and helps learning it fast.
That’s why I think Kotlin will emerge, because Jetbrains has the whole pipeline under his hands: from the IDE to the language, that’s really powerful and incredible if you think about it.
Princec, seriously, this continuous rant (no offense, eh) doesnt bring any of us anywhere 
If you want to evaluate Kotlin honestly, you should simply try it.
Because judging if a language will suit you without trying is, I repeat, quite pointless.
And I repeat, dont lose yourself the possibility to learn something you could fall in love with.
Invest some of your time, you wont regret. In the best case, you’ll come back to us thanking on your knees :D, in the worst case, you would have lost only some of your time.
Don’t you think is it worth giving it a try?
And btw, you have the perfect candidate for that test, princec: your parser.
Give it a try, convert it to Kotlin and have fun
I know there’s a ton of support for Kotlin but seriously, I’m more interested in Ceylon, which I find to be far less jarring and different for different’s sake.
Cas
That noise was the point swishing past your head! Yes, IDE’s exist to make life easier, no doubt about that.
a ha ha ha ha … hubris … Smalltalk comes to mind for a start, had this in the 70s!
So does (did) Snoracle with Java! But having other peoples’ solutions around too is a healthy thing.
Musing anecdote: the reason I got into Java so fast and wholeheartedly is that I found myself in a contract where they were using IBM VisualAge… the precursor to Eclipse. And originally developed for SmallTalk.
Cas
It’s a shame Ceylon is so underused, I really like union and intersection types. Ceylon’s approach to null safety is years ahead of Kotlin’s, but I suppose Kotlin has a gentler learning curve.
For what it’s worth, here’s an example of using LWJGL in Ceylon: https://github.com/gavinking/ceylon-examples-lwjgl/blob/master/source/eg/lwjgl/run.ceylon
Ok ok, I went too far, let’s say than since what… 2000? I’m too young for you guys ^^
It’s worth mentioning that Ceylon has first-class language support in Eclipse. And IMO is much easier to come to from Java than Kotlin as it remains lexically very similar.
Cas
Sounds like there’s a correlation between people liking/disliking Kotlin and choice of favorite IDE.
[quote=“Sickan,post:129,topic:59074”]
I’m curious to learn more, please explain.
See also: the suspicious schism that exists between Java and C# amongst Visual Studio programmers.
Cas
Cas
That article doesn’t say anything about how Ceylon’s null handling is better, in practice. It’s implemented with union types, which Kotlin does not support. What does that get me?
In Kotlin you may actually simulate union by custom setter and getter
If you ask the Scala guys, Optional is the only answer to nullability, if you ask C++ guys they start explaining you the differences between references and pointers, if you ask Ceylon people, they start talking about how great union types are…
The point is: Union and intersection types may be an elegant construct, that Kotlin lacks. Some claim that - like strucutral typing - the chance is high that this feature harms your codebase, because you lose track of your class hierarchy over time (of course, only the others do …). Fixing an existing, crappy API from someone else is very nice with this feature though, that’s probably the reason why TypeScript has it 
I don’t know in which situations Ceylon’s solution would be better than Kotlin’s, but when writing extension functions, it’s very convenient to be able to type Type?.bla() instead of something like (NULL|Type).bla(). Can anyone tell what Ceylon code looks like from Java when union types are used? I doubt it will say Object, but does it search for the most specific common superclass of all types?
EDIT: Or can you use String? as a shortcut for NULL|String literally everywhere in Ceylon?
EDIT2: AFAIK Ceylon makes heavy use of their own metafile-based implementation of reified generics, for example to make variance with this type system usable. I guess that this is pretty imperformant, so one of my first questions would be if using nullable type in Ceylon harms performance.
Yes, String? is shorthand for String | Null.
The devil is in the details but I think Ceylon is currently still the design winner.
Cas
How flexible is Kotlin in terms of coding styles/approaches etc.? What I mean is - is there any pressure to design your code in a particular way?
One of the things I found most vexing about .Net was that it forced me to take a particular approach to the flow of my application. For example, if I were writing a web application, in Java I tended to make one page submit to a second page to process the data and render a response. .Net pushed very hard to get me to make pages submit to themselves. I think it may have been possible to get it to work the way I wanted to, but it wasn’t easy. There was an attribute you could set that was supposed to do it, but the framework was so wired to work in a particular way that changing that attribute wasn’t enough.
Anyway, what I’m getting at with all of this is will Kotlin allow me to design my applications the way I want, or does it push you to use certain patterns/approaches/mindsets?
That’s nothing really to do with the language or even platform at all, but all about what APIs you’re using.
Cas