Wasabi – A Sinatra-inspired web framework for Kotlin(blogs.lessthandot.com)
blogs.lessthandot.com
Wasabi – A Sinatra-inspired web framework for Kotlin
http://blogs.lessthandot.com/index.php/WebDev/ServerProgramming/wasabi-a-sinatra-nancyfx-inspired
4 comments
I see that you're using straight-up Netty as the http server. Why did you choose to take this path rather than use a servlet container (Jetty, Tomcat)? Are there performance advantages?
To what the author has said, I will add that in terms of performance, Netty is currently faster than the fastest production Servlet containers [1]. Presently, Undertow (the web server for the upcoming WildFly application server, which will have a Servlet container) is the only platform providing slightly faster request-processing performance. Until WildFly is production-ready, Resin is the highest-performance Servlet container I am aware of.
[1] http://www.techempower.com/benchmarks/#section=data-r6&hw=i7...
[1] http://www.techempower.com/benchmarks/#section=data-r6&hw=i7...
I wanted the minimal viable that worked and proved concept and direction of API and then build on it. And while Netty seems to be seriously good performance wise , I will most likely add a layer to allow use of any servlet container. The dependency on Netty is minimal. Basically only one file with is the Request handler.
I wrote some toy programs in Kotlin, can anyone who used it for serious projects weigh in on how it compares to e.g. Java 8?
I wrote about 10kloc in Kotlin for internal testing framework. It is heavily multi-threaded and Kotlin aced here (compared to Scala).
Java8 brings lot of legacy stuff. It feels like authors just wanted to add 'functional' on feature list. No type inference or named arguments.
I think it is better to compare Kotlin to Groovy or Scala. In both cases it is simpler and more elegant language.
I found two problems with Kotlin:
Not mature yet. It is surprisingly stable and bug free (compared to Scala just 4 years ago). But some features are not designed yet and are missing (for example getters handling). Those will be added in some future milestones. Also I had to write some boiler plate code which should be in standard library.
Nullability handling is strictly required. Most of classpath API is already annotated, but I had to annotate external libraries I am using.
Java8 brings lot of legacy stuff. It feels like authors just wanted to add 'functional' on feature list. No type inference or named arguments.
I think it is better to compare Kotlin to Groovy or Scala. In both cases it is simpler and more elegant language.
I found two problems with Kotlin:
Not mature yet. It is surprisingly stable and bug free (compared to Scala just 4 years ago). But some features are not designed yet and are missing (for example getters handling). Those will be added in some future milestones. Also I had to write some boiler plate code which should be in standard library.
Nullability handling is strictly required. Most of classpath API is already annotated, but I had to annotate external libraries I am using.
I, too, have high hopes for Kotlin. It seems to achieve what I'd hoped Scala would but ended up failing miserably.
There's a lot of merit to the "Java philosophy": a gradual progression of what most programmers expect in a language. Google, for one, seems to have adopted the Java philosophy wholeheartedly in its new languages Go and Dart.
Kotlin is certainly in that camp: a gradual progression that will make programmers happier yet won't turn their world upside down. It's simply a better Java. So while Scala unfortunately evolved from being a better Java into the mother of all kitchen sink languages (assuming, of course, that your kitchen feeds a whole military base and has sinks the size of hot tubs), trying to cram Java, Haskell, Lisp and Javascript into a single compiler (I find it hard calling Scala "a language"; it's more like a compiler that compiles code written in any of several languages), Kotlin takes a few steps back and comes up with a coherent philosophy.
I think 99% of Scala users will find Kotlin to provide 100% of their requirements, and at a much reduced complexity and mental load. So Kotlin, I think, is not only a better Java, but a better Scala.
Yet, I think Java 8 will be the game to beat, for Kotlin as well as Scala. Java is hugely popular, and those that haven't migrated to other JVM languages so far, might be less likely to do so when Java 8 comes out. With lambda expressions and traits – the two killer features that attract many to Scala when it first came out – it gives Java a nice boost. Sure, Kotlin feels more like a fresh start, and has some other necessary features (properties), but will those be enough to switch people away from Java?
I think that one of the great achievements of Kotlin's design, though, is that the transition could be very gradual. Kotlin places a very strong emphasis on Java interoperability (leaps and bounds better than Scala's) and unlike Scala, Kotlin code is easily read by Java programmers. So teams would be able to easily replace individual Java classes with Kotlin code.
There's a lot of merit to the "Java philosophy": a gradual progression of what most programmers expect in a language. Google, for one, seems to have adopted the Java philosophy wholeheartedly in its new languages Go and Dart.
Kotlin is certainly in that camp: a gradual progression that will make programmers happier yet won't turn their world upside down. It's simply a better Java. So while Scala unfortunately evolved from being a better Java into the mother of all kitchen sink languages (assuming, of course, that your kitchen feeds a whole military base and has sinks the size of hot tubs), trying to cram Java, Haskell, Lisp and Javascript into a single compiler (I find it hard calling Scala "a language"; it's more like a compiler that compiles code written in any of several languages), Kotlin takes a few steps back and comes up with a coherent philosophy.
I think 99% of Scala users will find Kotlin to provide 100% of their requirements, and at a much reduced complexity and mental load. So Kotlin, I think, is not only a better Java, but a better Scala.
Yet, I think Java 8 will be the game to beat, for Kotlin as well as Scala. Java is hugely popular, and those that haven't migrated to other JVM languages so far, might be less likely to do so when Java 8 comes out. With lambda expressions and traits – the two killer features that attract many to Scala when it first came out – it gives Java a nice boost. Sure, Kotlin feels more like a fresh start, and has some other necessary features (properties), but will those be enough to switch people away from Java?
I think that one of the great achievements of Kotlin's design, though, is that the transition could be very gradual. Kotlin places a very strong emphasis on Java interoperability (leaps and bounds better than Scala's) and unlike Scala, Kotlin code is easily read by Java programmers. So teams would be able to easily replace individual Java classes with Kotlin code.
I think Kotlin and Java8 are in different category. For example Kotlin also compiles to JS and it has reasonable chance to become killer web language.
You know what language I wish could compile to Javascript? Visage (https://code.google.com/p/visage/), AKA JavaFX Script, AKA F3. Now that would be a killer client-side web language.
I'd never heard of Visage. Seems it's a declarative UI language. That raises two questions: what UIs have been built with it, and how does it accommodate the arbitrary code (i.e. imperative rather than declarative) that one inevitably needs as applications become complex?
Ok, three questions: why do you say it would be a killer client-side web language?
Ok, three questions: why do you say it would be a killer client-side web language?
The declarative part of Visage/JavaFX Script is simply a clever object instantiation syntax, with its killer feature being the "bind" form. Other than that, Visage is basically statically-typed typed javascript.
It would be great because it's:
1) Looks very familiar to javascript developers
2) Accommodates both the declarative (HTML) and imperative (js) parts of the applications consistently, beautifully and in one place, and ties them together very naturally.
3) Incorporates CSS
There was copious amounts of docs and examples online, but unfortunately they all seem to have been taken down. I found one example, though: http://langexplr.blogspot.co.il/2008/07/javafx-script-overvi...
It would be great because it's:
1) Looks very familiar to javascript developers
2) Accommodates both the declarative (HTML) and imperative (js) parts of the applications consistently, beautifully and in one place, and ties them together very naturally.
3) Incorporates CSS
There was copious amounts of docs and examples online, but unfortunately they all seem to have been taken down. I found one example, though: http://langexplr.blogspot.co.il/2008/07/javafx-script-overvi...
Interesting, in what ways is Kotlin more elegant that Scala?
I wouldn't say it's more elegant than Scala, because, unlike, say, Clojure or Haskell, elegance doesn't seem to be a central design requirement of Kotlin's, but it is far easier to understand, learn and master. I think Scala pays a tremendous cost in complexity for its features. Kotlin gives you all of those features that would interest all but avid Haskellers (and those would be better off with Haskell than with Scala) for a tiny fraction of the cost.
Agreed, there's a price to pay for Scala's elegance (long compile times).
If Kotlin can deliver on the promise to compile _at least as fast_ as Java, it will find Java converts for sure.
> Kotlin gives you all of those features that would interest all but avid Haskellers.
Not so sure about that, Scala runs on the JVM, which is one of the reasons Twitter, LinkedIn, etc. Big Companies have adopted the former and not the latter.
Will be interesting to see how things play out. For example, what will Kotlin provide in the way of a concurrency library like Scala's Akka? Are LINQ and F# style Type Providers possible in Kotlin given it's mandate for simplicity and compiler performance?
I suspect Java8 is going to be a thorn in Kotlin's side given that Java8 will likely already have been given a look at by Java world before Kotlin 1.0 comes on the scene.
If Kotlin can deliver on the promise to compile _at least as fast_ as Java, it will find Java converts for sure.
> Kotlin gives you all of those features that would interest all but avid Haskellers.
Not so sure about that, Scala runs on the JVM, which is one of the reasons Twitter, LinkedIn, etc. Big Companies have adopted the former and not the latter.
Will be interesting to see how things play out. For example, what will Kotlin provide in the way of a concurrency library like Scala's Akka? Are LINQ and F# style Type Providers possible in Kotlin given it's mandate for simplicity and compiler performance?
I suspect Java8 is going to be a thorn in Kotlin's side given that Java8 will likely already have been given a look at by Java world before Kotlin 1.0 comes on the scene.
> Not so sure about that, Scala runs on the JVM, which is one of the reasons Twitter, LinkedIn, etc. Big Companies have adopted the former and not the latter.
If you look at their code, they, like most Scala developers, hardly ever use features not found in Kotlin. None of them use the language for its Haskellesque powers.
> Agreed, there's a price to pay for Scala's elegance (long compile times).
I was referring to mental load and indescribable complexity that makes Haskell look like child play in comparison - not compilation time. This is the price Scala pays for power; I wouldn't in a million years call it elegant, but some people think it is.
If you look at their code, they, like most Scala developers, hardly ever use features not found in Kotlin. None of them use the language for its Haskellesque powers.
> Agreed, there's a price to pay for Scala's elegance (long compile times).
I was referring to mental load and indescribable complexity that makes Haskell look like child play in comparison - not compilation time. This is the price Scala pays for power; I wouldn't in a million years call it elegant, but some people think it is.
The designer of Kostlin answers this here: http://www.oracle.com/technetwork/articles/java/breslav-1932...
Just check scalac source code. Also Scala losses a lot when mixed with Java legacy code (collection casting etc..)
For me the ultimate elegant stunt is how Kotlin introduced immutable collections into Java Collections Framework.
For me the ultimate elegant stunt is how Kotlin introduced immutable collections into Java Collections Framework.
With the disclaimer out the way that I work for JetBrains, we are using it internally for several projects and some parts of our tools, including for instance the LiveEdit functionality in WebStorm is written in Kotlin.
In terms of comparing to Java, yes Java 8 adds lambdas but Kotlin drastically reduces the amount of code required and adds several other features that are not in 8.
I certainly think there is a place for a language that does not have the complexity of Scala, but reduces the boilerplate of Java. I also liked the support of non-null types in Kotlin.
I was wondering what niche this filled and now that you say it, yes, this does seem like a nice compromise between Java and Scala (The F# of the JVM?)
In general, these "traditional OOP with functional flare" languages are a very positive trend with functional idioms becoming much more mainstream.
"FP for the masses" is certainly going places.
In general, these "traditional OOP with functional flare" languages are a very positive trend with functional idioms becoming much more mainstream.
"FP for the masses" is certainly going places.
And also has extension methods and lambda extensions which AFAIK are unique to Kotlin (the latter), which makes some of the stuff I do with Wasabi possible.
[deleted]
Why was the Issues tab removed? http://i.imgur.com/9jCrGY8.png
We don't use GitHub issue tracker. Issues are tracked with YouTrack here:
http://hhariri.cloudapp.net:8080/issues/WA
Support is on Google Groups:
groups.google.com/forum/#!forum/wasabifx
http://hhariri.cloudapp.net:8080/issues/WA
Support is on Google Groups:
groups.google.com/forum/#!forum/wasabifx
Ah, I missed that in the description, thanks for reply.