151–160 of 194 posts
I don’t think Rust syntax and patterns (no classes) are especially elegant for many tasks. I can’t express the behavior of a system as cleanly in Rust as TypeScript, C#, go or Python. I know that’s not what it was designed for, but a guy can dream. But what Rust has is the best tooling bar none(cargo, build system, compile time checks, ease of first use). The tooling is actually more important than the borrow checker…
(Sorry for talking about my personal project again y’all.) What I want folks to get out of the Fil-C thing is that the whole notion that C is a memory unsafe language and Rust (or any other language) being safer is a subtle thought error. The truth is: C as it is currently implemented is unsafe, and implementing it in a safe way is possible but we choose not because that would make it slower and use more memory . The…
Earlier quoted context omitted.
It's on my free-time backlog to spend more time with Fil-C, so I'm not disagreeing from lack of interest. Most of annex-J is unrelated to memory safety. No, C has explicit UB because there wasn't a defined behavior that made sense to codify in the standards process. Signed overflow, invalid printf specifiers, and order of evaluation for example. I assume Fil-C doesn't fix things like uninitialized memory or division…
Fil-C absolutely does fix uninitialized memory. It’s on my list to solve division. It’s easy to do and also not super important for the security angle that I’m addressing. But with doing precisely to provide clarity to these kinds of discussions. I’ve mostly tackled signed overflow. I’ve fixed all the cases where signed overflow would let you bypass Fil-C’s own bounds checks. It’s not hard to fix the remaining cases.…
I don’t think Rust syntax and patterns (no classes) are especially elegant for many tasks. I can’t express the behavior of a system as cleanly in Rust as TypeScript, C#, go or Python. I know that’s not what it was designed for, but a guy can dream. But what Rust has is the best tooling bar none(cargo, build system, compile time checks, ease of first use). The tooling is actually more important than the borrow checker…
>dep hell As a C programmer, i'm always a little panic how a small Rust Program can pull in that many crates when compiling.
I've definitely cloned down my fair share of C projects, mashed the make command into my terminal, and watched the gcc/clang logs fly by and never batted an eye beyond checking the sha256sum on any downloaded tarballs.
There's a valid argument to be made about supply chain attacks, but there does exist tooling to lock that down, and I would argue that any serious software development firm should be auditing every third party dependency they take on.
Earlier quoted context omitted.
> If I clone a Rust repo, it’s actually easier to compile, test, and run the code than any other language zig is very comparable, and much faster at doing so. zig also comes with a build system, libc and can compile c programs. its a better c compiler and build system than most, lol.
These are honest questions and not rhetorical: how does Zig handle versions with syntax changes or breaking changes? Can you mix Zig libraries written X years ago with modern Zig? Will today's code work in 5-10 years if I want to use it in a project then?
This is C to Rust, not C++ to Rust. That's important. DARPA was willing to award multiple contracts, but the only one awarded is to a group from several universities. [1] "The team’s approach, Formally-Verified Compositional Lifting of C to Rust (which forms the acronym ForCLift, pronounced “forklift”), uses Verified Lifting, which combines formal methods and program analysis with AI techniques such as Large Language…
I mean... That's what I would expect. It's a translation not a rewrite. The question here is really “what's the end goal?”. Are you gonna refactor parts of the translations output, or is that too much work? Cause a pure translation won't give you anything besides a different compiler and build system. Ah well I guess you can claim you're memory safe and blazingly fast
Earlier quoted context omitted.
This is a bizarre take to me, what do you want to do with classes that aren't supported by structs and traits? Imo the usability issues with rust arise from the borrow checker and associated complexity + restrictions on patterns, so I'm surprised that you're citing macros and classes.
Access control. Here's a struct that maintains an invariant - say, that field a is less than field b. That invariant should be set when it is created. You find a bug where a is greater than b. Where is the bug? With a struct, it can be anywhere in the code - any line that touches the struct. But with a (well designed) class, a and b are private, and so you only have to look at lines of code within the class . The sur…
Take std::os::fs::OwnedFd the file descriptor. In fact of course this struct is literally just a C-style integer inside, it's the same size in memory, representationally they're identical. But, it's encapsulated, so it gets to enforce the fact that file descriptors are never -1 by definition, and since it is encapsulated it gets to refuse to participate in arithmetic, and to call close when we throw away the file descriptor, and so on. It's a huge improvement.
(Sorry for talking about my personal project again y’all.) What I want folks to get out of the Fil-C thing is that the whole notion that C is a memory unsafe language and Rust (or any other language) being safer is a subtle thought error. The truth is: C as it is currently implemented is unsafe, and implementing it in a safe way is possible but we choose not because that would make it slower and use more memory . The…
> What I want folks to get out of the Fil-C thing is that the whole notion that C is a memory unsafe language and Rust (or any other language) being safer is a subtle thought error. I think what you’re doing with Fil-C is cool and interesting. But I think you’re talking past a large part of the “memory safety” audience with this framing: most people don’t want “memory safety” qua uncontrolled program termination, the…
Rust doesn’t rely only on compile-time checks, so I find your claim dubious. Actually, the dynamic checks done by Rust are presented as useful features in themselves.
The memory safety audience and most people seem like arbitrary groups defined to support claims which aren’t really supported by strong evidence.
The biggest improvement in memory safety in the past decades wasn’t thanks to Rust, but languages like Python, Java or C# which rely heavily on dynamic checks. The goal is to catch bugs and avoid security vulnerabilities.
Taking standard C code and achieving the above would be amazing and much more useful than rewriting something in Rust.
Earlier quoted context omitted.
> What I want folks to get out of the Fil-C thing is that the whole notion that C is a memory unsafe language and Rust (or any other language) being safer is a subtle thought error. I think what you’re doing with Fil-C is cool and interesting. But I think you’re talking past a large part of the “memory safety” audience with this framing: most people don’t want “memory safety” qua uncontrolled program termination, the…
Another aspect is that the majority of projects that keep using C, do it specifically to maximize performance or low-level control (codecs, game engines, drivers, kernels, embedded). For such projects, a GC runtime goes against the reason why they used C in the first place. Rust can replace C where Fil-C can't. A technically memory-safe C with overhead is not that groundbreaking. It has already been possible with san…
These are two great reasons to try Fil-C instead of Rust. It seems that many Rustaceans think in terms of their own small community and don’t really have a feel for how massive the C (or C++) universe is and how many different motivations exist for using the language.
Earlier quoted context omitted.
But Zig doesn't have the very sophisticated type system that Rust has. Nor does it, importantly to DARPA, have the memory safety that Rust does.
Don’t underestimate Zig’s comptime or modern C++’s constexpr. You can use these to prove things about the program at compile-time far beyond the type system. In recent versions of C++, the scope of code that is compile-time verifiable is quite large, nothing like when it was first introduced 15 years ago. This has limited (but not zero) applicability to memory safety but it has a lot of applicability to many other cl…
Nope - of course the usual suspects insisted they needed a way to write non-constant expressions and have that somehow "work" anyway. So whereas a const function in Rust genuinely is constant, a constexpr function in C++ might not be, and we only find out whether it was if we force the compiler to do the operation at compile time. If we leave any gap where it can just delay until runtime that's what happens.
You can literally write a random number generator, label it "constexpr" and a modern C++ compiler goes OK, that's not actually constant, but you didn't technically promise it was constant you just used this useless "constexpr" keyword to gesture performatively at the idea of compile time evaluation without promising anything so we'll only complain if you try to use it in a context where I must know the concrete value at compile time.