The Morning Paper - a random walk through Computer Science research, by Adrian Colyer

https://blog.acolyer.org/

TLA from First Principles

https://buttondown.com/hillelwayne/archive/tla-from-first-principles/

Distributed Systems - Getting Started & Foundational Papers

https://muratbuffalo.blogspot.com/2020/06/learning-about-distributed-systems.html

https://muratbuffalo.blogspot.com/2021/02/foundational-distributed-systems-papers.html

Durable Execution

https://orkes.io/blog/why-your-applications-need-durable-execution/

https://materializedview.io/p/durable-execution-justifying-the-bubble

First heard about it in a podcast featuring Temporal's CEO

Database Sequences

 

ChatGPT discussion about ULID

https://chat.openai.com/share/e50b65c4-83da-4705-b122-70bb9894ab61

The Log: What every software engineer should know about real-time data's unifying abstraction - Dec 2013

https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying

Akka and Kubernetes, the beginning of a beautiful relationship – Hugh McKee

 

CRDTs: The Hard Parts

System Design class

https://systemdesignclass.com/

gRPC

https://docs.anycable.io/#/getting_startedhttps://grpc.io

AnyCable - ActionCable on Steroids

https://evilmartians.com/chronicles/anycable-actioncable-on-steroids

https://medium.com/@leshchuk/from-action-to-any-1e8d863dd4cf

Asynchronous messaging terms

https://www.kislayverma.com/post/defining-messaging-terms-precisely

Comparing Kubernetes & OTP

https://blog.kenforthewin.com/what-erlang-taught-me-about-distributed-systems/

http://blog.plataformatec.com.br/2019/10/kubernetes-and-the-erlang-vm-orchestration-on-the-large-and-the-small/

https://twitter.com/mononcqc/status/1122872187894018048?ref_src=twsrc%5Etfw

https://blog.ispirata.com/clustering-elixir-erlang-applications-in-kubernetes-part-1-the-theory-ca658acbf101

ElixirConf 2019 - Elixir + CQRS - Architecting for Availability, Operability, and... - Jon Grieman

Would you still pick Elixir in 2019? (github.com) - continuation - comparison with Scala/Akka

An interesting question  and discussion related to Elixir for same link as previous post:

lopatin 5 months ago [-] Does anyone have experience with Elixir as well as Scala/Akka. Afaik, these are the two largest Erlang inspired systems out there. I only have experience with Akka, and I'd love to hear a comparison.

ninjakeyboard 5 months ago [-] I have experience with both. I have recently been working with Elixir. It's okay. I find the lack of static typing to be some thing I celebrate and curse. Elixir is VERY simple and beam is VERY slow at computation. I wouldn't recommend anyone working with scala/akka look at elixir unless you want to understand how BEAM works but I would recommend _everyone_ working with elixir learn different functional programming languages. Ultimately I'm much happier writing scala with akka. I get more done faster (except things like handling json sometimes because it's hard with types), can refactor the code more freely, and release less broken code to production.

ninjakeyboard 5 months ago [-] Also, I have to say that elixir developers are generally not very experienced with it and seem to be generally less desirable than the people who are working with scala. You get rubyists that have some interest in working with elixir because there were some blog posts saying it's the new hotness. Scala seems to attract more comp-sci savvy people. And generally those people will refuse to work with elixir when there are Scala job out there that will pay. Startups should use scala for these reasons. Elixir may be a mistake for the resource pool alone. One thing that's trecherous is that rubyists can bring whatever they believe to be the right way to do things and assume everything should be exactly the same, especially with regards to ecto vs active record. Elixir isn't ruby. Ecto isn't rails active record. Not anywhere close. It just happens to look like ruby and there are some influences in the design but Ecto tells you not too implement STI like rails does for example so don't assume you're going to do it like you would in rails. I'd argue ruby is more like scala than it is like elixir as it has multiple paradigms. Elixir is squarely functional, just a very very simple functional language. The skill ceiling is pretty low and it should take very little time for someone to get up to speed which is important because you won't find a big pool of rockstars using it in the job market so you'll have to hire good people without experience and hope they will be okay using elixir and not jump ship to go work with strong typed languages.

