331–340 of 853 posts
Earlier quoted context omitted.
Zig at least claims some level of memory safety in their marketing. How real that is I don't know.
About as real as claiming that C/C++ is memory safe because of sanitizers IMHO.
Earlier quoted context omitted.
New high-scale data infrastructure projects I am aware of mostly seem to be C++ (often C++20). A bit of Rust, which I’ve used, and Zig but most of the hardcore stuff is still done in C++ and will be for the foreseeable future. It is easy to forget that the state-of-the-art implementations of a lot of systems software is not open source. They don’t struggle to attract contributors because of language choices, being on…
There's a "point of no return" when you start to struggle to hire anyone on your teams because no one knows the language and no one is willing to learn. But C++ is very far from it.
I'm working on Rust projects, so I may have incomplete picture, but I'm from what I see when devs have a choice, they prefer working with Rust over C++ (if not due to the language, at least due to the build tooling).
Earlier quoted context omitted.
Swift does not seem suitable for OS development, at least not as much as C or C++.[0] Swift handles by default a lot of memory by using reference counting, as I understand it, which is not always suitable for OS development. [0]: Rust, while no longer officially experimental in the Linux kernel, does not yet have major OSs written purely in it.
Nothing wrong with using reference counting for OS development.
Earlier quoted context omitted.
Swift does not seem suitable for OS development, at least not as much as C or C++.[0] Swift handles by default a lot of memory by using reference counting, as I understand it, which is not always suitable for OS development. [0]: Rust, while no longer officially experimental in the Linux kernel, does not yet have major OSs written purely in it.
There's an allocation-free subset. https://www.swift.org/get-started/embedded/ Rust's approach is overkill, I think. A lot of reference counting and stuff is just fine in a kernel.
Earlier quoted context omitted.
> I prefer debugging C I prefer not having to debug... I think most people would agree with that.
I prefer a billion dallars tax free, but here we are:(
Probably kernel dev isn't as easy, but for application development Rust really shifts majority of problems from debugging to compile time.
Earlier quoted context omitted.
[dead]
Oh I agree the survey has issues, I was just thinking about how each year the stats get more questionable! I just think it shows that interest in Rust doesn't come only from people with a C++ codebase to rewrite. Half of all devs have got less than five years of experience with any toolchain at all, let alone C++, yet many want to give Rust a try. I do think there will be a generational split there. > Steve Klabnik?…
Earlier quoted context omitted.
C is fun to write. I can write Rust, but I prefer writing C. I prefer compiling C, I prefer debugging C. I prefer C. It's a bit like asking with the new mustang on the market, with airbags and traction control, why would you ever want to drive a classic mustang?
> I prefer debugging C I prefer not having to debug... I think most people would agree with that.
Earlier quoted context omitted.
> It seems unlikely [Apple] would throw away that investment and move to Rust. Apple has invested in Swift, another high level language with safety guarantees, which happens to have been created under Chris Lattner, otherwise known for creating LLVM. Swift's huge advantage over Rust, for application and system programming is that it supports an ABI [1] which Rust, famously, does not (other than falling back to a C AB…
Swift does not seem suitable for OS development, at least not as much as C or C++.[0] Swift handles by default a lot of memory by using reference counting, as I understand it, which is not always suitable for OS development. [0]: Rust, while no longer officially experimental in the Linux kernel, does not yet have major OSs written purely in it.