By now I have gone through a number of Elixir web frameworks, a web framework in Cocoa, and not really been able to release my homepage in a way that I liked. So what would be more natural than to drop the code and try something else, perhaps something that I’ve worked on before and found wanting? Hello Node.js (+Express & CoffeeScript).

One of the issues I’d had last time I worked with Node.js was that debugging was hard, or console.log based. This time I found that someone had made a Eclipse distribution with Node.js support. Turns out, syntax highlighting and debugging CoffeeScript is still flaky. But I can step through most of the dependencies I use, so that helps, and a lot more people are using this, thus searching the net for solutions is better. Stuff I’m really missing from the earlier approaches, though, are

• the actor model
• GCD or other nice threading
• a crash only being local to a piece of the code and being restorable

What was really nice, was that I got up to where I’d been in both Elixir and in Cocoa fairly quickly. Also, I have a feeling I will be able to complete it this time. ;-) So onwards we go, at least writing posts is quick and easy with the approach I’ve tried to enforce through these different implementations. And that, after all, is where I expect to have my “big win” when my page has finally been deployed.

In my last post, I was exploring new web frameworks to migrate to, while learning more Elixir. I attempted a few, but learning a framework can be uphill, especially when not being fluent in the language. The main frustrating point was not being able to understand the errors I was getting. They were usually in one, long, truncated line. So not only was it formatted poorly, it didn’t give me all the information that was intended for me. I didn’t really find a good way of getting better error information or analyzing the errors I was getting, so finally I gave up… for now.

So I went back to what I know, and I know Objective-C and Cocoa really, really well. And there are a few webservers for it. I grabbed OCFWeb, thinking perhaps I could add exploration of Objective-Cloud to the task. This way I knew I would be able to understand the error messages I was getting, I had a debugger I could set breakpoints with and step through, and I would be comfortable.

With the advice of Christian Kienle I switched my templating language to Mustache. I forked it to update Mustache to a newer version and still be able to use OCFWeb as a Pod. That worked fairly well, but of course it’s a new framework to learn, just like all the other web frameworks I’ve tried so far. It isn’t much used, which means searching the web didn’t give many results, and thus I had to dig through the source exploring how the pieces fit together when I didn’t understand how to do something or why it behaved another way than I expected. That, of course, was a good opportunity to contribute, but it also exposed a weakness with my Cocoa-approach: the recompile-restart-reload cycle of seeing the results of my changes was rather longer than what I wanted. Of course, the content could be modified by having it outside of my application, but the routes and logic could not. Or at least I didn’t think of a way where I could keep it outside the server app.

So for now, I won’t be deploying my website as a Cocoa app either. Coming up next, back to Node.js

My first “real” Elixir project was to build my own homepage with my blog and portfolio. I wrote it using Dynamo. Not the best of choices, since it now recommends I look other places. The options I’ve found so far are:

The four of them depend on Plug, and thus on Cowboy. When I started my work, 0.13 had just come out. A week ago, 0.14 was released, so it’s great Plug, Phoenix and Weber are all updated already. At least as long as all of your other dependencies are at least up to 0.13, anyway, if not they’ll probably be broken now.

So, since I’m getting Plug anyway, do I want it the Phoenix way or Weber way? By reading their README.md, I don’t really have a preference. They seem to be very similar. Both have one main maintainer, two “leutnants” and many with a commit or two. Both have one-digit open issues and 3-digit closed issues.

When it came down to “mix test”, Phoenix had significantly more tests, and they gave no warnings, where I had 25 warnings when running Webers tests. So with lots of probably insignificant data points, this was the one that tipped the scale to let me try out Phoenix first.

However, my run with Phoenix was short. I had expected to be able to reuse my .eex template files from my Dynamo project, but there was just no documentation or examples to support this. Not even an itty-bitty template file in the generated scaffold. I could see from the dependencies that there is support, but it looked like I would have to do quite a bit of work on that on my own.

So I tried out Weber. Generate the scaffold and launch. Fine, there’s HTML on launch and it seems to be taken from a view file. The HTML includes a link to the Weber site, which is 404. Now that is reassuring…

What really excites me the most about iOS 8 right now is Remote View Controllers, which I mentioned around iOS 6. Right now they are presented as something you use to implement services (extensions in iOS parlance), but combine them with auto-layout and adaptable view controllers, and you have a setup for presenting your app on an iWatch or an embedded display, for instance in a smart cover or an AppleTV widget. Embedding widgets accross iOS and mac devices is also an avenue I hope we developers soon get to explore. :-)

Dear John,

thanks for the great show (ATP), I look forward to every episode the three of you do. In the episode I listened to today (#53) you guys talked about ObjC moving forward, and you mentioned Erlang a few times.

Two small disclaimers first, (1) I’m very new in the world of Erlang, and (2) the company I work for has subsidiaries that only focus on Erlang, and shares in companies whose products are built on top of Erlang. I like to believe I’m not influenced by this, but I am influenced, amongst others, by my CTOs passion for the ecosystem.

Erlang is two things: a VM called BEAM, and a language. The language is not to my taste, but I really like the VM. Lucky for me, there is a new language called Elixir that runs on the Erlang VM as a first class citizen.

What I really like with writing for this ecosystem is that it launches a ton of green threads instead of GCD threads, and these processes do true (shared nothing) message sending between them. The actor model is back!

Elixir has other fun stuff too, such as piping function calls as if they were commands in the terminal. So far, I find myself writing a bunch of pattern matching for the work I want it to do, in a more terse yet easy-to-read way than I’m used to coming from ObjC and the usual suspects of languages before that.

I think you’d find it interesting diving into the Elixir and Erlang VM combination. The take-away I’ve got that I’d love to bring back to ObjC would to be (1) even tighter on making everything immutable, (2) introduce green threads where for instance singletons can live, and (3) make a objc_msgSend that sends messages between threads not containing pointers to data, but an actual message, and having the sending process being able to continue with its logic until it needs the answer back where it can block and wait if there is no reply yet.

This was a bit longer than a 140 character tweet, but there you go. Oh, and to tie this together with the news, I only noticed Whatsapp because they sponsor conferences and give talks on how they built their backend in Erlang.