I don’t buy it but let’s say that in the best case this happens.

Then we’ll have a continuation of the memory safety exploit dumpster fire because these Rust ports tend to use a significant amount of unsafe code.

On the other hand, Fil-C has no unsafe escape hatches.

Think of Fil-C as the more secure but slower/heavier alternative to Rust

▲

kragen 5 days ago | parent | next [-]

Hmm, maybe this should be on the project's homepage: recompiling with Fil-C is a more secure but slower and more-memory-consuming alternative to rewriting in Rust.

▲

pizlonator 5 days ago | parent [-]

I want to write a detailed post about the strength of Fil-C’s memory safety guarantee at some point. I haven’t yet thought of a sufficiently precise way and sufficiently classy way to say it.

	▲	kragen 5 days ago \| parent [-]
		Does Epic upper management have an opinion?

▲

CuriouslyC 5 days ago | parent | prev [-]

By default you are right. However you can use static analysis and tooling guardrails to reject certain classes of unsafe code automatically, and force the agent to go back to the drawing board. It might take a few tries and a tiny amount of massaging but I don't doubt it'd get there.

▲

pizlonator 5 days ago | parent [-]

If you could get there that way with Rust’s unsafe blocks then you could get there that way with C++

	▲	CuriouslyC 5 days ago \| parent [-]
		probably true. I think thing doing the heavy lifting is an adversarial loop on the generated code to red team it repeatedly before merge.