Hacker News Reader

Comment by pizlonator | Hacker News Reader

> They're not going to mention a single-person experimental project that has 900 stars on GitHub.

Seems like a bad way to pick technology.

They do mention things like TRACTOR. Fil-C is far ahead of any project under the TRACTOR umbrella.

> This is meant to be a practical strategy that can be implemented nation-wide, without turning into another https://xkcd.com/2347

The solution to that is funding the thing that is essential, rather than complaining that an essential thing is unfunded. DOD could do that

View on HN

> Seems like a bad way to pick technology.

This is a very sensible way to pick a technology for a government.

Having a cool proof of concept, with a bus factor of 1, and having a solution that countless government agencies can depend on for multi-million-dollar decades-long software projects are very different things.

They can't just depend out of the blue on you personally maintaining "Fil's Unbelievable Garbage Collector" for the lifetime of the government's projects. Maybe you believe they could, but it takes way more legwork to give such assurance to a government.

They list TRACTOR under projects they've already funded (and crucially, not among solutions they recommend yet). Apply for funding for Fil-C, and if it gets accepted, it'll probably get listed there too.

The TRACTOR approach also has higher tolerance to being an experimental project, because it's one-time conversion of C to Rust. It only needs to work once, not continuously for decades. The Rust-lang org is set up to offer serious long-term support, and is way past having a critical dependency on a single developer.

> This is a very sensible way to pick a technology for a government.

No, it's not, for the simple reason that the government has more than adequate resources to recreate a Fil-C-like with a team, or even just add people power to Fil-C.

The fact that it only took one dude working in his spare time 1.5 years to make C memory safe suggests that the whole narrative of the OP is wrong. The problem isn't that people aren't using memory safe languages. The problem is that nobody is funding just making C memory safe.

You've made a language that is at least 20-50% slower than C and has a garbage collector.

That's not what people use C for. You're presenting it as a memory-safe C, but you've got a more fine-grained ASAN. That's useful, but it's not blowing away the whole narrative.

For running unfixable legacy C code there are already lower-overhead solutions. They're not as precise, but that's either not necessary for safety (e.g. where there's a right sandbox boundary), or the performance is so critical that people accept incomplete hardening despite the risks.

For new development, where a slower GC language is suitable, there are plenty of languages to choose from that are more convenient and less crash-prone.

There's already CHERI that takes a similar approach to pointer tagging, but they're doing it in hardware, because they know that software emulation makes the solution unappealing.

> You've made a language that is at least 20-50% slower than C and has a garbage collector. That's not what people use C for.

Says who?

Most software written in C is not perf sensitive. My shell could be 4x slower and I wouldn’t care.

That’s also true for most of the GUI stuff I use, including the browser.

> you've got a more fine-grained ASAN.

The difference between Fil-C and asan is that Fil-C is memory safe while asan isn’t.

This has nothing to do with “fine grained”.

> it's not blowing away the whole narrative.

The narrative is that C is not a memory safe language. That narrative is false.

If the narrative was, “C is only memory safe if you’re willing to pay perf cost” then like whatever. But that’s not what folks are saying

> For running unfixable legacy C code there are already lower-overhead solutions. They're not as precise, but that's either not necessary for safety (e.g. where there's a right sandbox boundary), or the performance is so critical that people accept incomplete hardening despite the risks.

No there aren’t. Fil-C is the only memory safe solution for C code.

Hwasan, mte, etc aren’t memory safe. Asan isn’t memory safe (and probably also isn’t cheaper). Don’t know what else you’re thinking of.

> There's already CHERI that takes a similar approach to pointer tagging

Neither Cheri nor Fil-C use pointer tagging. Both use pointer capabilities. Fil-C’s capabilities are safer (they actually protect use after free).

Fil-C is faster than Cheri because I can run Fil-C on fast commodity hardware. Fil-C in my x86 box is orders of magnitude faster than the fastest Cheri machine ever

Preach it brother! :)

Hmm, I take it that the situation is that there are a number of vendors/providers/distros/repos who could be distributing your memory-safe builds, but are currently still distributing unsafe builds?

I wonder if an organization like the Tor project [1] would be more motivated to "officially" distribute a Fil-C build, being that security is the whole point of their product. (I'm talking just their "onion router" [2], not (necessarily) the whole browser.)

I could imagine that once some organizations start officially shipping Fil-C builds, adoption might accelerate.

Also, have you talked to the Ladybird browser people? They seemed to be taking an interested in Fil-C.

[1] https://www.torproject.org/

[2] https://gitlab.torproject.org/tpo/core/tor

Tor wants to move to Rust, and they aren't happy with their C codebase. They want to expand use of multi-threading, and C has been too fragile for that.

https://blog.torproject.org/announcing-arti/

Makes sense. But maybe the fact that that post is 4 years old serves to bolster the argument for Fil-C's value proposition. However much people may want to move away from their C code bases, the resources it takes to do so in a timely manner are often not so readily available.

Reply on news.ycombinator.com