Hacker News Reader

Comment by ustolemyname | Hacker News Reader

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

View on HN

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.

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.

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.

The first-party stuff in the pipeline is basically: 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

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.

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?

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...

Reply on news.ycombinator.com