This is the old debate whether applications should be tightly or loosely coupled. As the article concludes, there are tradeoffs to consider - the broker is a SPOF indeed, but on the other hand it'll take care of all the queueing logic (which is not that simple as it seems - acknowledgements, backpressure, redelivery, timeouts etc etc). It's also much easier to scale the system out if applications are loosely coupled.
Furthermore, a good broker supports some kind of failover. We run a RabbitMQ cluster behind a load balancer, and it works great - once e.g. we had a hardware failure, and the applications did not notice anything from it. Of course we also have to monitor the queues on the broker (one of the few ways to bring down Rabbit is to fill up its disk). But having a central broker for connecting apps also means you have a central point you can keep an eye on to check where your bottlenecks are (which queues build up).
Loosely coupled applications are also much more unix-like in the sense that you can make them do one thing instead of baking in your custom restart logic (over a network? please don't).
Integration is very easy (check out the examples in their git repo), but this is still alpha quality software - there are known limitations, e.g. the one I ran into is that a large JS expression involving function calls might make Duktape run out of bytecode registers.
After a quick glance it also seems that newer versions of SpiderMonkey only offer a C++ API, so you can't embed it anymore into C apps without some glue code. I checked out jsapi.h in SpiderMonkey24 - maybe some trick is needed to use SM from C?
The funny thing is that most people choose Elixir over Erlang because of the syntax - personally I can't stand Ruby but love the Erlang syntax. When I see Erlang code, everything just clicks - almost like I'm reading prose.
So, if you want to harvest the power of Erlang, I'd suggest you start with the real thing first. The only drawback is that once you get used to functional programming, guards, pattern matching, OTP, cheap processes, links and all the other goodness, there's no way back.
If you still feel Erlang is weird after spending a couple of days working with it, feel free to jump on the Elixir bandwagon. :)
If you're only looking into weight loss/gain, then yes. Both are terrible choices as a diet, though. The latter will provide more nutrients, so we can call it 'healthier', but you will lack important ones still, and significantly undereat if you are an adult male of average weight and height.
The whole "clean eating" thing is mostly a fad. Nobody has managed to define what food is "clean" and what is not (see e.g. what the typical bodybuilder thinks is clean, and what someone doing paleo, what the average dietitian recommends, etc). The only important things are 1) the number of calories you eat, and 2) what nutrients your diet provides.
When I'm cutting, I don't make a fuss about "junk food", as long as I'm below my calorie intake limit and I'm not missing any important nutrient. Usually hovering around 20% junk food.
Interesting to see how mainstream intermittent fasting has become. It's worth noting where it started.
A few years ago a few hardcore fitness fanatics started playing with the idea of using controlled fasting for weight loss and/or body recomposition. Two people that should be mentioned are Lyle McDonald[1] and Martin Berkhan[2]. Martin especially made IF popular via his blog, laying out the principles he used as a fitness consultant with his clients.
Most research (and especially the commercial IF knockoffs) only take some part of these principles, but the "diet" part is only part of the picture when it comes to body recomposition. It's almost worthless without the rest (high intensity, low volume weight training, basic compound movements, progressive overload, no focus on cardio).
Quite a few people/company are trying to rip off customers via their IF programs knockoffs and supplements. If you want give IF a shot, read through Martin's blog, and try the original Leangains protocol.
The really nice thing about this is that the dispatching to the optimized version is done at runtime, via GCC adding the necessary stubs at compile time. No extra dispatching/CPU detection logic in the application is needed to take advantage of advanced CPU features. Very cool.
I have no experience with Akka, but what you write makes sense. Even Clojure concurrency primitives feel weird sometimes when one wants to mix them with low-level Java libraries.
Another option is to do it at the language level - see my comment on Erlang.
Interesting analogy: Erlang implements an M:N scheduling model, where it starts an OS thread for each CPU core (by default), and (preemptively) schedules its own lightweight processes on top of these threads. However, unlike OS threads, these are very lightweight: when they are created, they only need a few hundred bytes. Erlangers have been using the one process per request model for a very long time, and Erlang applications achieve massive concurrency via this.
To me it seems it is possible to do M:N right, but you need more abstraction and a different design. M:N seems to work well in Erlang-like cases (very lightweight processes on top of a kernel threads).
There are lots of startups in Berlin, and the tech scene is flourishing. However, I always feel that companies here are behind the state of the art. There might be exceptions, this is just my impression when I go to meetups, presentations, or talk to colleagues (they have worked for quite a few different companies here in Berlin).
That being said, there are quite a few companies that are into the big data business. Having a PhD will certainly make it very easy for you to get a good job here.
"Recognize that BMW/Daimler/et al really don't want true self driving cars. It's not really in their interest, because it would radically reduce the need for car ownership and would open up a new world of on-the-fly car rental."
This is exactly what is happening, without self-driving cars. E.g. Drive Now is a very popular service in several german cities, and one of the reasons why I don't feel the need to own a car while living in Berlin. I can just hop in a car any time I like, drive around, and then park it anywhere in the city.