Note that in theory an efficient system allocator can provide the same guarantees when malloc and free are used -- they can cache freed blocks and reuse them quickly, especially when the vast majority of blocks have the same size, as is the case if your critical workload is a sort on uniform linked lists.

This is only somewhat true. GHC uses a generational GC; when the lists that we are talking about fit in the nursery (minor/young arena), then you get reuse-in-place behavior. Any given list is kept alive by the GC until the next-level list is computed, but its memory space can then be reused, and will be reused in practice if the nursery becomes full, and its collection comes at zero cost. Some languages work hard to implement reuse-in-place schemes (notably Koka has made great experiments in that area), but we already get a flavor of reuse-in-place with generational GCs. Another way to think of this is that with an ideal GC, the memory usage of the program at any point in time is exactly the size of its live set, so you can reason about the ideal memory usage of mergesort and it is only O(n) and not O(n log n) as you wrote. Then GC implementations make compromises, they allocate more memory (but not too much) and they pay some compute cost (but not too much) for book-keeping.

Hmm, I could do that, or I could load the file into a DOS text editor and perform the ancient art of Save As. Which I did, and it loads perfectly now lol. I appreciate the help, though 😄

Sorry my code is pretty atrocious for this since I threw it together quickly to run the benchmark so it's not in great sharable form. But none of the individual optimizations are particularly complex, I'm sure an LLM can easily re-create these and verify the results if you feed it your code + my comment.

Like many languages there is a tradeoff between idiomatic code and tightly optimized numeric hot loops. Applying some optimizations I'm able to get the Haskell vector flat version (fastest version on my hardware) from 4.4x slower than C (your article number) to faster 😄. move salt out of inner hot loop, and instead invalidate once per iter (matching C version behavior, ~7% reduction) switch to PrimArray (faster than both Vector.Unboxed and Storable) (1.6x slower than C) flattening inner loop via a pre-computed nval * j offset table (once at start of bench) instead of nested inner loop with nval * j (1.3x slower than C). I think this is a fair optimization you could really do if this was a critical function, in a real program you would memoize this by stride length but in your bench stride is constant. Why does this inner loop flattening trick work? C compiler sees the benchmark test data dims are 5x5, and is able to automatically unroll the hot loop to 5 straight line copies (since it knows stride = 5 at compile time). We can do the same optimization manually at runtime in Haskell via a lookup table, once we know stride = 5. After modifying the C code so that it's unable to loop unroll (data as runtime input instead of const's) it becomes slower than my optimized Haskell code. Haskell flattened inner loop: 0.77x runtime of runtime data C 😎. Of course, C can benefit from this inner loop flattening also, applying the same optimization to C puts C in the lead again by 14% without vectorization, and by 60% with vectorization. Now the Haskell and C are both running the same algorithm, the gap is roughly broken down as 4/5ths auto-vectorization (Haskell doesn't auto-vectorize, and it's a big win on this problem), 1/5th residual. That 14% residual performance gap is a real performance penalty for Haskell, but it's much much smaller. For any real use case where the performance of this function is critical, you will want to reach for hand written SIMD intrinsics anyway rather than relying on the compiler to always get auto-vectorization correct. Intrinsics are available in both C and Haskell. I think what this shows more than anything else is how challenging it really is to write a good benchmark!

Welcome! C and OCaml is a really nice combination, especially if you’re interested in compilers. Looking forward to seeing what you’re reading or experimenting with.

Hey, welcome! Systems from the bottom up plus formal methods is a cool angle. I’m usually more on the debugging side, but I’d like to learn more about that.

Hey, welcome! Python, JavaScript, Rust, and OCaml is a very practical mix. Rewriting things three times to understand tradeoffs is extremely relatable.

AWS Glue is on 3.9 and ending support. We had to pull scripts and re work them.

the book, went through it too. The constraint driven design is what gets me. And that point about structs is interesting tbh.the way namespaces worked in early C really does feel closer to Fortran COMMON blocks.

Good luck enforcing it. Companies will just move the goalposts or use dark patterns. We need actual teeth in the law, not just a bill.

That's such a naive take. 'Nothing to hide' translates to 'I don't understand how power works or how it can be abused'. It's not about being guilty; it's about due process and protection from arbitrary government intrusion.

Totally. They push these massive 'safety' initiatives that inevitably create more problems, then act surprised when it all falls apart. All talk, no real solutions, just more red tape.

Honestly, it's probably some badly configured S3 bucket or an old FTP server left open from some legacy system. Happens more than people realize, but usually not with government data involving SSNs.

It's less 'access to everything' and more about specific internal tools and permissions. Most regular engineers don't just browse user data willy-nilly. This guy clearly went out of bounds, which makes it a criminal investigation.

Technically, targeting VPNs like this is next to impossible to do effectively without breaking a ton of legitimate internet traffic. What's their enforcement mechanism even supposed to be? Deep packet inspection for *everyone*? This just screams 'we don't understand how the internet works but want to control it'.

Honestly, what's the big deal? If you're not doing anything wrong, who cares if there's a camera? It helps catch bad guys.

As someone who's worked in data security, the fact that a travel company was storing *unencrypted* passport numbers (which they almost certainly were for this to be so easily for sale) is just mind-boggling negligence. There's zero excuse.

Nah, this isn't about their servers directly. It's usually a sync issue with iCloud backups, or messages re-downloading from an old device backup. Or sometimes just an indexing bug locally. Not necessarily 'Apple storing everything forever' intentionally.

Yeah, good luck with that. Like kids won't just find a way around it in 5 minutes. VPNs, using older siblings' phones, fake accounts... this is going to be a nightmare to enforce.

Just give me a manual with crank windows already.

Exactly. What's next, banning phones? The privacy issues are way bigger than just age-gating. It's about data collection.

You really think that's the primary motivation? It's about control, plain and simple. Not stopping bots, but stopping dissent.

As a dev, this kinda thing drives me insane. Imagine being on that team, knowing full well it's garbage, but management insists on 'security through obscurity' and 'release it anyway'.

Right? Imagine trying to get Linux distros or even old legacy systems to implement that. 'Welcome to Windows 95, please verify your age.' Absolute joke.

So, back to the Wild West internet? Cool.

That's a bit defeatist. While they can compel you, *technical* protections like strong full-disk encryption and a very short auto-lock timeout are still your best bet against opportunistic or less-resourced searches. It's about raising the bar, not making it impossible for the NSA. The legal battle is separate.

I mean, it's not 'another one bites the dust' if they're just integrating with existing ad networks or data sharing agreements, which is pretty standard practice. Still shitty, but not exactly groundbreaking in the world of online services.