3 ms·
Nice to see Sean cite Fil-C, though he does it much more in passing than it deserves, considering that Fil-C gives you memory-safe C and C++ without requiring a
by pizlonator 2y ago
Nice to see Sean cite Fil-C, though he does it much more in passing than it deserves, considering that Fil-C gives you memory-safe C and C++ without requiring any annotations whatsoever. He cites it as a sanitizer and references undefined behavior, which isn't really how I would describe it (unlike a sanitizer, it catches all memory safety bugs, and also unlike a sanitizer, it turns a lot of what would have been UB in C++ into defined-but-safe behavior). It's a very different approach from Sean's.
For example, Circle implies broad overhaul to tooling and libraries while Fil-C implies no such thing. Also, Circle is all about not using existing compilers on the grounds that they are hard to experiment with, while Fil-C is a surgical change to clang/LLVM.
The main advantage of Circle over Fil-C is that if you pay the cost of that overhaul, you'll get performance that is better than what Fil-C could ever do even with a lot of optimization. Not obvious to me if that makes it net better, though.
- tialaramex 2y agoFor the performance, there are a bunch of people, some of them probably wrong and others definitely right, who believe they need the best possible performance from software. You can sell these people something like Rust because you can very often either show why the "better performance" C++ they have is wrong (and if they wanted a wrong answer here's zero already, pay me) or sometimes actually worse performance. Not every time, but often enough to make a real difference. The Circle safety feature should be in the same ballpark. You can't sell them anything that's just anyway going to have worse performance, if you could they'd be writing Java already. So that's counting against Fil-C.
- pizlonator 2y agoJava is a totally different language, so it’s not even remotely a competitor in this space. Also Java is quite fast, even compared to C or Rust. Fil-C is all about being able to run existing C/C++ code that nobody is going to rewrite, not even in a dialect like Circle, since the burden of annotations will be too great.
- mike_hearn 2y agoFor existing C++ just using a checked std::vector and Boehm GC can get you quite a long way.
- pizlonator 2y agoNowhere near to memory safety. There are so many exploits left on the table if you do what you say. Not to mention that Boehm isn’t sound on modern C compilers. Conservative stack scanning can be foiled by optimizations that are valid from the compiler’s perspective.
- mike_hearn 2y agoNo, but it can be done without rewriting code. There's a lot of C++ out there that was perhaps once performance sensitive but hasn't been for years due to hardware improvements, or was perhaps never sensitive but used C++ just for team consistency etc. Windows is full of code like that for example. But, there's no funding to rewrite it. For situations like that, things which boost safety but don't require rewrites of any kind are waaaay under-rated. Compilers should definitely have a mode that stops them breaking conservative stack scanning. GC is a drop-in fix for so many memory safety problems it's a vital weapon in the toolbox. Combined with checked array and vector dereferences, you can get a long way without needing Rust or Circle style rewrites.
- pizlonator 2y agoYou get all the way to memory safety if you use Fil-C and you don’t have to rewrite code. I don’t think it’s reasonable to expect compilers not to break conservative stack scanning. Fil-C uses accurate stack scanning instead, and it’s properly wired into the compiler and the rest of Fil-C’s type system.
- mike_hearn 2y agoYes but from your web page about it, Fil-C does things like allocate all local variables on the heap and runs code 50x slower. Bounds checks+GC don't impose such a high level of overhead.