cnnrjcbsn

Let's skip over "low-latency", because virtually all programming languages and VMs are "low-latency". I believe the latency claims here are about running programs with multiple threads of execution. The Erlang VM (which Elixir runs on) uses preemptive scheduling and (I'm forgetting the exact number atm) each process (which is a userspace process) gets to run for a set period of time (I'm simplifying here) before the VM preempts it and lets another process run. If you have a rogue thread in something like Node, that thread can eat up all your CPU time. In Elixir/Erlang, it can't.

I'm not sure what "distributed" means here? Any app in most languages can be coded to be "distributed" both on the scale of within a single machine and at the scale of deploying multiple small instances of it. (eg Kubernetes, running it on multiple EC2s etc etc) The BEAM has a bunch of the "distributed" bits baked in that you then (mostly) don't have to think about when writing your program. If you have two machines, A and B, your program can run on those machines as if it was conceptually a single machine. This is somewhat different from most "distributed" applications.

In general, I find a lot of the patterns around fault tolerance and concurrency to be conceptually easier to work with than languages like Java, C++, etc.

For instance, in Elixir, you might structure a connection to your database as a supervisor and a pool of 10 connections. If something happens to corrupt one of those connections, the process will simply die, the supervisor will see that the process died and spin up a new one to replace it and then re-run any pending queries the dead process was in charge of. You can still handle known exceptions in the process, etc, but the idea is to quickly get back to a good state. The runtime was originally built for managing phone connections so this design choice makes sense.

In terms of concurrency, I find the actor model (which other languages use too!) simpler to reason about vs a process forking model like in Ruby. Essentially, similar to Go, you get parallelism by composing concurrent functions. Unlike Go, however, the composition is at a module level rather than within individual functions. So each function in Elixir/Erlang runs in series, but you can compose modules together to run concurrently and pass messages back and forth.

In general, I would think about Elixir as a Ruby/Node/Python competitor rather than a Java/Rust/C++ competitor. You can very quickly build scalable web applications without a ton of code. My pitch for Phoenix is that it's essentially Rails but built 10 years later; so it has 10 years of learnings (+ solid concurrency support) but doesn't have 10 years of maintenance baggage.

I wrote this very quickly so it's possible some bits aren't clear/precise/etc and I would be happy to elaborate/clarify on some points later when I have time. But hopefully this was helpful. I would also endorse many of the links others have posted if you are interested in more details! Especially the YouTube talk and the Armstrong paper.

Can someone ELI5 the implications of this please?

It's pretty solid. You may have to roll something yourself for really esoteric APIs, but pretty much everything you probably want to use is supported already

I'm just a little over a year out of school myself, so I'm far from an expert, but happy to share some things that come to mind.

I haven't had a chance to look through it in-depth yet, but this looks pretty interesting: https://github.com/donnemartin/system-design-primer

As far as things that have had an important impact in my learning path, I do have a few Ruby books I really like (the key here is to get your hands dirty with code as you read along): - https://www.amazon.com/Ruby-Under-Microscope-Illustrated-Int... - https://www.amazon.com/Metaprogramming-Ruby-Program-Like-Fac... - https://gumroad.com/l/rebuilding_rails

I think reading about (and looking at the code) for things you use and trying to understand how they work under the hood has been super useful: http://aosabook.org/en/index.html

Having smart people around to learn from is extremely helpful too.

Happy to chat more if you'd like. Just drop me a line: connor[at]opendoor[dot]com

I can't speak for the data science stack, but everything in the web stack is Postgresql (with the exception of Redis for background jobs and things of that nature).

Am I the only one who finds his conversation around the 1:45-2:15 mark of the video to be hilarious?

My understanding is that this was in an Uber Black. He's using the nicest version of his product and the one that pays out the most to the drivers. Sounds about like what I would expect him to do.

Alain Meier and Chris Morton from BlockScore

BlockScore. https://docs.blockscore.com/v4/curl/

Why not say your idea in a line is: "We are trying to bring financial education to the masses in an interactive fun way" instead of the "Uber for X" style idiom? Its easier to understand for the lay person that way too.

Definitely sounds like a lose-lose

You may enjoy this: http://nuclearweaponarchive.org/Library/Teller.html

I'm biased, I have used Zed's books many times, but I found that critique to be far more detailed than it was "good." I got the impression that the author perverted Zed's writing just to take shots at it. LearnCTheHardWay, like all of Zed's other books is of the "write the code first, try to figure out what's going on your own first, and then I'll explain it to you" style. I get that some people don't like that, and if you were just learning how to code, I could see how the C book would be particularly annoying, but he clearly states it's not for people new to code. Mr Hentenaar also can't seem to make up his mind as to how he would like a how-to book to be written. In the first couple sections he complains there isn't enough detail, and then as soon as printf() is introduced, he is whining about the fact that every line of code was explained. Further, as he complains that Zed does with K&R, Hentenaar takes a lot of LCTHW out of context to show why it is "wrong" (such as the "make is the new python" example). Maybe he's trying to be meta in the way he wrote the review, but I doubt it.

As a side note, it is (nearly) impossible for something that hasn't changed in almost 30 years (k&r) to keep up with something as dynamic as a program language. Even if the standard hadn't changed, the way a language is used is practically guaranteed to change over a period that long. Although, as somebody else said, the exercises in k&r are great and it covers a lot of interesting information, but does seem pretty light.