Interesting to see Fil‑C used with a large framework like Qt. The fact that it compiles with minimal changes says a lot about the compatibility layer and the InvisiCaps approach.
In my experience (20+ years with C/C++, and about 4 years with Rust), Rust is significantly less complex than C++, while being similarly capable. The extra syntax that throws off so many C++ devs is almost exclusively about data types and lifetimes, which I find very useful for understanding my own code and others', and which I wish I had in C++.
The real answer should have been a new language that has memory safety without all the extra conceptual changes and orthogonal subsystems that Rust brings. The core value of safety did not need the reinvention of everything else with the accompanying complexity and cognitive load. For example Zig which instead of introducing a new metaprogramkming language, it uses...... Zig - imagine using the same language instead of inventing a new additional language with all the accompanying complexity and cognitive load and problems. Rust is for those who revel in complexity. And traits - traits and extra complexity not needed for safety. And result and option and move by dedfault - none of these things were needed but they all add up to more complexity and unfamiliarity and cognitive load. And when you add it all together and intertwine it you end up with something so unfamiliar that it no longer looks like "ordinary programming" it looks like something from the Cambrian period.
I don’t know what you mean by SafER but it’s important to remember that Fil-C sacrifices a lot of performance for that safety which detracts the reasons you’d be running that software as otherwise C was a bad language for them. Sometimes this won’t matter but there are places fil-c won’t be able to go that Rust can - embedded and OS kernel come to mind. Other places would be things like browsers or games. Rust gives you the safety without giving up the ability to do performance.
Also, I could be wrong but I believe any assembly linked into Fil-C bypassed the safety guarantees which would be something to keep in mind (not a big deal generally, but a source of hidden implicit unsafe).
eh, I daily-drive a -fsanitize=address -fsanitize=undefined build of Qt and actual memory bugs are almost never a thing - I think the only time I had some were in tooling executables such as qmllint, but not in the framework itself. Most of the bugs by large are more "behaviour" bugs.
Depends in which sense you want it to "catch" the bugs. As this readme notes/quotes,
> All memory safety errors are caught as Fil-C panics.
If your problem is a memory-based bug causing a crash, I think this would just... catch the memory-based bug and crash. Like, it'd crash more reliably. On the other hand, if you want to find and debug the problem, that might be a good thing.
Sure, if the memory error is an immediately crashing one like a null per deref, but if is (for example) a memory corruption (e.g. an out of bounds write or a write-after-free) then this would be super helpful in exposing where those are happening at the source.
That’s what “catch” means here. As in, catch it in the act. Tools that make bugs crash more reliably and closer to the source of the problem are extremely valuable.
Sure fooled me. I follow his Twitter account and there isn't much he hasn't got building with it at this point. UX comes later. Amazing it's the random work of one person
I don’t think so much is fil-c itself, but from the looks of the diff it’s a new platform essentially. That can require porting existing software generally which you can read from the posted diff
Most large C code bases aren’t really written in C. They’re written in an almost-C that includes certain extensions and undefined behavior. In this case, it uses inline assembly (an extension) and manipulating pointers as integers (undefined behavior).
Interesting to see Fil‑C used with a large framework like Qt. The fact that it compiles with minimal changes says a lot about the compatibility layer and the InvisiCaps approach.
I believe much more in making C/C++ safer than using something as complex as Rust.
SafER is better than deeply complex and unable to be understood except by Rust experts.
In my experience (20+ years with C/C++, and about 4 years with Rust), Rust is significantly less complex than C++, while being similarly capable. The extra syntax that throws off so many C++ devs is almost exclusively about data types and lifetimes, which I find very useful for understanding my own code and others', and which I wish I had in C++.
The real answer should have been a new language that has memory safety without all the extra conceptual changes and orthogonal subsystems that Rust brings. The core value of safety did not need the reinvention of everything else with the accompanying complexity and cognitive load. For example Zig which instead of introducing a new metaprogramkming language, it uses...... Zig - imagine using the same language instead of inventing a new additional language with all the accompanying complexity and cognitive load and problems. Rust is for those who revel in complexity. And traits - traits and extra complexity not needed for safety. And result and option and move by dedfault - none of these things were needed but they all add up to more complexity and unfamiliarity and cognitive load. And when you add it all together and intertwine it you end up with something so unfamiliar that it no longer looks like "ordinary programming" it looks like something from the Cambrian period.
I don’t know what you mean by SafER but it’s important to remember that Fil-C sacrifices a lot of performance for that safety which detracts the reasons you’d be running that software as otherwise C was a bad language for them. Sometimes this won’t matter but there are places fil-c won’t be able to go that Rust can - embedded and OS kernel come to mind. Other places would be things like browsers or games. Rust gives you the safety without giving up the ability to do performance.
Also, I could be wrong but I believe any assembly linked into Fil-C bypassed the safety guarantees which would be something to keep in mind (not a big deal generally, but a source of hidden implicit unsafe).
If you can’t understand ownership I’m baffled how you believe you can write well behaved C or C++.
Rust at least embeds this information in the API with checks. C and C++ are doc comments at best.
Rust is a much easier language to master than C++.
This is awesome. Would love to see if it catches some of the Qt bugs I found but haven't been resolved yet[1].
[1] https://qt-project.atlassian.net/browse/QTBUG-122658
eh, I daily-drive a -fsanitize=address -fsanitize=undefined build of Qt and actual memory bugs are almost never a thing - I think the only time I had some were in tooling executables such as qmllint, but not in the framework itself. Most of the bugs by large are more "behaviour" bugs.
I only tried to get Qt Base up and running. But Qt Declarative will be next, after Qt Base.
That would be awesome (:
Depends in which sense you want it to "catch" the bugs. As this readme notes/quotes,
> All memory safety errors are caught as Fil-C panics.
If your problem is a memory-based bug causing a crash, I think this would just... catch the memory-based bug and crash. Like, it'd crash more reliably. On the other hand, if you want to find and debug the problem, that might be a good thing.
Sure, if the memory error is an immediately crashing one like a null per deref, but if is (for example) a memory corruption (e.g. an out of bounds write or a write-after-free) then this would be super helpful in exposing where those are happening at the source.
That’s what “catch” means here. As in, catch it in the act. Tools that make bugs crash more reliably and closer to the source of the problem are extremely valuable.
I thought the point of Fil-C was to be a drop in safe replacement of C. This project existing implies it isn't. What's going on?
It isn't entirely drop-in for all programs.
It's not done yet.
Sure fooled me. I follow his Twitter account and there isn't much he hasn't got building with it at this point. UX comes later. Amazing it's the random work of one person
I don’t think so much is fil-c itself, but from the looks of the diff it’s a new platform essentially. That can require porting existing software generally which you can read from the posted diff
Most large C code bases aren’t really written in C. They’re written in an almost-C that includes certain extensions and undefined behavior. In this case, it uses inline assembly (an extension) and manipulating pointers as integers (undefined behavior).