No disrespect meant to Mr. Armstrong, but it's possible it's never listed because it's basically a textbook. It's 295 pages. The rough average of all papers in OP is like 15 pages.
I would say 300 is more than slightly longer. Varies by institution and style, but 100k words, 4-5 collated papers, 100-150 pages maximum are quite common.
I would be concerned as an examiner if this came across my desk, more so if I read the colophon where the author comments that they intended to write their own typesetting system, before reading Knuth and wisely concluding that they were unlikely to do anything better than TeX. Top tier yak shaving there.
Yes, but it is boring telecom projects... so most people aren't interested.
Scala is kind of a more modern alternative.
If doing a twitter like platform, elixir with Phoenix channels could handle around >20k users per host. Very few other options work for that use case. =3
There's still a lot of WhatsApp Erlang tooling being published, so I'm pretty sure it's mostly still Erlang. I think I still know a couple people who would share with me if it was rewritten, although I left in 2019.
Erlang is simply the right language to build a chat server with, and it doesn't make sense to rewrite it in another language, even though Facebook did that with the server for Messenger. :P
Certainly parts of the WhatsApp stack have changed considerably. No more FreeBSD / no more only a handful of OS processes per node, much less Mnesia (not sure if there's any Mnesia left... I don't get that level of information). I've seen signs that they may have returned to large nodes, so they might be back to millions of connections per node, but that was very much not the case when I left; connection counts had dropped on our FreeBSD nodes because we were doing a lot more on the chat channel and then again because the Facebook nodes we migrated to were so much smaller than our FreeBSD nodes.
> But Erlang/OTP can replace a lot of expensive kludges.
If you can convince your employer of that. I'm working on a system today (and not for the first time) that could have significantly reduced complexity by switching to Erlang (or Elixir) and OTP. Amusingly, it's a glorified, in-house telecom system that was developed because they chose not to buy an existing solution.
>> But Erlang/OTP can replace a lot of expensive kludges.
> If you can convince your employer of that.
It's probably easier to find an employer that's already convinced. But that's not easy either. :P I'm working in Rust now, because that's what the employer wants to do and it works enough. Half of my work problems would evaporate if we switched to BEAM, but I'd still have the other half and new ones and I'm not sure the rest of the team would be as excited as I am. And they almost certainly wouldn't let me hot load code, which means less fun and less fast iteration :(
Convincing an employer to switch languages is generally hard, regardless of which language, but switching to a system built on BEAM is probably a bigger change than most.
Ah, I just recommended simple AMQP (packed BSON <128k messages) for RabbitMQ with client x509 cert GUID access as secure "middleware" to link all the legacy systems together. The addition of a strict sanitization producer/consumer process bound to each cpu core handles a sliding window idempotent operation handler. Or, people can corrupt their own data if they really try for a finite period, but the system eventually becomes consistent.
Notably, it is possible to rebuild or move the entire infrastructure by issuing a signed resend-logs-to-new-consumer request to clients or servers.
If you start with a dumpster fire at a dried fish factory, than 3 week solutions that last 6+ years under load look pretty nice in retrospect. Your boss is probably contemplating why most Erlang/Elixir people don't work for clown wages. =3
In distributed systems the fist lesson is resilience is more important.
Spend enough time in a computer lab, and you will see things halt and catch fire on occasion. Especially if it has a bunch of GPUs pinning the utilization 24/7, or a cheap power supply in the cluster. =3
Not OP, but a good resource for distributed consensus specifically is Tim Roughgarden's YouTube playlist "Foundations of Blockchains" [0] (hear me out, despite the title - see below). It's 85 videos over 12 lectures, rigorous, very well explained (but assumes some CS fundamentals). Not original work, but gives the conceptual framework and background so that one can read these classic papers in context.
Per-lecture reading lists are on the course page [1]. He also points at Elaine Shi's Foundations of Distributed Consensus and Blockchains [2] and Andrew Lewis-Pye's Consensus in 50 pages [2] as background, though these are more textbooks, not papers.
Remarkably, the first 7 lectures deal with permissioned systems, recapitulating the classic results of consensus in distributed systems (Dolev Strong, FLP impossibility, CAP) - no blockchain in sight. This takes us to the state of the art at the end of the 1990's (with algorithms that can achieve consensus in the presence of byzantine failures, namely Byzantine Paxos and PBFT, though he discusses a modern variant, permissioned Tendermint from 2014).
Lecture 8 stays permissioned and proves consistency and chain quality for the longest-chain rule. Only at Lecture 9, with proof of work, does anything specifically blockchain appear; then L10 block rewards and selfish mining, L11 transaction fee mechanism design; L12 proof-of-stake sybil resistance with the whole litany of attacks possible there.
Very good series in my view, and shows how little technical merit this whole blockchain circus has - nearly all the great properties people tout (reliability, consistency, audibility, availability) can be achieved with good old permissioned tech more efficiently, with pretty instant and deterministic finality.
Anyway, I found the series worth watching for the classical consensus material alone.
You are not 100% correct. Modules in Elixir are like namespaces, they contain functions. They're "static" and don't communicate with anything. Processes communicate with each other via messages.
I currently work on a glorified admin panel. The code should be the easy part. Unfortunately, the codebase is absolute trash. The code and the requirements are hard. My colleagues which drove the codebase to this miserable state think they’re developer extraordinaires. They don’t see the problems, at all. I can’t change anything and if I ask to be put on a different project I might be fired.
So Rails or some PHP framework. It was slightly too early to go full Node. Django was a little unusual too among the developers I knew. Java was still a thing but more for finance related projects.
Well 2010 PHP and the frameworks at the time were still going through the 5.x desert journey, and the prospects weren't entirely clear with the cancellation of PHP 6, so you wouldn't fault your 2010 self for not trying to push some Drupal/Joomla/Magento to that scale.
Kinda took until Facebook showing off Hacklang in 2014 for people to believe in getting more canonical programming features into PHP and make it more performant. So it would have been a good decision if one could predict 10 years into the future, but nobody can.
Rails was fully into growing pains and maintainability crises (some large rails codebases took years to migrate) and PHP was in transition; some good things by then but it was not what it is now.
Location: Varna, Bulgaria
Remote: yes
Willing to relocate: no
Technologies: Elixir, Erlang, JavaScript, Python, SQL
Résumé/CV: https://drive.proton.me/urls/7KWKMN96ZM#mj96pifbhyPI
Email: krasen.penchev@protonmail.com
I’m a software developer, a generalist, with more than 10 years of experience in delivering robust code in industries like online games, healthcare, education, finance, and staff management. Being a team player, I don’t hesitate to give and receive feedback in order for my team to grow. I’m eager to learn, improve, and use best-in-class technologies to build scalable, fault-tolerant, and predictable software. In the last 5 years I’ve been using Elixir to build everything from system daemons to UI heavy applications.
Yeah… I’ve been a professional Elixir developer for 5+ years and additional 4 as a hobby. The quality of the ecosystem and the practices are nowhere near those in OCaml. Sad to say it. People just want to write imperative procedural code and monkey patch in tests so they can test anything at all.
reply