3 ms·
> they expect the ability to manage threads, memory, and even networking as a core part of their language runtime and feature-set. These can be implemented usi
by badsectoracula 8y ago
> they expect the ability to manage threads, memory, and even networking as a core part of their language runtime and feature-set.
These can be implemented using a subset of the language that does not need them, pretty much like C++ requires 'new' but when writing a kernel you do not have enough functionality to use it - so you don't, until you have provided enough infrastructure for its use. Or in a similar fashion...
> None of this is going to work when you're trying to implement those building blocks itself.
...most C stdlib functions are also not available when writing a kernel in C (e.g. malloc/free, fopen/fclose, etc) and you simply do not use them until you have enough infrastructure in place to implement them.
- arghwhat 8y ago> These can be implemented using a subset of the language that does not need them, pretty much like C++ requires 'new' but when writing a kernel you do not have enough functionality to use it - so you don't, until you have provided enough infrastructure for its use. Or in a similar fashion... Definitely. That subset for languages like Go and JavaScript is, however, so small that nothing is left. And for a kernel, that subset would have to be used in the vast majority of the code base. If your goal is to write C with Go/JavaScript syntax, then that might be good enough for you, but that's hardly the point of "Should we rewrite in Rust" talks. > ...most C stdlib functions are also not available when writing a kernel in C (e.g. malloc/free, fopen/fclose, etc) and you simply do not use them until you have enough infrastructure in place to implement them. Of course, that's also how you'd do it in Rust: Don't use things that aren't there. The Go runtime won't give you that choice, though, so you'd have to remove that, which removes pretty much all the language features that makes Go... Go.