Functional Programming India 🇮🇳《ミ》λ≡

I firmly believe we are at a watershed moment in the history of mathematics. In the coming years, using LLMs for math research will become mainstream, and so will Lean formalization, made easier by LLMs. (1/4)

If you can only learn two languages, they should be: Rust TypeScript

Mostly working in Rust but keeping a curious eye on Zig - it's always interesting to compare the techniques offered by the two. That reflects a lot on the philosophy of language design that they embrace .. Here are four ways to model “interfaces” in Zig (and they compare to Rust traits) .. 1. Generics / duck typing (comptime) • fn foo(T: type, x: T) and require T to have certain funcs • Zero runtime overhead, no vtables, fully non-intrusive • Equivalent to Rust’s static dispatch 2. Tagged unions + switch • Store a tag + data, switch on the tag • Great cache density when you iterate a big array, no function pointers • Often the fastest in hot loops with many objects • Equivalent to Rust's enum + match 3. Manual trait objects (ptr + const VTable) • Every type defines one const vtable, instances carry a pointer to it • Memory overhead per instance: just one pointer (for the vtable) plus your data pointer if you wrap it • No duplication of the function-pointer list across N instances • Very close to Rust’s &dyn Trait fat pointer model 4. Inline function pointers (intrusive AoS layout) • Use this pattern for hot paths where you never keep big arrays of them. If you create lots of objects like this, you duplicate those function-pointer fields. • That grows your stride, hurts cache density, and increases copy/memmove cost • You do save one indirection (you can call s.draw(s) directly), but the win is usually tiny compared to the cache hit you take in object-dense workloads • In Rust you can implement this with structs with fn fields or strategy objects (e.g., struct X { op: fn(&Self) -> … }) and more flexibly, Box fields. But it's not widely used - rather the trait object approach is preferred.