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.
For 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.
Java 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.
For existing C++ just using a checked std::vector and Boehm GC can get you quite a long way.
Nowhere 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.
No, 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.
You 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.
Yes 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.
And my web page about it also says that I haven’t optimized it yet.
It’s not necessary to allocate all locals in the heap and have 50x overhead. It’s that way now because I’m only just getting started.
Bounds checks + an unsound conservative GC isn’t worth the overhead it imposes since it still leaves your code memory unsafe.