4 ms·

Others don't consider languages which do not handle OS signals a "systems" language: https://github.com/rust-lang/rfcs/issues/1368 https://github.com/rust-lang/

Others don't consider languages which do not handle OS signals a "systems" language: https://github.com/rust-lang/rfcs/issues/1368 https://github.com/rust-lang/rfcs/issues/1368

Jonhoo 10y ago
Not entirely sure what you mean here? Even Bash can handle (some) OS signals, but I don't think anyone considers that a systems language?
- ustolemyname 10y ago
  Well, maybe not Bash, but it seems a dozen years ago referring to Perl as a systems language would not have caused anybody to blink ;) I apologize for how glib my remark above was, it didn't add much to the conversation, and was more a knee jerk response to the notion that "Systems Language" is now, or ever has been, well defined. I brought up the handling of signals, because process management is, in practice, a pretty big deal in what I would consider systems programming. But I don't think it's important to all systems programming. Much like I don't think avoiding garbage collection is necessary for all systems programming, though it's clearly an issue for some applications. What I do find odd is the notion that it is necessary to not have garbage collection, but not having a solid story behind handling signals from the OS receives a pass. Rust can handle signals, but its implementation is very platform specific (even the currently recommended crate lacks Windows support), and ultimately calls out the FFI. So it seems that saying Rust has support for signals is like saying Go supports manual memory management because you can call C.malloc and C.free...
kibwen 10y ago
I'm unsure what this is implying. Rust is fully capable of handling signals, it just doesn't provide any nice APIs for such in the standard library.
- SiVal 10y ago
  Is there a roadmap for what is currently planned for the standard library? A lot of language choice these days comes down to what high-quality batteries are included and what will require either trusting some unknown 3rd party's github project or your own homemade version.
  - Gankro 10y ago
    The first-party stuff in the pipeline is basically: https://github.com/rust-lang-nursery https://github.com/rust-lang-nursery Off the top of my head, Time and SIMD are the only two first-party efforts that are missing from there. Things which will, at this rate, probably never be added -- either because there isn't a "standard" solution to these problems or because it doesn't seem worth it: * async io * web framework/http * numerical hierarchies and bignums * linear algebra / stats * GUIs * "human" time / calendars
    - kibwen 10y ago
      Eh, considering that TCP support already exists in the standard library, I could see HTTP also being added someday if there were sufficient demand. Bignums in general are a bit too open-ended, but I could see bigints at least being added someday. And as for async io, I think it's the same story as with HTTP: imaginably included contingent on implementation maturity and user demand.
pjmlp 10y ago
Which also disqualifies C, because many of the language features that the C crowd uses to argue against GC enabled systems programming aren't part of the C standard, but rather compiler extensions. In a strict ANSI C compliant compiler, signal handling is implemented in Assembly. A systems programming language is one one can be used to write a full OS stack, regardless how heap management is done and how much Assembly help is needed.

Others don't consider languages which do not handle OS signals a "systems" language: https://github.com/rust-lang/rfcs/issues/1368 https://github.com/rust-lang/rfcs/issues/1368

Jonhoo 10y ago

Not entirely sure what you mean here? Even Bash can handle (some) OS signals, but I don't think anyone considers that a systems language?

ustolemyname 10y ago
Well, maybe not Bash, but it seems a dozen years ago referring to Perl as a systems language would not have caused anybody to blink ;) I apologize for how glib my remark above was, it didn't add much to the conversation, and was more a knee jerk response to the notion that "Systems Language" is now, or ever has been, well defined. I brought up the handling of signals, because process management is, in practice, a pretty big deal in what I would consider systems programming. But I don't think it's important to all systems programming. Much like I don't think avoiding garbage collection is necessary for all systems programming, though it's clearly an issue for some applications. What I do find odd is the notion that it is necessary to not have garbage collection, but not having a solid story behind handling signals from the OS receives a pass. Rust can handle signals, but its implementation is very platform specific (even the currently recommended crate lacks Windows support), and ultimately calls out the FFI. So it seems that saying Rust has support for signals is like saying Go supports manual memory management because you can call C.malloc and C.free...

kibwen 10y ago

I'm unsure what this is implying. Rust is fully capable of handling signals, it just doesn't provide any nice APIs for such in the standard library.

SiVal 10y ago
Is there a roadmap for what is currently planned for the standard library? A lot of language choice these days comes down to what high-quality batteries are included and what will require either trusting some unknown 3rd party's github project or your own homemade version.
- Gankro 10y ago
  The first-party stuff in the pipeline is basically: https://github.com/rust-lang-nursery https://github.com/rust-lang-nursery Off the top of my head, Time and SIMD are the only two first-party efforts that are missing from there. Things which will, at this rate, probably never be added -- either because there isn't a "standard" solution to these problems or because it doesn't seem worth it: * async io * web framework/http * numerical hierarchies and bignums * linear algebra / stats * GUIs * "human" time / calendars
  - kibwen 10y ago
    Eh, considering that TCP support already exists in the standard library, I could see HTTP also being added someday if there were sufficient demand. Bignums in general are a bit too open-ended, but I could see bigints at least being added someday. And as for async io, I think it's the same story as with HTTP: imaginably included contingent on implementation maturity and user demand.

pjmlp 10y ago

Which also disqualifies C, because many of the language features that the C crowd uses to argue against GC enabled systems programming aren't part of the C standard, but rather compiler extensions. In a strict ANSI C compliant compiler, signal handling is implemented in Assembly. A systems programming language is one one can be used to write a full OS stack, regardless how heap management is done and how much Assembly help is needed.