3 ms·

Writing Rust code interfacing libc is a rather frustrating experience though. Many libc interfaces use constructs that Rust really wants you to avoid (for very

Writing Rust code interfacing libc is a rather frustrating experience though. Many libc interfaces use constructs that Rust really wants you to avoid (for very good reasons), things such as global mutable variables (errno and for callback functions without context pointers) or union types. I know about at least one cargo crate attempting to "Rustify" libc with some level of success. None the less, this is what I typically end up doing when writing Rust code as much of th Rust standard library is simply not ready for "serious" usage.

ekidd 11y ago
Personally, I rather enjoy writing clean Rust wrappers for gross C APIs. Doing so does require a solid knowledge of C, and familiarity with a small bag of Rust tricks. In my experience, the Rust standard library is extremely convenient and it handles corner cases very well. There are definitely still holes, but that's what "cargo add $CRATE_NAME" is for. My biggest annoyance with Rust (and it's not a huge one) is that if I'm doing something off the beaten path, I'm probably going to need to wrap a C library or two that nobody has wrapped yet. There's a lot of great stuff on crates.io, but it's only a minuscule fraction of the total C ecosystem.
pcwalton 11y ago
> Rust code as much of th Rust standard library is simply not ready for "serious" usage. Can you elaborate on this? I've been getting serious usage out of the Rust standard library for years...
- DrJokepu 11y ago
  There is no way to select over a range of TcpStream objects. There is no stable way to select over a range of mpsc channels. There is no way to access a TcpStream in a non-blocking manner. There is no support whatsoever for UNIX signals. I could go on.
  - pcwalton 11y ago
    I don't miss the things you mentioned very much, and I think it's an exaggeration to say that these things are what makes Rust's standard library not usable for anything serious. But anyway: > There is no way to select over a range of TcpStream objects. mio > There is no stable way to select over a range of mpsc channels. Yes, this is annoying. We should stabilize MPSC select. You can use BurntSushi's chan for now though. > There is no way to access a TcpStream in a non-blocking manner. mio basically supports this, no? > There is no support whatsoever for UNIX signals. Do many languages have good support for this? The C and C++ standard libraries don't; that's part of POSIX. Signals interact very badly with garbage collectors, so I can't imagine many languages have this.
    - DrJokepu 11y ago
      Mio is not part of the standard library. Go, for example, has excellent support for UNIX signals.
      - pcwalton 11y ago
        So I think our disagreement is semantic. When you say the Rust standard library is "unusable", you mean that you usually need Cargo packages in addition to what the standard library provides in order to write programs in Rust. That is true, but that's just a design difference between Rust and some other languages, like Go. For a systems language like Rust, I think that focusing on having an excellent package manager instead of having a super-comprehensive standard library was the right call. The standard library is very well designed for what it does (IMHO), and I credit the community-based library stabilization process for that. As for Go and signals, I think it's pretty debatable as to whether you can have "excellent support" for signals without the ability to write a true signal handler. Note that this is not a fault of Go and is pretty much inherent to any garbage collected language. I suspect the Rust community would not be particularly happy with an implementation of signals that had hardwired sending to MPSC channels. Even having MPSC channels in the library at all is somewhat controversial...

ekidd 11y ago

Personally, I rather enjoy writing clean Rust wrappers for gross C APIs. Doing so does require a solid knowledge of C, and familiarity with a small bag of Rust tricks. In my experience, the Rust standard library is extremely convenient and it handles corner cases very well. There are definitely still holes, but that's what "cargo add $CRATE_NAME" is for. My biggest annoyance with Rust (and it's not a huge one) is that if I'm doing something off the beaten path, I'm probably going to need to wrap a C library or two that nobody has wrapped yet. There's a lot of great stuff on crates.io, but it's only a minuscule fraction of the total C ecosystem.

pcwalton 11y ago

> Rust code as much of th Rust standard library is simply not ready for "serious" usage. Can you elaborate on this? I've been getting serious usage out of the Rust standard library for years...

DrJokepu 11y ago
There is no way to select over a range of TcpStream objects. There is no stable way to select over a range of mpsc channels. There is no way to access a TcpStream in a non-blocking manner. There is no support whatsoever for UNIX signals. I could go on.
- pcwalton 11y ago
  I don't miss the things you mentioned very much, and I think it's an exaggeration to say that these things are what makes Rust's standard library not usable for anything serious. But anyway: > There is no way to select over a range of TcpStream objects. mio > There is no stable way to select over a range of mpsc channels. Yes, this is annoying. We should stabilize MPSC select. You can use BurntSushi's chan for now though. > There is no way to access a TcpStream in a non-blocking manner. mio basically supports this, no? > There is no support whatsoever for UNIX signals. Do many languages have good support for this? The C and C++ standard libraries don't; that's part of POSIX. Signals interact very badly with garbage collectors, so I can't imagine many languages have this.
  - DrJokepu 11y ago
    Mio is not part of the standard library. Go, for example, has excellent support for UNIX signals.
    - pcwalton 11y ago
      So I think our disagreement is semantic. When you say the Rust standard library is "unusable", you mean that you usually need Cargo packages in addition to what the standard library provides in order to write programs in Rust. That is true, but that's just a design difference between Rust and some other languages, like Go. For a systems language like Rust, I think that focusing on having an excellent package manager instead of having a super-comprehensive standard library was the right call. The standard library is very well designed for what it does (IMHO), and I credit the community-based library stabilization process for that. As for Go and signals, I think it's pretty debatable as to whether you can have "excellent support" for signals without the ability to write a true signal handler. Note that this is not a fault of Go and is pretty much inherent to any garbage collected language. I suspect the Rust community would not be particularly happy with an implementation of signals that had hardwired sending to MPSC channels. Even having MPSC channels in the library at all is somewhat controversial...