josevalim 5 months ago [-] > Also, I have to say that elixir developers are generally not very experienced with it and seem to be generally less desirable than the people who are working with scala. Scala has been around for 14 years and is built on top of a much more used VM compared to Elixir. Given Scala's growth, it is expected that Scala developers are more experienced as they have been around for longer. Scala also had more time to spread to comp-sci fields, especially as it is taught by many universities. All thanks to Scala's merits, of course! So while I agree that experience is a factor, I wouldn't draw conclusions that those are intrinsic to Elixir or to its users. I also have heard of companies that had no trouble to hire Elixir developers (some have 80 Elixir devs and growing) and some that had many difficulties. As with any other technology, YMMV.

StreamBright 5 months ago [-] Scala/Akka has a much worse developer experience than Elixir/Phoenix. BEAM is fairly slow but you can make FFI calls into much faster implementations if your workload is CPU bound (most of the workloads I am familiar with in the web world are not). Release less broken code to production? I am not sure about it either.

jrx 5 months ago [-] I've used both in production and I must say I'm a very big proponent of both. Actor model of concurrent computation I think maps very well to, at least my, way of thinking and I think is the most productive way of writing distributed systems. Elixir/Erlang/OTP: + Very mature, very well thought out. While the newer stuff may feel a still under construction (string handling, date handling) all the concurrency primitives are rock solid, and by rock I mean diamond. + Elixir is simply a great language and you can get quickly very productive in it once you grasp the actor/process model of BEAM + Has one very big advantage over akka that actors can receive messages in different order than they were sent. That of course can cause some headaches if not handled carefully, but 99% of the time straight up leads to nicer and simpler programs. Really a lot of akka code very often is just written to deal with the order in which the messages may arrive. + Truly resilient with very good error recovery design once you know how to work with it. I still don't know more graceful and productive way of recovering from failures in a running system. - For doing any expensive computations it's slow and it's a fact. Not much can be done about it. - Library coverage is 7/10 or 8/10, but these few missing points can sometimes make a big difference. Scala/Akka: +/- I love Scala language and static typing, but one must be honest that it's much more complex. You can learn Elixir (without macros) in an afternoon. One really needs to take some time and think it through to utilize Scala properly and a true mastery lies even further. To be fair proficiency with Elixir macros also requires a considerable effort, but one can go very far with Elixir without writing macros, while with Scala already the upfront cost is pretty high. + Up to my best knowledge Akka Streams is completely unique and completely amazing library that is gaining support throughout library ecosystem. This is one point where Scala/Akka completely outshines everything else. Streams are such a great abstraction and gave a huge productivity boost to most of the projects I was working on. Compared to that, elixir GenStage feels much less robust and polished. + Speed of JVM should be enough for 99% of applications, and with that respect it wins with BEAM. + Java/Scala library ecosystem is very deep and is simply much more comprehensive than Elixir/Erlang one. - There are places around akka that still feel a bit immature/adhoc, but the library is steadily improving. It just is not as mature as BEAM/OTP. - Over small and mid size projects I think I was more productive with Elixir. Meaning, if I had the same amount of time, I could implement more features in less time using Elixir. But it could be just a personal thing. Overall I think both are fantastic platforms and I'm happy to have both of them to choose for each project. If I were to chose what to select today: - Choose Elixir/OTP for a system where we need to do a lot of io but not much computation and we're sure existing libraries cover our needs. Very big plus if we need it to be resilient. - Choose Scala/Akka if we need speed or call any existing JVM libraries. Very big plus if your project could use Akka Streams.

mrdoops 5 months ago [-] Agreed. The BEAM run-time and the preemptive scheduler implementation is designed to never block and keep chugging a long; highly desirable for the Actor model. The trade-off is you're further from the metal and raw-compute isn't as powerful as a JVM language like Scala. That said an Actor model on the JVM (Akka) can't make the same run-time guarantees using a cooperative scheduler; instead you get all the enterprise libraries and developer hours to tap into. So the trade-off of more complexity in Scala/Akka is probably worth it for big enterprise who are probably already in bed with the JVM. I think we'll see more Akka features built in Elixir through things like Genstage and Flow, but it's hard to argue with the mountain of exiting developer man-hours in the JVM.