91–100 of 190 posts
Earlier quoted context omitted.
How does it compare to the equivalent code in Typescript, Go or C#? Those languages all have “safe” syscall wrappers too, for a subset of syscalls.
Those languages rely on a much larger pile of YOLO C/C++ code for their runtimes and standard libraries than Fil-C does. So Fil-C is safer than those
Earlier quoted context omitted.
So Fil-C is competing with Go, C#, typescript and Python. If I’m writing a greenfield project where “bare metal” performance isn’t needed, why would anyone choose Fil-C over a more mature GC language? C is more verbose and more error prone than Go and C#. It has worse tooling. It’s missing decades of language features. C isn’t properly cross platform. There’s no package manager. The “standard library” isn’t fully sta…
Of the group of languages presented, your argument has more merit for Go. With C# and others, there is an additional OOP argument in there, that splits into different factions. But what is being overlooked, is the massive numerical dominance of C programmers and projects, along with legacy and embedded code. There is going to be a preference for writing and using C, that could arguably fuel Fil-C for a very long time…
I roll to doubt. I haven’t seen C topping programming language popularity charts for a long, long time.
I used to interview software engineering candidates professionally. Candidates could pick any language they wanted for the interview. Python was chosen by about 70% of our interviewees. C was under 5%. (N=400 or so)
Earlier quoted context omitted.
Machine code is unsafe, so any memory-safe language must necessarily be built on some unsafe code somewhere . Safety is always conditional on the underlying unsafe implementation having no bugs. With Fil-C, the "unsafe blocks" live entirely within the compiler and runtime. With Rust, the unsafe foundation is the Rust compiler and standard library, as well as any unsafe code within your application or dependencies. So…
There are no 'unsafe' blocks in Fil-C. I think you trying to conflate 'unsafe blocks' with the fact that there might be compiler errors which might break 'safety'? Which is equally true in any system including Rust.
Earlier quoted context omitted.
indeed, the ideas could be used more widely. fil-c runs on linux. what if linux ran on fil-c?
Do you want your kernel to be 2x slower and use 4x as much memory?
Earlier quoted context omitted.
Better include Rowhammer too. Maybe Fil-C should run a test and refuse to start on any system with bad RAM or unpatched CPU errata. It could also monitor the voltage to protect against undervolting attacks. And you'll need some cosmic ray shielding too. Of course I'm kidding, but it is absolutely the case that if you truly care about safety you need to consider more than the program source code and binary, but also t…
Sure all of those are escape hatches that work against any memory safety tech. Point is, Fil-C goes further than any other memory safety tech in terms of what it guards
Anyone could do the same with a Rust lint rule if he wanted. He wouldn't, because this policy is not the way to secure software.
Earlier quoted context omitted.
Of the group of languages presented, your argument has more merit for Go. With C# and others, there is an additional OOP argument in there, that splits into different factions. But what is being overlooked, is the massive numerical dominance of C programmers and projects, along with legacy and embedded code. There is going to be a preference for writing and using C, that could arguably fuel Fil-C for a very long time…
> But what is being overlooked, is the massive numerical dominance of C programmers I roll to doubt. I haven’t seen C topping programming language popularity charts for a long, long time. I used to interview software engineering candidates professionally. Candidates could pick any language they wanted for the interview. Python was chosen by about 70% of our interviewees. C was under 5%. (N=400 or so)
C is still highly ranked on many charts. C (as of July 2026) is ranked #2 on the TIOBE index. PYPL has C and C++ weirdly merged, the annoying C/C++, and that comes in as #3. The IEEE and Redmonk have C firmly in the top 10, using different methodologies. We also have to consider how many years back that C's run in the top 10 goes.
We have to also use context, as popularity can be a measure beyond simply job demand, relative to usage by students, hobbyists, open-source, and legacy. Furthermore, demand can be relative to location and country. Because it is less in your specific area or company, doesn't mean that's so in other areas or countries.
Earlier quoted context omitted.
Do you want your kernel to be 2x slower and use 4x as much memory?
A computer spends the vast majority of its time and memory in userspace, so this tradeoff isn't as bad as it sounds.
It would sometimes be a good trade off, for some users. But I don’t think many regular users would choose to pay this cost.
Earlier quoted context omitted.
Those languages rely on a much larger pile of YOLO C/C++ code for their runtimes and standard libraries than Fil-C does. So Fil-C is safer than those
Small nitpick but Go doesn't really have any YOLO C/C++ code in its runtime and standard library.
Go’s situation is nuanced since a lot of Go code does rely on unsafe C or C++ deps, but I have no idea how generally true that is. Also Go’s protections fall apart under certain races, which isn’t true in Fil-C.
Earlier quoted context omitted.
Small nitpick but Go doesn't really have any YOLO C/C++ code in its runtime and standard library.
Yeah what I said is true of TS and C#, but not of Go. Go’s situation is nuanced since a lot of Go code does rely on unsafe C or C++ deps, but I have no idea how generally true that is. Also Go’s protections fall apart under certain races, which isn’t true in Fil-C.
Fil-C's safety guarantees therefore fail to apply in this situation.
Earlier quoted context omitted.
Of the group of languages presented, your argument has more merit for Go. With C# and others, there is an additional OOP argument in there, that splits into different factions. But what is being overlooked, is the massive numerical dominance of C programmers and projects, along with legacy and embedded code. There is going to be a preference for writing and using C, that could arguably fuel Fil-C for a very long time…
> But what is being overlooked, is the massive numerical dominance of C programmers I roll to doubt. I haven’t seen C topping programming language popularity charts for a long, long time. I used to interview software engineering candidates professionally. Candidates could pick any language they wanted for the interview. Python was chosen by about 70% of our interviewees. C was under 5%. (N=400 or so)