

Recreating a distributed web with Chicago Boss - timClicks
http://timmcnamara.co.nz/post/54720434939/

======
banachtarski
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).

~~~
tel
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.

~~~
banachtarski
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.

------
oinksoft
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.

[1]
[https://github.com/evanmiller/ChicagoBoss/blob/master/skel/i...](https://github.com/evanmiller/ChicagoBoss/blob/master/skel/init.sh)

[2] [https://github.com/evanmiller/ChicagoBoss#philosophy-and-
fea...](https://github.com/evanmiller/ChicagoBoss#philosophy-and-features)

------
continuations
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.

4) Difference between Chicago Boss & Nitrogen?

~~~
oinksoft
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.

3) Yes.
[http://www.erlang.org/doc/apps/stdlib/unicode_usage.html](http://www.erlang.org/doc/apps/stdlib/unicode_usage.html)

4) No clue, I use neither.

[1] [http://jlouisramblings.blogspot.com/2013/01/how-erlang-
does-...](http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-
scheduling.html)

------
kylequest
I didn't know that Vagrant is an awesome tool for caching :-)

~~~
timClicks
Oops. Will change to Varnish :)

