91–100 of 244 posts
semi-conspiracy theory: the main goal of this rewriting is to have less and less infrastructure depending on GPL and AGPL-licensed code
Apache and Curl are not GPL or AGPL to start with.
Earlier quoted context omitted.
I think this is the issue tracking memory safety in Zig: https://github.com/ziglang/zig/issues/2301
Has any language successfully added memory safety as a "feature" after the initial release? To me memory safety seems like a fundamental aspect of a language that is very hard if not impossible to change afterwards, without so many breaking changes that you essentially in the end have created a new programming language.
Earlier quoted context omitted.
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.
Are you sure? > That’s why we’re expanding our collaboration with the Internet Security Research Group to support the reimplementation of critical open-source software in memory-safe languages. Though the rest of the article doesn't go into detail about this effort beyond http/TLS libs for curl.
Earlier quoted context omitted.
Has any language successfully added memory safety as a "feature" after the initial release? To me memory safety seems like a fundamental aspect of a language that is very hard if not impossible to change afterwards, without so many breaking changes that you essentially in the end have created a new programming language.
Depends what you consider an "initial release", is the point where it is available to the public or the 1.0 release?
Now, if the codebase is small enough to allow for scrutiny by 3rd-parties, that point may be moot, but even then, Google may have some ulterior motive which will not immediately become apparent.
So, I'm kind of suspicious of such an initiative.
"bugs would have been completely prevented by using a memory-safe language" Relying on safe languages isn't going to work as the defect resides in the Memory Management Unit. You would think by now these 'integrated' 'innovators' could come up with a MMU that provides total process isolation.
Nowhere does it call out Rust by name. Go / Zig / Pony / Haskell are all valid contenders.
Go, Pony and Haskell all have complex runtimes and a GC, which makes them unsuitable for embedding into other applications or exposing them as widely usable libraries. Rust, Zig, and to a certain extent D or Nim without GC, can easily expose a C API and have a minimal runtime. But the others do not provide the same guarantees as (safe) Rust with the borrow checker. All very cool languages in their own right, but memo…
It's also introducing isolation [3] to provide safe multithreading similar to Rust's sendable.
[1] https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...
I'm assuming Go will also be an option, what are the others options for core OSS system tools?
No doubt, it will still be around in low latency or embedded. However, this is a significant cut of their market share, especially if Google, Microsoft, and Amazon retires its usage in its systems.
I wonder what implications this has for C/C++ in big tech backends. Startups, from what I've seen, have already moved away. No doubt, it will still be around in low latency or embedded. However, this is a significant cut of their market share, especially if Google, Microsoft, and Amazon retires its usage in its systems.