Rough, but worth it.

The last month has been rough.  Scala drives me to either completely love it, or it makes me want to bathe in the blood of its creator’s children.  This month has been full off bloodlust.  I love to bitch about Scala, Typesafe, and the poor decisions that have been made regarding the language and its popular libraries; however, once things are working, they work well, and they work fast as hell.

If you’re working with people that try to make Scala look like Haskell, it’s a nightmare.  That is a lot of the problem.  It isn’t haskell.  I don’t want to grow a neckbeard and try to understand punctuation as code.  If you write code like that, and I have to work on it, I will want to pour hot coffee on your babies.  I’ll be thinking it every time that I talk to you.  Readability trumps writability EVERY SINGLE TIME. I’m not the only one who feels this way. If you work with people that care more about readability than writability, and you don’t mind reading about what the underlying JVM is doing with your code, Scala is a delightful language to work in. Someone needs to write a Scala (the good parts) book though; and someone also needs to write a guide that works like the Elixir guide. Show people how to build a server with akka and Scalatra instead of showing way-too-clever ways to calculate/memoize Fabonicci and we’d be on to something.

I spent the last month battling issues that I assumed were caused by the PlayWS standalone http client library using a single thread per connection. Then I read some whitepapers on how Java nio works (it’s really badass), realized that WS uses Java nio and that the library couldn’t be the cause of my problems, fired up a yourkit profiler demo, and discovered that my problem was actually that I was using Scalatra routing in such a way as to block an entire thread waiting for the Future returned by WS to complete. No, I didn’t call Await.* or anything on it. I just returned the future to the route. Scalatra doesn’t like that though, as then the call to your route doesn’t free up the thread until the Future completes. All you have to do to prevent the issue that I encountered, and make your calls actually asynchronous, is to have your external call return a promise or use the AsyncResult object correctly. Basically, just follow the instructions for Scalatra. Scalatra is awesome. I wish every library in Scala was so straightforward. Those guys totally get it. I can’t say enough good things about them.

Anyway, I went from struggling to handle 2000 simultaneous external calls and crashing due to memory exhaustion to easily handling 300000 simultaneous external calls on less than 1GB of memory (I did have to increase my ulimit file count on the OS to keep from running out of files). I will likely be able to tune that up even more. I wouldn’t have guessed where the problems were without the profiler. The yourkit profiler is worth every penny that they charge for it. I bought it the second I fixed my problem. I think everyone should support them as well. They’re doing great work.

Anyway, I guess the gist of this is that Scala is an amazing language when you use it on the regular; but, someone not associated with Typesafe needs to write a “good parts” book and associated style guide. It really could be a very popular language if someone would wrestle it away from the academics and neck-beards. Maybe I’ll do it some day when I have a little more time.

Linode

Linode moved to SSDs and adjusted their prices to be the same as Digital Ocean’s, but with more features (load balancers being the main one).  I’m not going to lie, I missed their toolset.  Linode’s DNS setup beats the bag out Digital Ocean’s.  It took me a few minutes to set up all of my DNS settings for about 11 sites manually.   It took me about 30 minutes to build the new VM and move everything.  Imagine if you had it scripted.  Digital Ocean was nice, but Linode feels like home.

So Does ReactiveMongo

Since I am handing out endorsements this week, I figured I’d throw one more onto the pile.  ReactiveMongo is an asynchronous MongoDb driver for the JVM.  It’s the only non-blocking MongoDB driver there is for the JVM I believe.  It’s such a good driver that it actually makes a stronger case for using Mongo than Mongo itself does.  If this driver existed for Postgresql instead of Mongo, I’d use Postgresql.  That’s how good this driver is.  I hardly care about the underlying db because the driver is so good.  It is the best driver for any db I have ever used on any platform.  Mongo basically uses json to interact with it.  That is about as simple as it gets.  As simple as that is though, the ReactiveMongo driver is actually easier.  I wasn’t totally sold on Mongo a few months ago.  I feel like Postgres is actually a really solid platform, and with its ability to handle json, it’s arguably better than Mongo, even as a document store.  ReactiveMongo is a game changer for me though.  I’m using Mongo on new projects just because the ReactiveMongo driver is so good.  That’s saying something.  Good work guys.

Scalatra Rules

If you’re doing Scala development and want to save yourself a ton of time and headache, seriously check out Scalatra. I’ve worked quite a bit with the Play framework and worked against Spray, and I have to say that Scalatra is just a joy to use. I might name my kid Scalatra. Scalatra Legler. It rolls right off the tongue. That’s how impressed with it I am.

I’m not going to knock Play too much because it is a great piece of software. It’s just really heavy if all you need is web services though, and I’m not crazy about the functional testing framework (I’m looking at you FakeApplication, you crashy bastard). That’s beside the point though. I’m building an app that makes heavy use of web services and websockets, but the entire front end is javascript. I don’t need Play’s templating etc, so it’s just overkill. I researched micro frameworks and out of several, I decided to play around with Spray and Scalatra. Actually, I shouldn’t say that. I decided on Spray because it is so tightly integrated with Akka, which I use extensively, and so began the trouble.

