Do you think about immutability on a daily basis while coding? I certainly don't. Yet, you are very likely making use of it in one form or another: rust's let, git, lsm-based dbs, consensus append-only logs, frontend frameworks, etc. Immutability is literaly everywhere, sometimes hiding behind synonyms like persistent (data-structures), copy-on-write, and content-based. Unfortunately, immutability tends to be predominently associated with functional programming and those pesky "persistent data-structures" that have a bad rep in industry. image The theoretically minded will keep challenging that bad rep on hackernews, pointing to some Rich Hickey talk touting the benefits of immutability in Clojure and Datomic, to some John Hughes article, or to a Joe Armstrong quote about the benefits of immutability in Erlang. But the practically minded programmer who wants to get shit done, fast, will have no-doubt already prepared his Chris Lattner quote as a response: "Functional programming, strictly defined, is dumb."

In this article: We optimize a simple function to use memory pre-allocations and SIMD copying, by using Godbolt to look at generated assembly and control-flow-graph. We observe actual magic happening by pushing ifs up and fors down.if you haven't read this article, stop whatever you are doing and go read it first. We explore 2 reasons why Rust iterators are not zero-cost if you don't know what you are doing: not using ExactSizeIterators leads to extra allocations auto-vectorization won't happen... automatically :(

The goal of this article is to help people speed-run through the states of confusion that I've been going through learning about Optimism and L2s more generally, which I believe anyone learning about L2s would eventually go through. Confusion-Resolution Driven Learning I personally find one of the best ways to learn about systems is to start by watching some overview video, then skim docs, and finally ask myself some dumb questions. Very often I won't be able to answer these seemingly dumb questions and be left in a state of confusion. Fortunately confusion, although painful, is necessary for learning, but only if it is eventually resolved. So one must find a way to resolve that confusion. Sometimes its asking other people, sometimes its reading the code, and other times the best way is to play with runnable example code. The goal of this article is to get readers confused about Optimism by asking questions, and to help readers resolve their confusion, using two separate approaches. We will first get confused about the protocol itself, and resolve this confusion using visualizations. I have found that the optimism spec generally lacks good visuals, all of which exist in their repo but unfortunately are not linked in the book. After understanding the protocol better, we will next get confused about op-batcher and resolve that confusion by running a fork of the optimism devnet, playing with the batcher parameters, and analyzing the behavior using a grafana dashboard. We will leave confusing the reader about op-proposer, op-challenger, and fault proofs to a future article. Getting Confused about the Protocol

Design doc to be submitted to OP Labs, either unofficially in their discord server, or officially in their design-docs github page. Main authors: Samuel Laferriere (EigenLabs): samlaf@eigenlabs.org Bowen Xue (EigenLabs): bxue@eigenlabs.org Karl Bartel (Celo): karl.bartel@clabs.co Suggested Reviewers:

Rohan Shrothrium , Samuel Laferriere Huge thank you to Justin Drake for his thorough review and feedback. Rollups In order to make this FAQ self-contained, we will quickly explain a view of what rollups are in order to ground the future questions about based and preconf rollups in a common understanding. The idea for rollups is to bank on ethereum for DA and settlement, and hence only have to deal with sequencing and execution themselves. Arbitrum has a great visualization of an L2 transaction lifecycle image which clearly outlines these two separate roles: