If you are not writing anything performance sensitive, you shouldn't be using C in the first place. Even if Fil-C greatly reduces its overhead, I can't see it ever being a good idea for actual release builds.

As a Linux user of two decades, memory safety has never been a major issues that I would be willing to trade performance for. It doesn't magically make my application work it just panics instead of crashes, same end result for me. It just makes it so the issue can not be exploited by an attacker. Which is good but like Linux has been already safe enough to be the main choice to run on servers so meh. The whole memory safety cult is weird.

I guess Fil-C could have a place in the testing pipeline. Run some integration tests on builds made with it and see if stuff panics.

That said, Fil-C is a super cool projects. I don't mean to throw any shades at it.

▲

pizlonator 2 days ago | parent | next [-]

> If you are not writing anything performance sensitive, you shouldn't be using C in the first place.

Then why are all of the IO-bound low level pieces of Linux userland written in C?

Take just one example: udevd. I have a Fil-C version. There is zero observable difference in performance.

▲

cardanome 2 days ago | parent [-]

udevd might actually be a good use for Fil-C. Good point.

My fear is that the performance difference might add up once use it on more and more part. I imagine it uses a lot more memory. Plus once Fil-C gets adopted in the mainstream it might lower the need for devs to actually fix the code and they might start just relying on Fil-C.

To be fair, systemd itself is corporate shite to begin with and I wouldn't mind seeing it being replaced with something written in a language with memory safety.

	▲	pizlonator 2 days ago \| parent \| next [-]
		> My fear is that the performance difference might add up once use it on more and more part If that argument is valid, then why hasn't it stopped adoption of slow languages? Like, Python is waaay slower than Fil-C. And so much of Linux userland is written in shell, which is slower still.
	▲	kardos 2 days ago \| parent \| prev [-]
		> it might lower the need for devs to actually fix the code and they might start just relying on Fil-C. Well, the program would still halt upon memory flaw, so there would still be a need to fix it

▲

jitl 2 days ago | parent | prev [-]

People with Linux servers keep getting hacked so idk if I buy the argument “if it’s in use it’s good enough”. That’s like saying “everyone else runs Pentium 2, why would I upgrade to Pentium 3?”

	▲	cardanome 2 days ago \| parent [-]
		While memory safety can help reduce many security vulnerabilities it is not the only source of vulnerabilities. Furthermore as for getting hacked I would suspect the main problems to be social engineering, bad configuration and lack of maintenance and not really the software itself being insecure. > That’s like saying “everyone else runs Pentium 2, why would I upgrade to Pentium 3?” No one should blindly upgrade because bigger number is better. If I look into new hardware I research benchmarks and figure out if it would enable me to (better) run the software/games I care about it and if the improvement is worth my money. Same with security. You need to read actual studies and figure out what the cost/benefit of certain measures is. There are safer alternatives to Linux but apparently the situation isn't bad enough for people to switch to them. And I am not saying you should create new projects in C or C++. Most people should not. But there is a lot of battle tested C and C++ code out there and to act as if we suddenly have this big problem with memory safety is a weird narrative to push. And if you discover a vulnerability, well fix it instead of wrapping it Fil-C and making the whole thing slower.