Hacker News Reader

Comment by mattbee | Hacker News Reader

The Fil-C project ( https://fil-c.org/ ) seems like a more pragmatic way to deal with C security holes in old, well-loved userspace code. It effectively turns C into a managed language rather than a bare metal one, seems to remove a lot of the impetus to rewrite.

View on HN

I really like the idea of Fil-C for derisking legacy code, but

- It's not an option for debian core infrastructure until it supports at least the same platforms debian does (arm, riscv, etc) and it currently only supports x86_64.

- It doesn't turn C into a modern language, since it looks like there's active development here getting the productivity benefits of moving away from C is likely still worth it.

If C isn't going away yet, just doing filc for x84_64 might still be a big win as it could catch a lot of stuff at runtime for x84_64 users that can then be fixed for everyone.

Given that a few languages from similar timeframe are still around, even if with fewer users, it is guaranteed to stay around as long as current computing models stay relevant.

If you're single platform (Fil-C is x86-64 only), if the program is finished (Fil-C doesn't magically make maintaining a C project any easier to handle) and if performance isn't relevant (Fil-C is and despite its originator's confidence always will be bigger and slower than what you have today) then I agree.

Making core package infrastructure 10x slower doesn't seem especially pragmatic.

The author's benchmarks suggest 10× would be a pathological case!

But even so - what price correct & secure software? We all lost a tonne of performance overnight when we applied the first Meltdown and Spectre workarounds. This doesn't seem much different.

We have an alternative that isn't 10x slower, and comes with many other benefits (Rust). The only cost is losing hardware support for some very obsolete and very unpopular platforms. (Nevermind that Fil-C's hardware support is narrower than Rust's.)

Rust doesn't automatically add memory safety to all existing C code, which will need to be maintained for decades, Fil-C nearly does and its still early days.

> We have an alternative that isn't 10x slower, and comes with many other benefits

Anyone involved with development around a fruity company would say Swift ;)

I don't get the impression the Swift team is especially interested in use cases outside of OS X and iOS. (The context here is Debian.)

There seems to be a push to get Swift outside of just Apples platforms, namely Linux and Android support and backend micro service developnent.

Reply on news.ycombinator.com