That sounds a bit unfair. All that code that we neither wrote nor understood, I think in the case of Rust, it’s either the borrow checker or the compiler itself doing something it does best - i.e., “defining memory safety away”. If that’s the case, then labeling such tooling and language-enforced memory safety mechanisms as “a bunch of additional code…you didn’t write and…don’t understand” appears somewhat inaccurate, no?

> This can potentially lead to performance and/or control flow issues that get incredibly difficult to debug.

The borrow checker only runs at compile-time. It doesn't change the semantic meaning - or the resulting performance - of your code.

The borrow checker makes rust a much more difficult and frustrating language to learn. The compiler will refuse to compile your code entirely if you violate its rules. But there's nothing magical going on in the compiler that changes your program. A rust binary is almost identical to the equivalent C binary.

The way we've done code reuse up to this point rarely lives up to its promises.

I don't know what the solution is, but these days I'm a lot more likely to simply copy code over to a new project rather than try to build general purpose libraries.

I feel like that's part of the mess Rust/Swift are getting themselves tangled up in, everything depends on everything which turns evolution into more and more of an uphill struggle.

Yeah that is the opposite take of recent posts that the Cargo/npm package dependence is way too heavy.

Saying we should rely on reusable modules is great and all, but that reusable code is going to be maintained by who now?

There's no sustainable pattern for this yet, most things are good graces of businesses or free time development, many become unmaintained over time- people who actually want to survive on developing and supporting reusable modules alone might actually be more rare than the unicorn devs.

One of these days, a project will catch on that's vastly simpler than any memory solution today, yet solves all the same problems, and more robustly too, just like how it took humanity thousands of years to realize how to use levers to build complex machines. The solution is probably sitting right under our noses. I'm not sure it's your project (maybe it is) but I bet this will happen.

It makes it a lot less performant and there is no avoiding or mitigating that downside. C++ is often selected as a language instead of safer options for its unusual performance characteristics even among systems languages in practice.

Fil-C is not a replacement for C++ generally, that oversells it. It might be a replacement for some C++ software without stringent performance requirements or a rigorously performance-engineered architecture. There is a lot of this software, often legacy.

> but in practice fails, because of pervasive use of `unsafe`.

Yes, in `unsafe` code typically dynamic checks or careful manual review is needed. However, most code is not `unsafe` and `unsafe` code is wrapped in safe APIs.

I'm aware C already has a runtime, this adds to it.

> but in practice fails, because of pervasive use of `unsafe`.

Even if we accept this, it's still an improvement from the status quo. As is your project.

Does CPython fail at memory safety because it's C or allows things via C extensions or ctypes? Does C# fail because of similar things? If Fil-C doesn't have a runtime, how does it ensure memory safety when using libc or the Win API? That would be neat to go into!

Anti-Rust zealotry is just as bad as Rust zealotry (if not worse, because there are other things Rust does well, that people may genuinely be excited about).

If your project achieves what it says it does, it'll be a no-brainer because there are more C/C++ codebases and programmers than Rust.

The negativity/vague fear mongering doesn't add to a nuanced technical discussion; it detracts from it. I wish you all the best, the more tools we have for safer code, the better.

The stuff Fil-C adds is on the same footing as `unsafe` code in Rust- its implementation isn't checked, but its surface area is designed so that (if the implementation is correct) the rest of the program can't break it.

Whether the amount and quality of this kind of code is comparable between the two approaches depends on the specific programs you're writing. Static checking, which can also be applied in more fine-grained ways to parts of the runtime (or its moral equivalent) is an interesting approach, depending on your goals.