There are only three programs where memory safety matters: HTTP server, browsers, and operating systems. In practice, really just browsers and operating systems. Memory safety schemes that don't work for those systems are primarily cosplaying if their goal is safety.
Memory safety absolutists
81–90 of 272 posts
Re: Memory safety absolutists
#82Fil-C is basically an alternate ABI and libc runtime. Otherwise it is not tied to C and I see no reason it couldn't be targeted by Rust or Zig.
I think Fil-C ABI implemented by all of C, Rust, and Zig is the future. But that would need some sort of stability for interoperation, and stabilizing ABI takes time: Rust still doesn't have one (while Swift spent enormous amount of effort to have one). Experimental implementation is probably still worth doing.
Re: Memory safety absolutists
#83Earlier quoted context omitted.
We can learn a lot about memory safety from Rust. But if we can achieve the same dream of Fil-C for other more common languages that need it, Rust's popularity will likely wane.
Fil-C has a large performance impact though, and it'll always be reasonably significant. Rusts popularity has always been the combo of safety and performance, otherwise you might as well just use C#
More people should use C#, to be honest.
Re: Memory safety absolutists
#84Earlier quoted context omitted.
> It seems like "can switch on unsafe whenever" vs "has no escape hatches" is an obvious line in the sand and a very useful distinction with real world implications. Sure, although to me, the obvious distinction is that one of them gives you more flexibility (since neither Go nor Fil-C is at risk for someone accidentally writing unsafe code). > Why in the future? It exists and can be used right now. In fact, much of…
Bearing in mind that "there should be no room for a language above assembly and below Rust" (i.e. something like what C or C++ is to Python, Java, C#, etc.) was an intentional design decision for Rust which resulted in `unsafe`.
It seems very common for people to misunderstand that having strict accounting for unsafe is part of why Rust does what it does so well rather than just disallowing unsafe outright. I think it's easily confused because being able to choose "how much unsafe do I want to allow, and where do I want to allow it" allows the choice "I don't want any in my own code" to be easily enforced, and that's by far the most common amount needed, but it's certainly not the only useful one. Being able to handle the edge cases without having to give up the checks entirely is a huge improvement over most alternatives.
Re: Memory safety absolutists
#85There are only three programs where memory safety matters: HTTP server, browsers, and operating systems. In practice, really just browsers and operating systems. Memory safety schemes that don't work for those systems are primarily cosplaying if their goal is safety.
That's really just not true. Easy counterexample: any codec should be written in a memory safe language.
Really anything that deals with untrusted input should be memory safe. Your TLS library. A load balancer. Your password manager.
Re: Memory safety absolutists
#86There are only three programs where memory safety matters: HTTP server, browsers, and operating systems. In practice, really just browsers and operating systems. Memory safety schemes that don't work for those systems are primarily cosplaying if their goal is safety.
That's really just not true. Easy counterexample: any codec should be written in a memory safe language. Really anything that deals with untrusted input should be memory safe. Your TLS library. A load balancer. Your password manager.
And how about safety of life systems? They use computers in chemical plants and on planes, you know lol. Integer overflows have a body count!
Re: Memory safety absolutists
#87I think the "Fil-C is safer than Rust" thing is an understandable reaction to 10 years of Rust evangelists telling people they have to use Rust otherwise they're stupid and wrong.
We can learn a lot about memory safety from Rust. But if we can achieve the same dream of Fil-C for other more common languages that need it, Rust's popularity will likely wane.
I doubt it. I am a big fan of Rust's memory safety, but it's not just memory safety that draws me to Rust. Having a strong, featureful type system is also a big plus for me, and even if Fil-C could someday magically compile any program or library without modification, and its performance trade offs could be mitigated, I'd still write Rust, because C is miserable to write. (And I say this as a 25+ year C programmer.)
Re: Memory safety absolutists
#88Earlier quoted context omitted.
There are too many opensource projects that show that even with good engineering discipline humans are flawed creatures. Memory safety is just little thing that makes sure that when you write code at 4am that it will not leak memory via trivial mistakes such as forgetting to free something, freeing something twice or passing a freed pointer. I believe AI agents shine here the most because the they do not get tired an…
How many bugs in qmail though?
I don't think we should set our expectations based on an extreme outlier. qmail is special, and we can't expect most software to get to its level of security/safety.
Put another way: if you have to rely on programmer skill or attention to detail in order to guarantee something, that will always be a losing bet, on average. The existence of a tiny percentage of programmers that can clear that high bar does not make it a valid strategy.
Re: Memory safety absolutists
#89Earlier quoted context omitted.
How many bugs in qmail though?
It had one bad cve it seems, but that's exactly what I mean. It only takes one mistake, of course you can learn and never make those mistakes again, however, that is an unrealistic expectation in software that receives hundreds of feature updates a year especially when it comes to core applications as basic as communication when it wants to support image previews, reels and whatnot.
There will always be one, so "it only takes one" is meaningless and invalid. That leaves less is better than more, and any form of less is as good as any other form of less.
Re: Memory safety absolutists
#90Earlier quoted context omitted.
We can learn a lot about memory safety from Rust. But if we can achieve the same dream of Fil-C for other more common languages that need it, Rust's popularity will likely wane.
Fil-C has a large performance impact though, and it'll always be reasonably significant. Rusts popularity has always been the combo of safety and performance, otherwise you might as well just use C#
> Rusts popularity has always been the combo of safety and performance, otherwise you might as well just use C#
Combined with the ability to compile to a single native binary, having a solid package management solution, a fairly advanced type system, and a solid selection of nice language features. Usually you need to give up at least one of those.