Google's take on memory safety (page 4)

On Saturday, 9 March 2024 at 02:33:16 UTC, Gregor Mückl wrote: > On Friday, 8 March 2024 at 10:43:39 UTC, Paulo Pinto wrote: >> [...] > > This isn't going to happen in this century. > > You're talking about an absolutely *gigantic* amount of software - an utterly, unfathomably, big amount. Many thousand lifetimes' worth of work. > > [...] This is already happening, in Germany if a company is proven to not have provided adequate security measures, customers are allowed to take them to court as per latest cybersecurity laws. Additionally in consulting, security fixes have to be provided free of charge by the delivery company when proven liable.

On 3/8/2024 6:33 PM, Gregor Mückl wrote: > You're talking about an absolutely *gigantic* amount of software - an utterly, unfathomably, big amount. Many thousand lifetimes' worth of work. That's why D enables hybrid C/D programs. D can be gradually introduced into an existing C code base.

On Saturday, 9 March 2024 at 20:18:41 UTC, Walter Bright wrote: > On 3/8/2024 6:33 PM, Gregor Mückl wrote: >> You're talking about an absolutely *gigantic* amount of software - an utterly, unfathomably, big amount. Many thousand lifetimes' worth of work. > > That's why D enables hybrid C/D programs. D can be gradually introduced into an existing C code base. I "ported" a few thousand lines of C to D in a couple hours this afternoon. That includes the time it took to put all C memory allocation inside SafeRefCounted. With the overhead out of the way (setting up the SafeRefCounted structs, testing, and some minor other things) I bet I could easily port 20,000 lines in an 8-hour day. Working directly with C macros was the last thing needed to make this go fast.

On 3/9/2024 3:32 PM, Lance Bachmeier wrote: > I "ported" a few thousand lines of C to D in a couple hours this afternoon. That includes the time it took to put all C memory allocation inside SafeRefCounted. With the overhead out of the way (setting up the SafeRefCounted structs, testing, and some minor other things) I bet I could easily port 20,000 lines in an 8-hour day. Working directly with C macros was the last thing needed to make this go fast. Thanks for posting that, I enjoy such testimonials!

On Sunday, 10 March 2024 at 04:24:15 UTC, Walter Bright wrote: > On 3/9/2024 3:32 PM, Lance Bachmeier wrote: >> I "ported" a few thousand lines of C to D in a couple hours this afternoon. That includes the time it took to put all C memory allocation inside SafeRefCounted. With the overhead out of the way (setting up the SafeRefCounted structs, testing, and some minor other things) I bet I could easily port 20,000 lines in an 8-hour day. Working directly with C macros was the last thing needed to make this go fast. > > Thanks for posting that, I enjoy such testimonials! What about we build maybe a strategy to send D out there! We must let the world see the power of D.

On Saturday, 9 March 2024 at 02:33:16 UTC, Gregor Mückl wrote: > This isn't going to happen in this century. > > You're talking about an absolutely *gigantic* amount of software - an utterly, unfathomably, big amount. Many thousand lifetimes' worth of work. > > It would be a major miracle if even a single one of these chunks of software would get replaced by a rewrite from scratch within the next one or two decades. There's a hidden assumption that this task has to be accomplished the way that software was originally written, and not largely automated. ImportC is an illustration of a strong beginning of such, so that C can gradually be D'ified and, en route, made safer. Moving C to D largely automatically is looking like a real prospect now, making the impossible complete rewrite into something quite different. If D reaches a place where human assisted automatic translation of C source to D source is mostly just automatic, then it becomes a strong contender to solve a significant fraction of the problem by an unexpected route. As I see it, ImportC is a hint about the future.

March 11

Re: Google's take on memory safety

Posted by Martyn
in reply to matheus

Permalink

Martyn

Posted in reply to matheus

Permalink

On Wednesday, 6 March 2024 at 21:34:27 UTC, matheus wrote:
> On Wednesday, 6 March 2024 at 19:13:26 UTC, H. S. Teoh wrote:
>> ...
>
> I think you're being too harsh with Linus Torvalds, back in the day I really think he was right regarding C vs C++ battle.
>
> A couple of years ago he even agreed with some Rust experiments in the Kernel and pointed out some problems later too.
>
> He is a technical person, he usually point out flaws very correctly.
>
> Matheus.

On top of this, Linus knows that he needs to accept the ever changing industry. He wont be a maintainer forever. He has to pass the torch at some point. Younger developers coming in are less likely "C experts" or have interest doing so when we have languages like Rust. I am sure this factors in (with other reasons) why the kernel needs to remain relevant for the new generation.

The number of C gurus will shrink in the next 20 years, which is likely to align with the transition in the Linux kernel to another language. Rust is likely to gain more responsibility in the kernel at this point, and unlikely to be any other language (in my opinion)

From what I have seen, Linus seems pretty level headed towards Rust. I dont think he has any interest learning it. Behind the curtains he might hate the language as much as he does C++. It is moving with the times.

On Monday, 11 March 2024 at 09:41:16 UTC, Martyn wrote: > From what I have seen, Linus seems pretty level headed towards Rust. I dont think he has any interest learning it. Behind the curtains he might hate the language as much as he does C++. It is moving with the times. Rust is already in the Linux kernel: https://thenewstack.io/rust-in-the-linux-kernel/ https://docs.kernel.org/rust/index.html

Forums