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.

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.

Crisis of Choice (software, not an actual crisis)

I’ve been writing Scala code for about 9 months now daily.  I just recently completed (as much as one can complete software) a small project at work that took much longer than expected due to things that didn’t seem like they should take very long taking an eternity to figure out (Marshaling and UnMarshaling data is a huge pain in the ass using spray-json.  I highly recommend fasterxml if you don’t want to waste shitloads of time battling the library itself.  It works like the Play libraries, which is nice.)

Once I get things working, they work reasonably well, although I feel like what I have built is fragile.    Things that should be easy are a huge pain in the ass.  It’s been running for 30 days with no problems, which is nice, but that’s mostly because Akka is solid.  I just don’t feel like I have my head around this language.  I was a dumbass and decided that using a web framework for what I was doing was overkill, so I tried to build it with Akka, Spray, and Slick.  It was a waste of time, other than for learning Akka/Spray/Slick.  I should have stuck with Play and used traits to make testing my code easier.   The previously mentioned huge pain in the ass (which I never did get working) would have never occurred, it just works in Play.  My primary complaint about Play was it was hard to test, but that was actually my problem not really understanding how useful traits are when it comes to testing.  Anyway, you live and learn.

It’s an interesting place to be.  Nine months seems like it should be enough time to grok a language; however, I still feel like I’m scratching the surface.  I’m not expecting to be an epic badass at it, but it’s harder than it should be.  I have the same feeling with Scala that I have with C++.  If I can’t get the bulk of the language into my head, I have much less confidence in what I am writing.  I think that makes me a weaker developer in some ways, but at the same time, the point of abstraction is to not have to worry as much about what’s going on within the abstraction.  Scala is so complex with its generics implementation and type system and every other thing it tries to throw in, that it just gets out of hand in a hurry.  It is an amazingly powerful language, and overwhelming because of it.  It feels like it has created a whole new set of very complicated problems for me to solve to do what should be less complicated.

Scala offers all kinds of badass ways to get concurrency and parallelism and a neat type system, but at the cost of being a really really complex language with a seemingly insurmountable amount of concepts and associated buzzwords.  I blame the JVM and the JVM community at large.  They love abstractions of abstractions with abstractions in them, wrapped in Lists of Generics, which are type erased so you can’t tell what is inside of them at runtime without writing a bunch Manifest or TypeTag bullshit, each with a different name depending on the order that the abstraction occurs.  It’s maddening.  The JVM is amazing, and also drives me nuts.  I’m starting to feel like the “solution” causes more problems than it solves.   I think I’ll always be a JVM outsider.  It just always feels a little wrong to me, even when it’s working (and gobbling up memory).

To put it in perspective, I rewrote my Scala app in Python in about 4 days using Falcon.  My Python version handles the load it needs to and actually uses less memory.  It won’t scale at even a fraction of the scale of the Scala version in its current version, but it doesn’t need to.  If that became a requirement, I’ll bet I could write it to scale in less time than it took me to write it in Scala.  Admittedly, I have been writing Python code for much longer, and since I already had the design worked out, reimplementing it is always easier than the original implementation.  I also used a framework, so it’s not as fair of a comparison as if I had used Play.  It isn’t 86 days easier though.  I’ve been looking at Go and it tries to solve the concurrency/speed/memory/complexity problems in a kind-of backwards way that is interesting to me.  It doesn’t have classes or generics, and I kind of love that idea.  They tried to intentionally keep it simple, which is the philosophical opposite of Scala.  It’s a get-shit-done language instead of an academic language.  I’ll give it a try at some point.

I’m not giving up on Scala.  The challenge is fun; however, I don’t think it will ever be a dominant language.  I don’t think it will every be possible to scale a Scala development team in most cities.  There just won’t be enough people that are actually good at it that don’t cost a fortune.  What do I know though?  I could be wrong, but it just doesn’t feel right to me.  Maybe it’s better if you love the JVM, I really don’t know.  It’s a very complex language though, and I’m not settling on it as the best way to tackle concurrency/parallelism problems.

Formatting

I’m a sucker for formatting.  I follow the python PEP-8 religiously when I write python.  The Scala style guide isn’t as dogmatic though, which isn’t good for someone like me.  I like having some rules.  Anyway, I’ve been writing decent Scala code; however, I’ve not been confident in my formatting choices.  I’ve been getting more confidence through a Scala Coursera class I’ve been taking, but even with that, I just wasn’t positive I’ve been doing it correctly.  That has now changed.

I was just recently turned onto scalariform by a coworker.  It basically checks/fixes your formatting on compile.  It’s completely configurable, but so far I’ve just left it alone.  I set it up to check any code I compile with sbt.  Between sbt, scaliform, and intellij, I’m feeling a lot better about how my codes looks.