Also, +1 for building the application in Erlang on top of Cowboy (which Chicago Boss uses under the hood). You'll learn a lot, especially about the entire HTTP/Websocket protocol. Be prepared, however, to never want to develop a web application in another language again once you understand Erlang idioms and why they are superior to Go, Scala, Clojure, C++, etc. It is said, after all, that Erlang isn't a programming language but a DSL for distributed systems (this is, in fact, why it was built by Ericsson).
As someone who just scrapped a lot of Erlang code running Cowboy for a Haskell codebase, I'm not completely convinced. There are lots of runtime features I miss, but it's significantly harder to manage non-distributed code in Erlang as I experienced it.
This is how I do it: Erlang manages the distributed portions of my application but a throughput oriented language (such as Haskell) handles the non-distributed portions. A la using the right tool for the job. Cloud Haskell has come a long way but it is still missing Erlang's per-process heaps and scheduler behavior.
I think the real magic of Erlang is probably OTP. Over time, I can see Riak Core also being a fantastic tool for bootstrapping high-availability services.
Mmm, erlang is a nice language and cowboy, too (Misultin, if that's what it was called, was fun to play with too) But all the things that erlang promotes, instantly spinning up millions of processes on 1 server with overhead /process of a few hundred bytes, the gen_*'s, profiling/logging, I have to say akka (the actors/futures modules that's now a full fledged member of the scala distribution), it has all those. Akka can hot swap actors but not chunks of the entire runtime AFAIK. Akka doesn't have as many large apps in production but getting there. Akka does't have the glass ceiling, where sooner or later you know you're going to have to write C nodes/BIF's/NIF's or whatever they've come up with, to speed up an erlang app doing, say, lots of floating point math.
Chicago Boss is a heavy framework, so don't hesitate to start with Cowboy and add the remaining pieces as you need them. It goes without saying that something like CB is complex and that it can make simple tasks like building an OTP release more challenging. See for instance that `init.sh' uses Rebar[1] internally rather than a standard `erl -s MOD FUN ...` invocation. In general the philosophy seems to be to hide many OTP things from the end-user, for better or worse (given how powerful OTP is, I would say this is worse for the individual versed in OTP but better for the one coming from Rails or something like that, who doesn't want to have to scale the steep learning curve. That developer is Chicago Boss' target audience[2]). It is very much a monolithic distribution akin to Django.
I've been meaning to learn more about Erlang. For the Erlang experts who are willing to enlighten me:
1) I recall reading that string in Erlang is implemented as linked list and is slow. How does that affect web development which usually involves a lot of string processing?
2) Does Chicago Boss come with non-blocking database clients? If one of those millions of userland processes makes a query to MySQL would it block the entire Erlang scheduler?
3) Does Chicago Boss support multibyte languages like Chinese and Japanese? Last time I looked unicode support of Erlang seemed to be shaky.
1) Binaries are usually used when space is important (like when developing web applications). They use considerably less memory than lists. Processing binaries or list strings is slow compared to other languages where this is a focus. Erlang is not a strong string-processing language if you care about performance.
2) Mnesia? Riak too. And no, the Erlang scheduler won't get blocked. Why would waiting for something unpredictable like an open MySQL connection block a central coordinating component of the VM? Study how the Erlang VM[1] works more and you will see why Erlang/OTP is so resilient. The `epgsql' and `Emysql' libraries are heavily used by Erlang developers to work with PostgreSQL and MySQL, respectively.
Others, who are more proficient in the language (I have a heavy Python background), can supplement or correct these answers.
Here is a start though:
1) For web development, Erlang uses a data type called an iolist. This can be a (potentially nested) mashup up binary, character and byte sequences. It is extremely memory efficient and is a pleasure to work with.
2) Chicago Boss database drivers use client libraries from the Erlang community. Erlang programmers
3) Yes. I believe Chicago Boss supported Unicode/UTF-8 before the rest of Erlang did.
4) I guess the biggest difference is that Chicago Boss uses Rails conventions, whereas other Erlang web frameworks create their own. For example, CB is the (only?) Erlang web framework to use a database abstraction layer built from models written in an easy-to-read DSL.
