3 ms·

It is not technically a matter of interacting with C, but rather a matter of being able to interact in a very controlled fashion. Both JavaScript and Go are fa

It is not technically a matter of interacting with C, but rather a matter of being able to interact in a very controlled fashion. Both JavaScript and Go are fantastic of examples of languages deeply incompatible with OS work, as they expect the ability to manage threads, memory, and even networking as a core part of their language runtime and feature-set. None of this is going to work when you're trying to implement those building blocks itself. It is also not acceptable for a language to decide to do something else outside of the authors' control when working on a kernel, like both JavaScript and Go wishes to do. Attempts to write kernels in Go have been made, but doing so involves defining a subset of Go so small that what you end up with is really just a small new language with a Go-ish syntax, without any of the features. So no, C interaction is by itself not a requirement, but it's more of an indicator for the ability to be in control.

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.

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.