Hacker News Reader

Comment by vmchale | Hacker News Reader

It looks like it's not memory safe? What does this offer over existing options?

There are some optional memory safeties, including real-time leak detection, but this language targets an audience who value performance over total memory safety.

For someone looking for a C replacement where memory safety is absolutely critical (ie- open server applications) then Rust may be a better fit.

> value performance over total memory safety

Is there any evidence this is a tradeoff? What of linear types?

> Is there any evidence this is a tradeoff?

Bound checking often is the reason rust performs worse on some benchmarks. Though I wouldn't consider this a problem at all since it can be disabled.

It's better to manually hoist the bound checks so that they happen before any critical loop. The compiler often can't do this because it has to preserve the partial effects of where the failed bounds check happens, but that's generally not what you really want; if anything, you'd rather fail fast.

Linear types (and affine types, as in Rust) only buy you some memory safety (preventing use-after-frees, and memory leaks although that's not really a safety issue).

The more important part of memory safety is preventing out-of-bounds accesses. Rust, Ada, and (it seems) Beef sacrifice performance for memory safety here by having runtime bounds checking. (Though there is not much performance cost to this and all of those have options to turn off runtime bounds checking anyway.)

The only performance-oriented language I'm aware of that is fully memory-safe at compile time is ATS‚ via a combination of linear types and dependent types, and using ATS is… cumbersome.

> Rust, Ada, and (it seems) Beef sacrifice performance for memory safety here by having runtime bounds checking

Its not all black and white though. Using iterators, bounds checks can often be elided by the Rust compiler.

leaks aren't unsafe though. Things like bounds checking and aliasing guarantees are like 90% of the memory safety issues you care about, and those can be performant.

It seems to have some memory safety features:

https://www.beeflang.org/docs/language-guide/safety/

> Leaks can be detected in realtime with the debug memory manager. Reachable memory will be continuously traced at runtime and memory which is no longer reachable but has not been properly freed will be immediately reported as a leak...

Sounds like it doesn't have a Garbage Collector, but a "Garbage Detector" that's only active for debug builds?

That's still not the same as affine/linear types, which other languages offer.

Also, testing helps detect bugs, but cannot guarantee security.

Yes, this is right - there is what is essentially a fully-functional "garbage collector" but its only job is to detect leaks in debug builds. Well, it also is used for detecting illegal memory layout changes during hot code changes...

One may say "then why not just make the GC optional like D", but when you design a library you really need to either design it for a GC or for manual memory management. Even for the basic string type - if Beef was a GC'd language then String would be immutable, but it's not so String is mutable. Totally different designs.

Reply on news.ycombinator.com