Remix.run Logo
QuiEgo 6 hours ago

Apple handled this problem by adding memory safety to C (Firebloom). It seems unlikely they would throw away that investment and move to Rust. I’m sure lots of other companies don’t want to throw away their existing code, and when they write new code there will always be a desire to draw on prior art.

goku12 3 hours ago | parent | next [-]

That's a rather pessimistic take compared to what's actually happening. What you say should apply to the big players like Amazon, Google, Microsoft, etc the most, because they arguably have massive C codebases. Yet, they're also some of the most enthusiastic adopters and promoters of Rust. A lot of other adopters also have legacy C codebases.

I'm not trying to hype up Rust or disparage C. I learned C first and then Rust, even before Rust 1.0 was released. And I have an idea why Rust finds acceptance, which is also what some of these companies have officially mentioned.

C is a nice little language that's easy to learn and understand. But the price you pay for it is in large applications where you have to handle resources like heap allocations. C doesn't offer any help there when you make such mistakes, though some linters might catch them. The reason for this, I think, is that C was developed in an era when they didn't have so much computing power to do such complicated analysis in the compiler.

People have been writing C for ages, but let me tell you - writing correct C is a whole different skill that's hard and takes ages to learn. If you think I'm saying this because I'm a bad programmer, then you would be wrong. I'm not a programmer at all (by qualification), but rather a hardware engineer who is more comfortable with assembly, registers, Bus, DRAM, DMA, etc. I still used to get widespread memory errors, because all it takes is a lapse in attention while coding. That strain is what Rust alleviates.

Surac 3 hours ago | parent [-]

So you try to say c is for good programmers only and rust let also the idiots Programm? I think that’s the wrong way to argue for rust. Rust catches one kind of common problem but but does not magically make logic errors away.

ykonstant 2 hours ago | parent [-]

No, they are not saying that at all??

AceJohnny2 3 hours ago | parent | prev | next [-]

> 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 ABI, which degrades its promises).

[1] for more on that topic, I recommend this excellent article: https://faultlore.com/blah/swift-abi/ Side note, the author of that article wrote Rust's std::collections API.

gjajric 2 hours ago | parent [-]

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.

astrange an hour ago | parent | next [-]

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.

gjajric2 29 minutes ago | parent [-]

But at least a lot of tasks in a kernel would require something else than reference counting, unless it can be guaranteed that the reference counting is optimized away or something, right?

pornel 26 minutes ago | parent | prev | next [-]

Apple is extending Swift specifically for kernel development.

pjmlp 2 hours ago | parent | prev | next [-]

What matters is what Apple thinks, and officially it is, to the point it is explicitly written on the documentation.

gjajric2 32 minutes ago | parent [-]

The practical reality is arguably more important than beliefs. Apple has, as it turns out, invested in trying to make Swift more suitable for kernel and similar development, like trying to automate away reference counting when possible, and also offering Embedded Swift[0], an experimental subset of Swift with significant restrictions on what is allowed in the language. Maybe Embedded Swift will be great in the future, and it is true that Apple investing into that is significant, but it doesn't seem like it's there.

> Embedded Swift support is available in the Swift development snapshots.

And considering Apple made Embedded Swift, even Apple does not believe that regular Swift is suitable. Meaning that you're undeniably completely wrong.

[0]:

https://github.com/swiftlang/swift-evolution/blob/main/visio...

pjmlp 15 minutes ago | parent [-]

You show a lack of awareness that ISO C and C++ are also not applicable, because on those domains the full ISO language standard isn't available, which is why freestanding is a thing.

saagarjha an hour ago | parent | prev [-]

Nothing wrong with using reference counting for OS development.

gjajric2 30 minutes ago | parent [-]

Even kernel development? Do you know of kernels where reference counting is the norm? Please do mention examples.

pjmlp 2 hours ago | parent | prev [-]

Also, Swift Embedded came out of the effort to eventually use Swift instead for such use cases at Apple.