I can't speak to whether it's literally as fast as compiled C code. I imagine that there will be common uses cases where it's very slightly less efficient due to its support for things like dynamic dispatch; but I don't see any reason in my brief experience with it why it couldn't at least be as fast as equivalent C++ code. It uses LLVM for its backend.
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.
Both of these are turned off during normal builds but seem to be excellent debugging tools.
The IDE is also cool and was developed in conjunction with the language. It's not the most feature-rich application and there are some bugs as you'd expect, but it's a perfect example of dogfooding as it was written in Beef. Hot code reloading is also supported.
Note that I have zero connection with this language, other than that I really enjoy it so far, and that I reported a minor issue that is probably very specific to me and me alone, and Brian replied to me personally and we had a pleasant brief exchange.
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.
