Re: The Case for Rust (in any system)

I just completed a month long project to port a C++ codebase that used
vectors for array allocations back to using C‘s calloc. For a 15% increase
in memory footprint, batch jobs that took three days to complete now finish
in 10-12 hours.

That’s what professional engineering is about- making tradeoffs to delight
customers and save money on cloud compute.

What you guys go on about is high school drama club debate.

On Thu, Sep 12, 2024 at 8:18 PM Joe Schaefer <joesuf4@gmail.com> wrote:

> -Werror, valgrind, coverity, fuzzers, etc. CI is a thing.
>
> On Thu, Sep 12, 2024 at 7:59 PM Pat Maddox <pat@patmaddox.com> wrote:
>
>> I think you have those reversed.
>>
>> I would say that a compiler that notifies you of errors is more
>> empathetic than one that doesn't, inasmuch as the compiler's designers'
>> empathy is expressed through the tool.
>>
>> Knowing that we will write errors and can benefit from automated checks
>> expresses humility to me.
>>
>> The safety net of such checks allows us to explore new ideas.
>>
>> C's "don't want memory errors? don't write none" approach is clearly more
>> hostile and requires strict adherence to the rules.
>>
>> Pat
>>
>> On Thu, Sep 12, 2024, at 4:07 PM, Joe Schaefer wrote:
>> > On the other hand, it is foolish to expect a programming language
>> > itself to be more thoughtful and wise than the engineers who need to
>> > solve a computational problem in the here and now.
>> >
>> > It’s like banking on building an empire based on process enforcement,
>> > civility, diversity of preferred quota stereotypes, and obedience;
>> > instead of empathy, humility, diversity of thought, and ingenuity.
>> >
>> > Rust is in the former camp; C the latter.  All progress in this fad
>> > based universe leads to the same joy-free outcome of forever changing
>> > our toolchain to keep up with industry norms that treat professionalism
>> > in computer engineering as a market commodity.
>> > On Thu, Sep 12, 2024 at 3:52 AM David Chisnall <theraven@freebsd.org>
>> > wrote:
>> >> On 12 Sep 2024, at 00:14, Alan Somers <asomers@freebsd.org> wrote:
>> >> >
>> >> > "Memory safety == restrictive training wheels" is just a common
>> >> > misconception.
>> >>
>> >> It’s worth thinking about why programming languages exist. Any modern
>> language is Turing complete. In terms of what can be expressed, there is no
>> difference between Rust, C, and C++. The important thing is that there is
>> an infinite set of possible programs and a finite set of desirable
>> programs. The goal of a programming language is to make it easier to
>> express programs in the set of desirable programs than ones that are not in
>> that set. Sometimes this is skewed away from specific sets.
>> >>
>> >> The reason that we care so much about memory-safety bugs is that they
>> allow an attacker to step completely outside of the abstract machine of the
>> program. Unless you embed an interpreter/ compiler in your program,
>> memory-safety bugs are about the only way that an attacker can get
>> arbitrary code execution in your program. The kind of bug where an attacker
>> provides a specially crafted file / blob of network data and then runs code
>> on your machine is typically the worst thing that can happen.
>> >>
>> >> Rust, in particular, skews towards making programs with memory-safety
>> bugs much harder to represent. You can still do it, by using unsafe or
>> relying on unsoundness in the type system as cve-rs does, but you have to
>> try hard.
>> >>
>> >> I consider that a desirable property in a language. I don’t have to
>> think about whether I’ve made these bugs impossible (and, remember,
>> WannaCry cost billions of dollars and depended on a single memory-safety
>> bug), I get that for free and I can focus on other things.
>> >>
>> >> David
>> >>
>> >>
>>
>