Comment by nemothekid
2 days ago
>There's a dichotomy being presented here where you have to either choose a "style guide" or a programming language feature in order to avoid bugs. The sleight of hand misdirects the reader away from the main way bugs are eliminated: by dedicating engineering resources to it. You're not giving TigerBeetle nearly enough credit.
In a post-Rust world I really don't like the rebuttal for eschewing memory-safety is always "you aren't engineering hard enough". The guys at TigerBeetle are "real engineers" and don't need memory safety. If I'm spending most of my time manually chasing memory errors, I didn't "real engineer" hard enough.
Chasing esoteric memory bugs are the worst kinds of bugs to pin down. They are always non-obvious (because if they were they would be fixed) and almost always non-deterministic. I'm just can't escape feeling like new memory unsafe languages are just hobby projects.
I've chased down plenty of esoteric bugs in my career and memory safety ones were usually the easiest. There are tools like valgrind, address sanitizer, etc. that help with those, or, like you said, there are memory safe languages (any interpreted language, for example). I've dealt with even harder to find bugs from things such as:
- misunderstood specifications
- missing else clause to an if statement
- wires with the insulation rubbed off in an embedded system with a mechanical design flaw
- accidental endless loops starving all other tasks
- priority inversion
- string encoding problems
- byte order problems
- etc., etc.
From everything I've read now about this bun project, I won't be surprised to hear that it continues to have lots of bugs even after this rewrite to rust