Summary
⚠️ The Hidden Cost of Exception Handling
The Hidden Cost of Exception Handling
Exception handling is a tricky to get right on many levels - from an API and performance point of view. It requires a high level of context and understanding of the conventions of the org, the tools and languages you're using, and the domain being modeled itself, and is something equal parts art and science. This article by Christophe de Dinechin sheds some light on the cost of exceptions; he writes a recursive Fibonacci sequence algorithm using the C++ templating system, forcing the compiler to evaluate and optimize it at compilation time. He then develops the program further and examines the compilation output at different sizes, program variations, and with or without exception handling enabled; you can view the results for yourself in the link but suffice to say this was a great empirical look at compilers and exceptions handling.
👉 Stop Writing Rust Linked List Libraries
Stop Writing Rust Linked List Libraries
In this post, diziet rigorously evaluates linked list libraries in the Rust ecosystem. They enumerate the many implementations on lib.rs, offer insight into common concepts in Linked List implementations like the cursor, and compare the libraries to the standard library's VecDeque. This was a tour de force in library evaluation, and I'm happy they chose to share it.
🌎 The Distributed Computing Manifesto
The Distributed Computing Manifesto
This manifesto that was publicized this week by Werner Vogels, CTO of Amazon.com, was originally written in 1998. It's short and succinct, but I've already re-read it a few times; it's quite fascinating because, as Werner prefaces, a lot of this methodology has become much more common place (3 tier web architectures, service oriented architectures, and microservices) and some just starting to become more common (workflow engines) - but this was written ~25 years ago. It's hard to pin down the exact terminology of what they mean when they refer to node (AWS certainly didn't exist yet, and even VMWare was just starting up in 1998) and the graph / workflows they make reference to, and there is the possibility that some of it is redacted or abridged. But it largely seems well communicated, contextualizing with the business vision for the change, hallmarks of the proposed architecture at just the right level of granularity, and even (especially) acknowledging necessary changes to how their team at the time would have to work and think.
I've included my favorite highlights from the document below.
At each of these inflection points, engineers would invent their way into a new architectural structure to be ready for the next orders of magnitude growth. Architectures that nobody had built before. They consistently invented themselves out of trouble, scaling a monolith into what we would now call a service-oriented architecture, which was necessary to support the rapid innovation that has become synonymous with Amazon
We propose moving towards a three-tier architecture where presentation (client), business logic and data are separated. This has also been called a service-based architecture. The applications (clients) would no longer be able to access the database directly, but only through a well-defined interface that encapsulates the business logic required to perform the function. This means that the client is no longer dependent on the underlying data structure or even where the data is located
Services, in combination with workflow, will have to provide both synchronous and asynchronous methods. Synchronous methods would likely be applied to operations for which the response is immediate, such as adding a customer or looking up vendor information. However, other operations that are asynchronous in nature will not provide immediate response. An example of this is invoking a service to pass a workflow element onto the next processing node in the chain.
Instead of processes coming to the data, the data would travel to the process.