Nowhere does it call out Rust by name. Go / Zig / Pony / Haskell are all valid contenders.
This.
Mitigating Memory Safety Issues in Open Source Software
41–50 of 244 posts
Re: Mitigating Memory Safety Issues in Open Source Software
#42Can someone please fix the title to the original in the blog ('Mitigating Memory Safety Issues in Open Source Software'), because the current title is not at all representative of what the blog is actually saying.
Also "for rewriting popular systems in Rust" is just false. The blog is about improving memory safety and gives two pieces of software rewritten in Rust as an example.
There's nothing about this effort being focused on rewriting things in Rust.
Re: Mitigating Memory Safety Issues in Open Source Software
#43semi-conspiracy theory: the main goal of this rewriting is to have less and less infrastructure depending on GPL and AGPL-licensed code
If all Google wanted was GPL- and AGPL-free code, they're quite capable of assigning their own engineers / contractors to work on it rather than the more tortuous route of going via a 3rd party
> they're quite capable of assigning their own engineers
but if they develop it for internal usage only, then they don't get the added benefit of destroying the existing copylefted version!
Re: Mitigating Memory Safety Issues in Open Source Software
#44Would not be cheaper to fix those unsafe languages, such as C, and offer safe mechanisms that could be used upon need? Why spend thousands, if not millions of dollars, on rewriting existing codebases when they could help fixing the existing toolset and make it safer? I don't get it.
The people "in charge" of C are just not interested in radical changes - they have not even bothered to add better strings. There was a recent post here describing how the C standard bodies even oppose adding warnings, because it would increase the size of building logs.
So the only chance for advancement are those who propose radical changes, like Rust, or Zig if you want something less complex and "spiritually" closer to C
Re: Mitigating Memory Safety Issues in Open Source Software
#45Re: Mitigating Memory Safety Issues in Open Source Software
#46Would not be cheaper to fix those unsafe languages, such as C, and offer safe mechanisms that could be used upon need? Why spend thousands, if not millions of dollars, on rewriting existing codebases when they could help fixing the existing toolset and make it safer? I don't get it.
The main strength of a memory-safe language is that the safety mechanisms are opt-out, not opt-in: you can confine the unsafe behavior to a small, manageable portion of the codebase. And trying to "fix" C to become a memory-safe language would probably just result in something like a Rust dialect that merely bears more superficial resemblance to C. In any case, thorough re-writing of existing codebases would be requi…
I would call C++ a memory safe language that has more than a superficial resemblance to C. Rust makes is more obvious when/where you are intentionally opting out, but most C++ memory bugs are where someone opted out of the modern C++ way to use the C way. (including new/delete as the C way).
Re: Mitigating Memory Safety Issues in Open Source Software
#47Earlier quoted context omitted.
I’m not sure “hijack” is the right word. They are using money to entice projects to rewrite in memory safe languages.
-
Then be satisfied that your project is a good enough idea that someone else is willing to put up money to rewrite it using a safe language.
But if you're not the one doing the rewrite, why would google pay you? And if you would be capable of such a rewrite, may be they would pay you to do so.
Re: Mitigating Memory Safety Issues in Open Source Software
#48Earlier quoted context omitted.
I’m not sure “hijack” is the right word. They are using money to entice projects to rewrite in memory safe languages.
-
Since they don't do that (it's right there in the announcement, which no one in this thread seems to have bothered to read) that whole point is moot:
> The ISRG's approach of working directly with maintainers to support rewriting tools and libraries incrementally falls directly in line with our perspective here at Google.
And a link to: https://www.abetterinternet.org/post/memory-safe-curl/
Re: Mitigating Memory Safety Issues in Open Source Software
#49Earlier quoted context omitted.
I’m not sure “hijack” is the right word. They are using money to entice projects to rewrite in memory safe languages.
Your missing what the two parent comments are driving at. Google says that's what it is doing, but this money is going to "an organization" that will seemingly get it's money from Google, giving Google control over whatever open source projects they target.
> control over whatever open source projects they target.
but if they rewrite the project in rust, why _shouldn't_ they control that project? If other people choose to switch, then it's not wrong for them to move, and not wrong for to google gain control of those users.
The original project maintainers is a third party to this whole process, and i would argue, is uninvolved tbh. It is up to the users of the project to decide to trust google's rewrite (and their tendencies to abandon projects...), vs the original maintainer's version, balanced against the security aspect.
Re: Mitigating Memory Safety Issues in Open Source Software
#50The more I look at Rust the more I realize it’s going to become the next standard language.
You mean standard for systems programming?
I don't doubt that it will be a popular choice in that area, but even there it has competition from new languages.
And above all, I think it might take longer than a century to phase out all the C/C++ legacy code!