And you are here why?

“Quick, how many FSMs are there in your code?” Zero, right? (Yeah, I didn’t need to say “Quick” — you already knew the answer) A better question might have been “ How many places in your code could benefit from using an FSM? ”. This, one is a lot more discuss-able, with pro-FSM and anti-FSM camps getting into the usual thing (if you’re hankering for entertainment, grab some popcorn, and then ask a group of erlang devs about  gen_fsm ). Rephrasing the question yet again into “ How come there are no FSMs in your code? ”, you usually get responses like “ I didn’t need them when I started ”, and “ They’re too complicated ”. And  now  we get to the heart of the matter. Let’s parse these two responses “ I didn’t need them when I started ”: We’re all trained to incrementally add behavior to our code, and, when you’re starting out, it just doesn’t seem like the system is worth the time, energy, and effort associated with using an FSM. “ They’re too complicated ”: Rem...

You’ve really gotten into this whole Observability thing, and have started plugging Prometheus into, well, everything that doesn’t already have it.  And you’ve   also   started implementing OpenTracing because, well, you’ve got a distributed something, and not doing it, or something like it, would be just plain dumb. And you realize that you’ve now spent the last week pulling together some kind of consistent wire protocol that works seamlessly across the metrics and the traces,   and you haven’t even started on the APIs , and surely,   surely somebody has already done this?   Enter OpenCensus (•), the open-sourced version of Google’s Census library, and which gives you  • Standard wire protocols and consistent APIs for handling trace and metric data.  • A single set of libraries for many languages, including Erlang, Java, C++, Go, Python, Ruby, and more  • Integrations with your favorite web and RPC frameworks  • Exporters for storage...

Reliability is Hard. Oh, there are tools to make it easier, but “easier” is not the same as “easy”. And Reliability is, certainly, not Easy. When you factor in the (geometrical) complexity of distributed components, and the (geometrical) complexities that get layered on top when these components span nodes, and then networks, well,   “Reliability is Hard”   gets close to being the Understatement of the Year. And that’s where rigor comes in, rigor in the form of empirical tests, rigor in the form of mathematical certainties, rigor in the form of proofs, models, and battle-testing, in short   RIGOR . Do you, genuinely, understand what your system does? Can you explain this to others, simply, in a form they can understand (a-la Feynman)? Most importantly, is there any place in the system where you up with “I hand-tuned this till it worked” “I implemented my own   <something in common use, that I didn’t know existed> ” “It doesn’t matter, it works, and ...

The world of Distributed Systems is as much about philosophy as it is about implementation — the specific context, architecture, tooling, and developers all come together to make your way different from everybody else’s. And yet   yet , there are overarching themes and patterns that hold true, that you ignore at your own peril. The most important of these is the necessity to architect for failure — everything springs from this. (°) Complexity grows geometrically with the number of components, and no amount of fakes, strict contracts, mocks, and the like can reduce this. If anything, poor practices will only   increase   this complexity The key is to accept this, and align the risk associated with a given service/component with the risk the business is willing to take. In short,   make the component reliable, but no more reliable than necessary” As a developer, what this means is that you   must • Understand the operational semantics of the system as ...

Let’s get something out of the way first               Boring =/= Bad Of course there is any amount of Boring   and   Bad (°) out there, but here the reference is to stuff that #JustWorks, whose implementation surface is well defined, whose failure modes are well understood, and whose edge cases tend to qualify as “Good Problems To Have”. #Postgres   is Boring.   #Varnish   is Boring.   #AWS   is Boring.   #Erlang   is Boring. Wait,   what ?   Erlang ?Yes indeed, it is, in many ways, the   quintessential   Boring technology. Remember, your job, as a technologist, is to keep the company in business. Everything else — reducing costs, increasing revenue, using the best tool, “having fun”, etc. — are subordinate to keeping the company in business (°°). And, keeping a system working reliably is waaay more expensive that building the damn thing in t...

(#Erlang)  Here Lies Coder"          "pang"

A straight cut-and-paste from erlang-questions - it pretty much sez. it all, and very eloquently at that Anything can be done in any language, so the technical answer is "nothing". But the spirit of the question begs for an answer, especially in a company situation with deadlines. My company does mostly business data systems and custom extensions to certain products of ours. Originally we used a mix of Python (probably 70%), PL/pgSQL (maybe 10%), Guile/Scheme (probably around 10%), C (5%ish) and a smattering of Bash, Perl, Scala or Java, etc. where necessary. I am extremely familiar with Python and Guile, and between those two a one-dimensional solution to any conceivable problem can be reduced to triviality. They are great languages. They have great libraries. They tie into the rest of the *nix world smoothly. Super tools, *vastly* superior in every way (for us) than more prolific tools such as Java. But when it came time for us to deal with some new feature requests -- ...