A simplified model of Fil-C (opens in new tab)

Yes it's slower, but it works. It's being built by one single dad who focused on compatibility before speed.

I'm not convinced that tying the lifetimes into the type system is the correct way to do memory management. I've read too many articles of people being forced into refactoring the entire codebase to implement a feature.

I think the core advantage of Fil-C (that Java and C# don't have) is that it moves the decision between security and performance to the user, not the programmer.

Imagine you're writing a library for, let's say, astronomical and orbital calculations. Writing it in Java means that it's always going to be slow. If you write it in C, NASA may decide to compile it with a normal compiler (because it won't ever be exposed to malicious inputs), while an astronomy website operator may use the Fil-C version for the extra security, at the cost of having to use slightly more computing resources, which are abundant on Earth.

This doesn't negate the advantages of Rust, which lets you get speed and performance at the same time.

> Fil-C is slower and bigger

It's not any slower or (proportionally) bigger compared to the experience you would have had 20 years ago running all sorts of utilities that happen to be the best candidates for Fil-C, and people got along just fine. How fast do ls and mkdir need to be?

> the rewrite you should have considered wasn't to Rust in the last ten years but to Java or C# much earlier.

That doesn't quite make sense. The point of Fil-C, is to not have to rewrite in any other language, because it's still C. But now, there are safety benefits, though there is a trade-off with size and speed. Even in that context, size and speed, it can be very acceptable to many people and Fil-C will improve in that department as time goes on.

> Rust is just so much nicer.

That clearly is your own personal opinion that not everyone shares. There are many people who do not like Rust.

All of these didn’t prevent Go from competing with Rust and I’m guessing that Fil-C will be the better choice in some cases.

Rust has managed to establish itself as a player, but it’s only the best choice for a limited amount of projects, like some (but not all) browser code or kernel code. Go, C++, C with Fil-C) have solid advantages of their own.

To name two:

* idiomatic code is easier to write in any of these languages compared to Rust, because one can shortcut thinking about ownership. Rust idiomatic code requires it.

* less effort needed to protect from supply-chain attacks

The fundamental question is that if an address is “safe” is a runtime thing, which in some cases you can decide it in compile time but not always. To force that during coding is just handicapping oneself to be “safe”. Which you can do the same in C (or mostly any language if you want it)

> write memory-unsafe code, just now it is guaranteed to crash

If it's guaranteed to crash, then it's memory-safe.

If you dislike that definition, then no mainstream language is memory-safe, since they all use crashes to handle out of bounds array accesses

By that token, Rust is also memory unsafe: array bounds checks and stack overflow are runtime checks.

Rust also has run-time crash checks in the form of run-time array bounds checks that panic. So let us not pretend that Rust strictly catches everything at compile-time.

It’s true that, assuming all things equal, compile-time checks are better than run-time. I love Rust. But Rust is only practical for a subset of correct programs. Rust is terrible for things like games where Rust simply can not prove at compile-time that usage is correct. And inability to prove correctness does NOT imply incorrectness.

I love Rust. I use it as much as I can. But it’s not the one true solution to all things.

What's the alternative?

https://play.rust-lang.org/?version=stable&mode=debug&editio...

For some things the just-crash is ok, like cli usage of curl

Minor nitpick. Or confusion on my part. In the filc_malloc function the call to calloc doesn't seem to allocate enough memory to store an AllocationRecord for each location in visible_bytes. Should it be:

    ar->invisible_bytes = calloc(length, sizeof(AllocationRecord));

A lot of the frameworks do it. There's RC in GNOME/GTK, C++ stdlib, and built into Objective-C.

And of course it's easy to think of lots of apps that heavily use those or another form of GC.

Exactly, the Venn diagram of programmers using c/c++ and programmers who can use a garbage collector for their workload is two circles.

Those using Managed C++, C++/CLI, Unreal C++, the group of WG21 folks that voted C++11 GC into the standard, or targeting WebAssembly (which runs on a managed runtime for all practical purposes).

Windows developers using COM, and WinRT, Apple developers using IO and Driver Kit.

You’re not wrong but both problems could be alleviated by sending patches :-)

> it slows programs down

Interesting, how costly would be hardware acceleration support for Fil-C code.

Even without Fil-C I do not think it is even clear that new software should be written in Rust. It seems to have a lot of fans, but IMHO it is overrated. If you need perfect memory safety Rust has an advantage at the moment, but if you are not careful you trade this for much higher supply chain risks. And I believe the advantage in memory safety will disappear in the next years due to improved tooling in C, simply by adding the formal verification that proves the safety which will work automatically.

could you recompile a c program in fil-c and then decompile it to c and recompile it in c to have the high performance.

Tell me more about Ada!

Hardware-supported capability-based architectures like CHERI are great. I am lilttle skeptical about adpotion prospects of software-only implementation of fat pointers for languages like C and C++.

No, it is not, as has been covered extensively. Atomic operations in Fil-C tear.

  // global
  foo* p = initial();

  // Thread 1  
  p = something_else();

  // Thread 2
  p[attacker_controlled_index] = value;
  

There are interleavings in which p has the value of initial() but the capability of something_else(), or vice versa, which means that an attacker who can perform memory access with an offset into p can access the wrong object through p. This is a violation of memory safety as commonly understood.

But sure, you can just bleat Pizlo's claims of safety instead of engaging with the substance of his runtime model. The point is that Fil-C does not provide full memory safety, and cannot until it updates pointer and capability atomically, and it can't do that without paying much more for general memory access than it does today.