Impressive!

Could someone (or OP) elaborate on the value that re-implementing a whole software to a new language provide comparatively to just building an interface "bridging" both worlds?

To clarify, my metric for "value" is usefulness to other people. That is, without considering the (interesting) learning opportunity that it represent for the author.

For example, someone developed a Python interface to the Stanford Core-NLP library (written in Java). Would re-writing the Core NLP library to Python be useful to the community? How to figure what are people needs?

I am asking because while I think it would be ton of fun and allow me to learn a lot, I also value building useful software and re-writing a whole system sounds like an overkill except for a few very niche cases..

And if I am not mistaken you would need a team at least as large as the parent project to implement new features, fix bugs and keep pace with it. Looking forward to hear what HNers think!

edit: clarified ambiguities

themckman

The README answers this:

  To learn Rust.

Edit: It also mentions not being tied to UNIX and appears to claim it will run on Windows. That's certainly something.

r0naa

Sorry if I wasn't clear, but I am looking for a more general answer! I would like to know in which case it is useful (to other people) and discuss it's value comparatively to writing interfaces to other languages.

seppo0010

I had no intention of making the end result useful, but I run into interesting problems.

First, I wanted to make it as pure Rust as possible. I tried to avoid UNIX specific code, and since there is no library with Windows support for asynchronous IO in Rust, I was pushed into spawning thread and blocking waiting for client data. I quickly noticed that the benchmark was way below Redis (around 60% of ops/sec with 50 clients). But then someone point out to me[1] that I was running tests in a machine with two cores, and this actually may be better for machines with multiple cores[2]. I have yet to try it out and benchmark the results.

So far Rust API was disappointing for network operations. For example, `TcpStream.read()`[3] and `TcpListener.incoming()`[4] do not have a timeout. Maybe because its development is driven for Servo and not for servers.

I have thought about doubling down on multithreading and instead of a global database lock as rsedis is using now, having one per key (or some other arbitrary partition), and having concurrent operations, which is hard to do safely in C. But I have not gotten there yet.

[1] https://github.com/jonhoo/rucache/issues/2

[2] https://github.com/jonhoo/volley/

[3] http://doc.rust-lang.org/1.0.0-beta/std/net/struct.TcpStream...

[4] http://doc.rust-lang.org/1.0.0-beta/std/net/struct.TcpListen...

steveklabnik

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

seppo0010

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?

lambda

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.