Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

    > Maybe because its development is driven for Servo 
    > and not for servers.
This is not true at all. If Rust's development were determined by Servo, we would have kept green threads and implemented struct inheritance by now.

The reason timeouts were dropped is in the IO/OS reform RFC: https://github.com/rust-lang/rfcs/blob/8fa971a670f9b9bc30f31...

    >  set_timeout has been removed for now (as well as other
    > timeout-related functions). It is likely that this may
    >  come back soon as a binding to setsockopt to the 
    > SO_RCVTIMEO and SO_SNDTIMEO options. This RFC does not
    >  currently proposed adding them just yet, however.
And on UDP:

    > All timeout support is removed. This may come back in
    > the form of setsockopt (as with TCP streams) or with 
    > a more general implementation of select.
I'm on shaky wifi and my phone, so I can't find a citation for this, but I also believe it was removed due to 1) Rust not having any stable representation of time and 2) needing to shim certain behaviors on some platforms, which we decided wouldn't happen in the first round of stable interfaces.

That said, the lack here certainly hurts, and we did manage to stabilize Duration, paving the way for timeouts to return.

EDIT: Oh! I forgot that https://github.com/rust-lang/rfcs/pull/1047 got merged recently. https://github.com/rust-lang/rust/issues/25818 implemented it. http://doc.rust-lang.org/nightly/std/net/struct.TcpStream.ht... shows it implemented on nightly, so you can actually even do timeouts today, just not on the stable channel.



Thanks for the clarification. I wanted to subscribe to rust's internals debates and proposals, but I was not sure how to find them. Should I be looking at https://github.com/rust-lang/rfcs or is there anywhere else?


There's a few stages:

1. We keep open issues on that repo to track ideas.

2. At some point, someone may decide to formally propose an idea. They may or may not post a "pre-RFC" to internals.rust-lang.org to get early feedback.

3. An actual RFC will get filed at that repo as a PR.

4. The relevant sub team will check it out and comment, and at some point, consensus will be reached either way.

5. The RFC will go to 'last call' for a week, making sure all voices have been heard.

6. Assuming nothing in last call blocks moving forward, the RFC will be accepted.

7. The RFC will be implemented.

So, in short, yes, subscribing to that repo will notify you of the relevant discussions.


The main places to look are https://internals.rust-lang.org/, https://github.com/rust-lang/rfcs, https://github.com/rust-lang/rust (for actual implementation), and the Rust IRC channels such as #rust-internals on irc.mozilla.org.

IRC is used for quick casual conversation. The internals forum is used for discussion, "pre-RFC", and the like. The rfcs repo is use for actually discussing formal RFCs, as well as wishlist language and library bugs. The rust repo is for the actual implementation of rustc and the standard library itself.


You can also subscribe here: https://internals.rust-lang.org/




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: