I think it should be crushed before the bindings creep in and litter up the codebase.
That is indeed another matter. Rust seens very keen on refactoring, and it may happen that this will add push to the rest of the system to do it "their way". That could become a problem.
I'm really not.
Just like any random language. Rust would *need* to replace C (atomically). Because it sure as hell can't interoperate with it as part of a natural evolution. Which is why it is another dead end (at least for our lifespan).
Question:
If someone craps on your front lawn; it is kind of your problem to avoid standing in it each morning on the way to work, regardless of if the person who did it is still pokeing it with a stick or not.
Absolutely. Though, like any language, a ground up rewrite (aka Redox OS, Singularity, etc) is likely the quicker process than many, many refactors, writing temporary binding layers in between stages to get to the same point. And in the meantime, it doesn't break or pollute existing projects.
Sure, I feel that Rust is immature and potentially unproven for very large projects, but these concerns shouldn't hold it back at all. Admittedly it is still *much* more mature than C was when it was used to implement classic UNIX.
Right. Pressure to write new code in Rust ("easy") instead of tiptoeing around it ("hard").
Of course, nobody wants drywall dust everywhere. Do your Rust elsewhere... don't bother the C people.
Indeed. Writing new code is easy. Working with and around existing large systems is hard. This is the developers motto.
I think this kind of "chip on the proverbial shoulder" of Rust developers (almost exclusively) is why they don't tend to be viewed too favorably by existing developers and come against quite a few road-blocks. Contrast this to the Go-lang community who are not nearly as inflammatory and yet also "memory safe and modern".
Heh yes. But certainly it makes sense to wait and see if Linux is damaged rather than "purified" first rather than FreeBSD to also take the risk and jump off that same cliff in parallel.
I think you either have this flipped or you're reading into something I didn't say.
I wouldn't bet on Linux's Rust experiment not working. People really don't like the memory bugs.
People haven't liked memory bugs for multiple decades. And yet here we are
As far as I can tell Apple's macOS, iOS is C in the kernel (not even Obj-C) with a fair amount of C++ for the kernel modules and daemons.
Yeah, and Java does have garbage collection... seems like Rust still has a lot to learn from its predecessor... ?
Simula 67, the granddady of all O-O languages was garbage collected. So was SmallTalk. So is Java. And of course Lisp. I think C++ is the outlier -- some people don't even consider O-O! Something Alan Kay said:
My opinion, that is a perfectly logical stance (I agree with it). Use the appropriate tool for the job.
Another reason for further "packagizing" the base!
Got better tools to solve that problem, now. ?
I've helped write Linux kernel modules in C++, which requires a blood-brain barrier (and before you even ask, the module is to my knowledge never been open sourced, nor does it need to be). It is possible to change languages at the module boundary. It requires a little bit of care, but then all kernel programming requires a lot of care. In an environment with really good software engineers (meaning: they are all experienced professionals, and all get paid to do this job, in a big company), we can except that level of professionalism; and large organizations tend to have functioning software processes.
Do we? I think they said the same thing about Java.Got better tools to solve that problem, now. ?
Indeed. That is a succinct way of putting it.
