Kotlin: A statically-typed language that compiles to JVM bytecode and JavaScript
kotlin.jetbrains.org
kotlin.jetbrains.org
Kotlin feels like an incremental improvement over Java that I can wrap my head around and it comes with stellar IDE support right out of the box.
I hope they release a 1.0 soon so we can see if it gains traction, but it will be challenging, because Java certainly seems invincible right now, and probably for years to come thanks to the imminent Java 8.
Kotlin is a very practical, well thought-out language, that was designed with the right approach re language features: if in doubt, leave it out. The result is simple, modern and powerful, with – and this one is extremely important – top notch Java integration. It is extremely easy to integrate Java and Kotlin in the same project, and easy enough to go back to Java if Kotlin doesn't catch on. Kotlin is very easy for Java developers to learn, and easy to read and understand if they haven't learned it. It feels very unobtrusive when introduced into a Java project.
Not just compared to Scala but any other language. I actually think Kotlin is more similar to Groovy than Scala. Sure the facade is veri similar, but the philosophy and internals are very different. Also founders of Groovy and Groovy++ (statically typed) are involved in Kotlin development.
Most of Scala was created by postdoc and students. Kotlin was created by java company who want to scratch their own itch.
I especially like that Kotlin is 100% compatible with Java. I think best trick in language design is how Kotlin interacts and adds new features into legacy Java codebase. For example it introduces 'immutable collections' into existing Java Collection hierarchy without modifications.
Even though the students and postdocs definitely contributed, it is still probably accurate to say most of Scala was created by Martin Odersky.
Scala is more like ecosystem on its own.
And is Kara better than (for example) Grails? Are we going to be stuck writing Spring MVC?
Also, I've written Wasabi (Sinatra/Express like framework) and am using it on a project.
http://github.com/hhariri/wasabi
I also know of quite a few people using it already.
Scala has very little syntactic rules. Of course if you dont take the time to learn them , you are not going to understand the language.
There are a lot of counter examples to this claim but just to keep this short, I'll go along with your claim.
A downside of this is heavy overload of keywords/symbols. For example, last time I checked, the underscore (_) has six different meanings depending on where it's used.
The number of syntactic rules is not a good way to judge whether a language is difficult to read, otherwise, Brainfuck would be the most readable language on the planet.
no it has not ,it always express some kind of default behavior. just like ! in ruby method means mutation or ? means it returns a boolean.
> The number of syntactic rules is not a good way to judge whether a language is difficult to read, otherwise, Brainfuck would be the most readable language on the planet.
But we are not talking about Brainfuck.
> no it has not ,it always express some kind of default parameter.
You might want to refrain from commenting on a topic you don't seem to know much about.
I was wrong when I said "six", it looks like the number is up to eleven today. Here is a short list:
- Existential types
- Higher kinded type parameters
- Ignored variables
- Ignored parameters
- Wildcard patterns
- Wildcard imports
- Hiding imports
- Joining letters to punctuation
- Assignment operators
- Placeholder syntax
- Partially applied functions
More details: http://stackoverflow.com/questions/8000903/what-are-all-the-...
the underscore is not an operator.that's why you are listing random stuffs that are not related. It express an intent, see my previous message.
You might want to stop patronizing people you dont know. Or your head is too big for that.
Actually, it can express eleven intents, depending on where it's being used.
The bang (!) does not mean "destructive" nor lack of it mean non
destructive either. The bang sign means "the bang version is more
dangerous than its non bang counterpart; handle with care". Since
Ruby has a lot of "destructive" methods, if bang signs follow your
opinion, every Ruby program would be full of bangs, thus ugly.
_ has only one meaning => "unspecified"
http://www.reddit.com/r/programming/comments/uk015/kotlin_m2...
EDIT: Scala does have an incredible compiler, though, and it is interesting from a PL research POV (which is to be expected, given its origins). The JVM community will forever be indebted to Scala. But it is not a language that many will feel comfortable using, and most of those that do, use a subset of it (which is basically Kotlin), and ignore the fact that they can't understand how the linked list is implemented. Kotlin takes a lot of inspiration from Scala, obviously, and learns from its mistakes. It takes that subset of Scala that gives people 99.9% of what they want and need with only 10% of the complexity.
Learning Scala's type system takes time, yes; it quite possibly takes longer to learn Scala than most languages. But it's still going to be less effort than learning two different languages.
I think that most organizations are already using a lot of code that they don't understand. The JVM itself is many thousands of lines of not especially clear code; I suspect very few java-based organizations really understand it (and I've hit bugs in the JVM in real life, so it's not that there's no need to understand it). Likewise large, popular Java libraries like Spring and Hibernate (particularly given that they do bytecode manipulation, so you can't always even assume that the normal rules of the language apply).
I think standard library implementations are rarely read in any language, so the complexity of the standard library implementation in scala isn't a concern. I think the interfaces are important, and if users are unable to understand the method signatures then that's a problem. But documenting what a method does is often seen as adequate (e.g. in Python or Ruby the documentation is the only interface signature you get), so I don't see a fundamental problem with the "simplified signature in the documentation" approach (though it would be better to have some way of automatedly ensuring these were correct).
(The only alternative would be to give up the power entirely, or to have two distinct collection libraries; neither of those seems like a good answer. If you don't see having Haskell-level language power as an advantage, then yes the complex library interface is not worth it and you'd be better with a less powerful language. But if you see value in writing parts of your system in something like Haskell, I think it's a big win to be able to use the same language for the haskell-like parts and the kotlin-like parts, and learning a complex library is less overhead than learning a second language).
I think not, and here's why: we're talking about large organizations here, right? Because if you're a single developer or a small team, then anything from assembly to VisualBasic goes and it all pretty much boils down to personal preference. But in a large team (say 50 people and up), only one or two would need to master the "Haskell part" (assuming there was a real need for one), and the rest would use Kotlin. So there is no overhead in learning two languages. The developers would learn one simple language that they can understand, and the single star developer (there is usually one in any team) could probably master five different languages if the need arises. Throwing everything in a single powerful-yet-very-complex does not fit with how complex software is actually developed. This is one of the reasons many huge organizations abandoned C++ and flocked to Java pretty much on the day it was released (I'm exaggerating, but in a software-timeframe terms that's pretty much what happened).
The worst company I worked for was the one where the dev team was split into three - the frontend guys working in PHP, the backend guys doing mapreduce stuff, and the middle team in Java. No-one understood what the others were doing, so there was no sense of the overall product, and bugs or features would get thrown over the wall to another team and then come back weeks later, by which time everyone had forgotten about them.
My last job worked in Scala, and had what was essentially a transactional framework using monads. I reckon at most three of the developers there actually understood the transaction library, and probably only two would actually have added new features to it. But everyone was able to write code that used it, and being able to see the code in the repository and their IDE, at least some of the other developers were able to pick it up gradually, from the outside in, learning more and more, starting to fix bugs that were similar to problems they'd seem elsewhere, and eventually reaching a full understanding. If that code had been written in a different language I think they would never have taken the first step.
Of course (as long as those responsible for maintaining that portion understand their libraries)! Since we agree that some parts of the code are specialized and reserved for experts anyway, what difference does it make if it's written in a different language?
This is not like your story at all about PHP, Java and mapreduce. In my scenario, everyone is using the same language except for the "expert portion", which comprises maybe 2% of the code. I think it is far better than having everyone use a complex language which they don't fully understand, just so that the experts working on that 2% will be nominally using the same language (I say nominally, because in the Scala case it would hardly be the same language – only the same compiler). I don't want to pay the complexity price for everyone for the power needed only for the 2%.
ADTs/pattern matching are not "a complete type system". Structural types are not "a complete type system". Scala unifies the different concepts by expressing them through Java-style classes and inheritance.
Even if they were incompatible non-orthogonal type systems sitting side by side (they aren't), it is immensely useful to have both dynamic dispatch and ADTs/pattern matching in the toolset; they are often useful for different problems.
Why not? Can you not write any program using either? Haskell uses just the former, and JS the latter (though without type safety).
> Scala unifies the different concepts by expressing them through Java-style classes and inheritance.
I think it "unifies" them only in the sense that the (single) compiler can compile all three. But case classes cannot be part of an inheritance hierarchy nor structural types (or inheritance types) be used as ADTs. The three certainly intersect, but they're not really unified.
> It is immensely useful to have both dynamic dispatch and ADTs/pattern matching in the toolset; they are often useful for different problems.
Obviously, and that is why some languages employ the one or the other. The question is, how useful is it (from a cost/benefit perspective) to have all three (plus macros!) in the same language? After all, while each has its benefits sometimes, they also overlap a lot, as most programs are about as easily implemented in all three. As I've said elsewhere, in language design, as in most things, one must choose. A pizza, a steak and ice-cream all have their place, but may lose much of their flavor if mixed into the same dish. In the JVM ecosystem we are lucky enough to have easy interoperability between languages. The JVM is a restaurant with a varied menu, and you can have a meal of several courses. The best way to go, IMO, is to pick one simple language you're comfortable with and use it for most tasks, and for those tasks that require specialized skills outside your chosen language's strengths – use another.
While you can make do with either, they have complementary strengths and weaknesses, which are useful in different situations. See "Expression Problem", and "Visitor Pattern".
> Why not?
"Single Dispatch Polymorphism" is a language feature. ADTs/pattern matching are a language feature. Subtyping is a type-system feature. "Structural Typing" is a type-system feature. Guaranteeing exhaustive pattern matching is a type-system feature. They are not "type systems", and different languages pick them and combine them a la carte.
> But case classes cannot be part of an inheritance hierarchy nor structural types (or inheritance types) be used as ADTs
Yes they can, and they do. You just can't extend case classes from other case classes. You can use any class as an ADT-like structure if you want, leaving the hierarchy open or closed, and defining pattern matching extractors as you please. It's all part of the same system; whether you call it an "ADT" or a "class hierarchy" is a design pattern thing more than a rigid systemic property.
> Obviously, and that is why some languages employ the one or the other
Er... that doesn't follow. What I said is that it's very useful having both together. If you don't think that's valuable, that's fine; Scala's not for you.
> It's all part of the same system; whether you call it an "ADT" or a "class hierarchy" is a design pattern thing more than a rigid systemic property.
Obviously it's part of the same system, which just happens to be a superset of three type systems. A type system is not how its implemented but what it does.
Verbatim even.. a copy paste :p
So yeah, if it takes several paragraphs to explain why something that can be as straightforward as this (Haskell)
(a -> b) -> [a] -> [b]
is actually not that complicated when it looks like this
def map[B, That](f: (A) ⇒ B)(implicit bf: CanBuildFrom[List[A], B, That]): That
it is clearly the stupid infidels that don't get it. This doesn't mean that Scala is a bad language in general, just that it is ridiculous to state that it isn't complex, especially compared to Lisp.
It's debatable whether the complexity of the API is worth the additional functionality, but the basic version of map (Data.List.map :: (a -> b) -> [a] -> [b]) is utterly trivial in either language.
Eh? No language extensions necessary.
fmap :: Functor f => (a -> b) -> f a -> f b
Are you sure this is true? Compared to what?
I use it everyday for work, and it's an excellent language. I think it "falters" because it's more ambitious than anything else. Kotlin doesn't look as ambitious so far. I'd rather stick with Scala and see them keep improving. There are some promising ideas in the pipeline for future simplification without loss of power: http://www.infoq.com/presentations/data-types-issues
But it's yet another language with strings-are-a-list-of-code-units. I've mentioned it before, but I'd like more languages to follow Haskell/Python's suite of "String are a list of code points", at the very least. (Those as others have point out, while dealing with code points is less error prone than code units, you probably want something even higher level.)
Integers are still range-limited. For some things this is okay, for some things it'd be nice to not worry about what happens when you get near 4B. Python solved this nicely. (There's a place for range-limited ints, and you can always have a ranged_int<0, 65565> type, or something. But by default, I don't want to think about overflow!)
Generics appear to be C#/Java like (i.e., limited, not full meta-programming).
Some things that run when targets to the JVM don't in JS. `for(c in "a string")` didn't compile for JS, nor did `1000000000000000 or 0`. (To be sure, this isn't exactly easy.)
(Last, the issue tracker infinite-redirects, likely because it doesn't handle a browser rejecting cookies.)
A code point is a character, that may be encoded by a single code unit or may require multiple code units.
Mostly Java handles strings as 16bit code units, code point functions were only introduced at 1.5.
Is this just a way of saying "variable bit length character encoding?"
The point is that it's better to treat strings as sequences of unicode codepoints ("characters") than treat them as sequences of 16-bit utf16 units like Java does.
For example, the demo video that prints an ArrayList of Integers raises more questions than it answers, given that JavaScript doesn't have Integers or ArrayLists and has different built-in stringification (which is always idiosyncratic from language to language). Can I write portable code that uses arrays?
Some quick poking around indicates that Kotlin is pretty JVM-centric for someone who works in the web world. (I used to write a lot of Java and Scala and even wrote a mini JVM once, but these days JavaScript is my go-to platform.) There's good old byte/short/int/long and there's boxing of primitives. They don't even bother to mention that arrays have immutable size (like Java and unlike JS), presumably because they assume it's obvious.
Inexplicably, the English words "and" and "or" are used for bitwise operations while && and || are unchanged. Hate to criticize but it all just seems rather strange.
For JavaScript, check out:
http://blog.jetbrains.com/kotlin/2013/10/writing-kotlin-in-t...
Now my question :
Why didnt you chose an existing language like Dart for instance?which would have been closer to java and still compile down to javascript. I think dart on the jvm would be a great idea.
Regarding Dart, AFAIK, we started working on Kotlin before Dart and Kotlin was first focused exclusively to target the JVM. The JavaScript came afterwards.
I'm starting to suspect Kotlin is a unified syntax but doesn't actually have any unified semantics, or considers all heap objects to be "foreign" and owned by either Java or JS.
I was expecting to hear one of a few reasonable approaches to making code portable across Java and JS. For example, Kotlin has its own concept of an array which happens be backed by an ArrayList in Java land. Or, classes like ArrayList are emulated in JS by a runtime library.
A DSL written in a dependently-typed language (such as Idris) would suffice for both the kind of safety and the level of expressivity I require. (Unfortunately, the various JS backends for Haskell, Idris, Agda, etc. are not usable for my purpose, since I need the output to be readable and debuggable).
Anything less than what I have proposed in the previous paragraph is pretty uninteresting to me. It's unfortunate that people are working so hard on Kotlin, when it cannot contribute anything new or interesting, by its very nature.
If you need a stronger type system, and you're already using TypeScript, take a look at FunScript (http://funscript.info/); it uses the meta-programming features of F# to do strongly-typed JS (and TypeScript) code generation and interop with existing code.
Maybe you can think outside of yourself for once and consider that your uses cases or personal preferences aren't what the Kotlin devs consider important.
A priori, it would be better if they conformed to my expectations; anything less than awareness and deference to the last 40 years in PL research is uninteresting and unhelpful.
A priori, it would be better if they conformed to my expectations; anything less than awareness and deference to the last 40 years in PL research is uninteresting and unhelpful.
Amazing. Are you a solipsist or just incapable of perceiving outside of your little bubble? Do you even understand what the Kotlin devs are trying to accomplish? Hint, they're not trying to develop the next dependent type theory implementation on the JVM. They're implementing a language so that Java developers can be a bit more productive than they are now.
In order to have a type system that is compatible with javascript , there are things you just cant do. I think Microsoft TS team did an acceptable compromise. TS is not perfect , but the fact that one can still use pure JS in typescript is a huge plus.
Can you explain this? Thanks!
1) compiles to jvm and javascript 2) handles null better than java/javascript 3) good tooling
I don't know of many other languages that hit this mark.
Targeting to JS allows for certain scenarios, such as those I recently wrote about: http://blog.jetbrains.com/kotlin/2013/10/writing-kotlin-in-t...
Actually, I view these higher-level languages as the program that ships with a Raspbery Pi (don't know what it's called, sorry), which uses a drag and drop interface to create loops and create a game. You'll learn the basics of programming, but having a company where everyone speaks their own higher-level language won't really work. You're especially fked if you've got a developer that has to read the generated code, in a lot of cases.
Please correct me if I'm wrong, I'm still genuinely interested in the purpose of such languages!
I'm saying that languages like these (if I understand correctly), when compiled, result in a program generated by said language, "written" in another language, like Javascript, Java, Python or something.
Personally, I see no value in doing so. It creates a bit of an "overhead" (you compile it twice), and you actually don't really see what happens in the layer below the layer you're working in: the JS/Java/Python layer.
Say you've been working in the language FooBar, which creates, say, Javascript. Now most examples of code generators I've seen don't really care about the readability of the code they output. They have a readable, human-created bootstrap.js loading the default handler, and a bunch of semi-obfuscated .js floating around.
Usually, this doesn't matter. However, I see a lot of these languages appear on HN lately. The problem I'm starting to see is that, when we've got 10,000 alternatives to FooBar, people all start using different FooBar-like languages, and it becomes a mess. If you, for example, like to write in BarFoo, then we have a problem. We both understand JS, but the generated code is a mess. What do?
Then again I could be wrong. :P
Now, from the JavaScript target, yes, it compiles down to JavaScript, but it does so in a way that it not only provides sourcemaps to be able to debug, but also be consumed from JavaScript via Common JS modules for instance, thus allowing you to interact from JavaScript with the code you've written in Kotlin. Think for instance replication of some business logic on both client and server which is quite common.
Finally, in regard to writing Kotlin versus JavaScript, well Kotlin has it's advantages if you prefer static typing and want some of the benefits that language provides. If you're comfortable with JavaScript, if you prefer dynamic languages, then there's little reason to use Kotlin to compile to JavaScript (except the previous scenario of sharing code).
[1] https://en.wikipedia.org/wiki/Scratch_%28programming_languag...
val arr: Array<Array<Tile>> = Array<Array<Tile>>(height, { x ->
Array<Tile>(width, { y -> Tile(x, y, Terrain.GRASS) })
})
val arr = Array(height) { x -> Array(width) { y -> Tile(x, y, Terrain.GRASS) } }- C++ level of const correctness or a simple way to make immutable data structure. Or immutable view of full data structure.
- Explicit symmetric coroutine with safe data sharing machinery. I mean something like Erlang process or Goroutine.
- Any meta-programming facility such as macro or template.