Hacker News Reader

Odin can achieve the same feature of checking memory leaks with it's custom allocator system. You can very easily have a custom allocator track the allocations of everything, including its source location. This is because Odin was heavily designed around custom allocators as a core feature.

And coupled with the implicit `context` system, it can very easily profile third party Odin code's allocations too!

BeefLang will report leaks as they occur, not when the program shuts down. There's a tracing "GC" in debug mode for detecting unreachable memory in realtime. It's also used for reliably detecting use-after-free since memory is held when there are references and released when the last reference goes away -- again, a debug-only feature.

This is totally possible with custom allocators in Odin too. You'll be surprised by how much custom allocators can do, but so many people know little about them.

Am I understanding correctly that in Odin feature could even be provided by a third party library implementing such a custom collector? If so, that's seriously cool.

Thanks for the mention, Gene. Thanks for being an early adopter, and keep those bugs and feedback coming in!

As far as performance vs C - there's not a lot of features that incur dynamic dispatch: virtual method calls, dynamic casts (as/is keywords), and direct interface dispatch. When you use interfaces as generic constraints, those monomorph into static dispatches unless the implementing method itself is virtual.

For C-style code, however, the performance should be the same as the C equivalent in Clang. File a bug if it isn't!

> One of my favorite things about it is the way it handles memory during debug runs. (My #1 favorite thing is that it was all developed by one guy working solo - Brian Fiete, a cofounder of PopCap Games.) First, it's able to trace allocated memory during debug execution and immediately report on memory leaks, along with the location in code where the leaked memory was allocated. Second, it can guard against use-after-frees in debug by marking the memory freed, but not actually reclaiming it. Any subsequent writes/reads to that location will immediately fail with the object's allocation stack trace.

Existing C++ tooling (sanitizers) achieve this too.

It’s also cross platform as hell. Amazing at this stage of development.