Linux

But it happens all the time with other languages. Especially when that language is newer or in the headlines. NodeJS/Electron was a big one a few years ago. Ruby/On Rails a while before that, have seen it for python programs and way back in the day when java was all the rage.

Personally I think it does matter and as a end user I do care to come degree. It tells you some things about the program, like how it can be install/run what deps you might need, is it going to be a memory hog or possibly full of vulnerabilities. The language affects all of these things, more so when the projects are new or niche and have not been hardened over time or been properly packaged yet.

Personally I love it when a program is written in languages like rust or go as it means I know it is going to be easy to build/install and distribute given they build into single binaries and very easy to make static. But if I see one written in nodejs with electron I am disappointed as I know it is going to be a huge package that consumes large amounts of memory. Or if there is some python package that is not already packaged by my distro I would avoid it as I hate dealing with python dependencies and its virtualenvs.

And for this case, with redox. Well redox is not an application to be used by people. It is a showcase about what can be done in the language. It is not intended for most people that hear of it to ever run it or even want to run it. Yet is very impressive what they have managed to do in it. Including having parts written for it be able to work standalone in Linux and other OSs.

I'm looking at how many of the bugs and security issues are due to memory unsafe code - it's A LOT and new ones come up almost daily. Humans are just bad at writing safe code because we are so fallible. So if we can eliminate a significant percentage of these bugs from the ground up that suddenly becomes very interesting. Besides personally after two decades of C and C++ (and debugging them) I find Rust much more pleasant and "ergonomic" to use.

If we want an OS to be more secure by design we really have to begin at the most basic level. It might never be perfect but we can greatly reduce the attack surface. This is also why Microsoft is rewriting a number of vulnerable system components of Windows in Rust.

So why is it important to the end-user? Well, if that's Average Joe, maybe not but Redox OS right now is not mainstream, it is for us nerds who are interested in a safer OS and to see what can be done in that space. Maybe you don't care and that's fine, but some of us do and just like any post here, people can chose to skip over it or dive into the discussion, we can't guarantee that all posts or projects are interesting to everyone :)

That's fair, I'm just saying it's not "OS with memory safety" but "OS written in modern language". I guess it's interesting in itself but yeah, definitely not groundbreaking.

You can load Rust into Python just fine. In fact, several packages have started requiring a Rust compiler on platforms thst don't get prebuilt binaries. It's why I installed Rust on my phone.

The build files for Rust are bigger than you may expect, but they're not unreasonably big. Languages like Python and Java like to put their dependencies in system folders and cache folders outside of their project so you don't notice them as often, but I find the difference not that problematic. The binaries Rust generates are often huge but if you build in release mode rather than debug mode and strip the debug symbols, you can quickly remove hundreds of megabytes of "executable" data.

Rust can be told to export things in the C FFI, which is how Python bindings are generally accomplished (although you rarely deal with those because of all the helper crates).

Statically compiled code will also load into processes fine, they just take up more RAM than you may like. The OS normally deduplicates dynamically loaded libraries across running processes, but with statically compiled programs you only get the one blob (which itself then gets deduplicated, usually).

Rust can also load and access standard DLLs. The safety assertions do break, because these files are accessed through the C FFI which is marked unsafe automatically, but that doesn't need to be a problem.

There are downsides and upsides to static compilation, but it doesn't really affect glue languages like Python or Typescript. Early versions of Rust lacked the C FFI and there are still issues with Rust programs dynamically loading other Rust programs without going through the C FFI, but I don't think that's a common issue at all.

I don't see Rust replace all of C either, because I think Rust is a better replacement for C++ than for C. The C parts it does replace (parsers, drivers, GUIs, complex command line tools) weren't really things I would write in C in the first place. There are still cars where Rust just fails (it can't deal with running out of memory, for one) so languages like Zig will always have their place.

Well that is rather insidious. Crap. They probably understand the reasons for the GPL very well. Doesn't mean they support them.