The Spray toolkit is nicely decoupled, so you can use just the part you need, which I like. I love their caching module, in fact, I use it with Scalatra. I found their routing really cumbersome though, and I hate how implicit everything is. There is a lot of magic going on, which I don’t like. I’m building a REST service. If I want to send a response code with a json payload, that should be trivial. I shouldn’t have to look that up. I certainly should have to spend hours looking it up and learn an entire new vernacular of Spray idiomatic concepts to express what I am trying to do. Yet hours into messing with it, I found myself in the bowels of various google groups finding out that I have to write customer marshalers to do it? (again, we can’t agree to call them serializers? We have to come up with different terms?) Fucking annoying. The problem that put me over the edge was trying to return a 204 Status message if there were not results to display. This is a really really really common thing to do, and for the life of me, I could not get Spray to do it. This should be a one liner. I also wanted to throw 400 status codes when url parameters were missing with details as to what was missing in Json. Again, totally normal, should be a one liner, and a total fucking nightmare in Spray. I am sure that once you learn the idiosyncrasies of Spray, it’s a delight to use; however, I have shit to do and it was driving me crazy. Enter Scalatra.

At the point I went to Scalatra, I was completely disgusted with the Scala community’s acceptance of stupid complexity. This happens regularly for me. The people are great, but the idea that this complexity is acceptable is irritating. The Scala community at large needs to step back and start thinking of best practices for the language. It seems like the people with the loudest voices in the community have raging boners for the most complex abstract mathy ways to do everything. It’s exhausting. The thing about Scala is though, that if you ignore those people, the language is awesome. You don’t have to go down the pure functional hole to get performance out of it. I write Scala using the Zen of Python as my guide. It works great, and it makes me not feel guilty about ignoring the people running things. In any case, Scalatra is sweet relief from the abstract implicit horseshit going on in the Scala community. They’re my kind of people.

Let’s get back on task here and use an example to do it! For example, let’s say you have a parameter called name in your url, from which you’d like to get a value, probably a name if you’re into obviousness the way I am. Let’s say you want to throw a 400 code if it is missing and a json response explaining what happend. There are lots of ways to do this, but an easy one for me was something like this: Create a case class called HaltReason that contains a string called error. You’ll use this to deliver the message to your users of what the problem is. In your Servlet, extend ScalatraServlet with NativeJsonSupport. You do this to convert your HaltReason object into json. Then get your value with this line of code:

val name = params.getOrElse("name", halt(400, HaltReason("missing name parameter")))

Boom, that’s it. It either gets it, or it throws a useful explicitly defined error with an explicitly defined message to your user. Did I just blow your mind? If I hadn’t written that example and explanation, I’ll bet it would have pissed me off. I need examples man. I can’t conceptualize things like that. To remedy that, here is an example of the code in context.

Note: I didn’t compile this, so there may be syntax problems, but you get the gist. I also added a method that will always return a 204 response, just for awesomeness’ sake. You can imagine writing some code that results in no result, and then you can probably imagine explicity returning a response that says so. Imagining is fun.

import org.json4s.{ DefaultFormats, Formats }
import org.scalatra._
import org.scalatra.json._
 
case class HaltReason(error: String)
case class MyDumbResponse(name: String)
 
class ApiStoreServlet extends ScalatraServlet with NativeJsonSupport {
 implicit val jsonFormats: Formats = DefaultFormats
 
 // I put all of my routes here, this may not be totally normal. Check out the Scalatra website for real examples.
 before() { contentType = formats("json") }
 get("/getName") { doSomething(params) }
 get("/throw204") { doSomethingElse(params) }
 
 def doSomething(params: Params): MyDumbResponse = {
  val name = params.getOrElse("name", halt(400, HaltReason("missing name parameter")))
  MyDumbResponse(name)
 }
 
 def doSomethingElse(params: Params): MyDumbResponse = {
  halt(204) // This is just an example. I didn't even make it try to do something other than throw a 204 response.
 }
}

Better? If not, check out scalatra.org and build an example project and try it out. Try to do the same thing in Spray. Actually, if you do it in Spray and get it working, send me the code. I gave up on it and I’d love to see it. My point is this: Scalatra makes it easy to do exactly what I wanted, and that is my favorite thing when it comes to software.

So what about Akka integration and all of that? What about the fact that it runs on old and busted Servlets. Don’t worry about it. The akka integration is perfect. You spin up an Actor system behind Scalatra, extend your Servlet with Future Support, and you can distribute and cluster until your heart is content. Worried about thread exhaustion because of the Servlets? Don’t worry, Scalatra works with Servlet 3.0+ containers, making that not a problem. It’s already integrated with Atmosphere, build some asychronous beast and make a billion dollars. Scalatra makes this stuff fun. I’m sure Spray is awesome too, but I just got frustrated with the complexity of it. I want my framework out of my way so I can do the things I want to do, and Spray just wanted my attention constantly. Play is great, but it’s heavy. Both Play and Scalatra are well documented and straighforward. Scalatra is just lighter, which I wanted and I like. There are others out there that I didn’t try as well, and I have no idea how well they work. Try them all if you like. I just really liked what I found with Scalatra. If your time means anything to you, I imagine you’ll find Scalatra to be a pretty valuable piece of software to use.

I should be using twitter…

Because my posts are really short.  I’ll just say this.  I’m using spray.io for the second time in my career, and it is exactly as fucking annoying as it was the first time.  What an abstracted implicit mess.  Seriously, does explicit behavior cause physical pain?  Why does all of this shit have to be so magical?!?  Ugh.