Can someone explain how Odin achieves memory safety? Eg how does it avoid use-after-free?
It's not trying to be memory safe, but rather try and catch many common mistakes that C does not catch easily.
As for use-after-free, I'd argue that is more of a problem with the memory allocation strategy in a language like C or Odin. And a change to something like an Arena like memory allocation strategy or something else reduces issues like that by a hell of a lot. `malloc`/`free` like approaches to memory allocation make use-after-free a lot more common because it making you micromanage allocations on a per-value level rather than on a per-shared-lifetime level. It's rare a single value has a unique lifetime, and I'd argue never in many projects.
ObjC is pretty much the sweet spot for me in terms of language complexity and cognitive load over C, while providing so much more. It's really a shame that a lot of people (and I'm not pointing any fingers at anyone specifically) can't get past the [..] syntax, which comes from making ObjC a pure superset of C.
So for example if I have a server, instead of allocating a Request object for each incoming request I should pre-allocate an arena of N request objects and just keep reusing them? Doesn't this blow up memory usage if I have a static pool of objects that may not be actually needed depending on traffic?