What's everyone working on this week (26/2016)?

New week, new Rust! What are you folks up to?

Have you ever wanted to write a number into an io::Write as fast as possible? This weekend I published two crates itoa and dtoa to do that. Check out the readmes for a chart of performance compared to the standard write! macro. There is a 3-10x improvement in many cases.

let mut buf = Vec::new();

let i = 65535u64;
try!(write!(&mut buf, "{}", i)); // slow
try!(itoa::write(&mut buf, i));  // FAST

let d = 2.71828f64;
try!(write!(&mut buf, "{}", d)); // slow
try!(dtoa::write(&mut buf, d));  // FAST

I am currently using Rust to implement a physically based raytracer with the help of pbrt. Just to understand the concepts for physically based rendering.

1 Like

I just re-triaged all the E-easy bugs. Somebody come fix them!

Other than that I'm going to be hacking on rustup (which also has "help wanted" bugs), and finishing a survey of standard libraries in batteries included languages.


Why did this need to be in two separate crates, I feel like it is kind of a waste. Could the API look like this instead?

extern crate toa;

import toa::{dtoa, itoa};



There doesn't seem to be any point to not putting them into the same crate. It seems like this stems from the NodeJS mentality, of having as many tiny crates as possible. Im personally not a fan of this mentality, as Rust can optimize the unused code out.

I'm implementing a gateway server with the new async model introduced into hyper. My goal is to get a working prototype up before my TD returns from vacation so that I can convince him we don't have to write it in C++.....

@sinistersnare: Being in the same crate would require them to have the same version. The two are totally independent implementations so any future breaking changes for one are not necessarily breaking changes for the other.

They could have been two crates in the same GitHub repo but I don't think that is what you are suggesting.

An extremely incomplete Scheme interpreter that doesn't even compile yet, but which I am hoping to get working.

Also trying to figure out if anyone will use it even if it is finished. Does anyone here think that there would be a use case?

Plunging into the rabbit hole and learning how rotor works and making a lot of faces like this:

Enjoying figuring it all out though :smiley:

I'm working on a Rust implementation of Cauterize, a data description language and [de]serializer. It's mostly Haskell for code generation with a little bit of static Rust.

I finished rewriting my Metamath database verifier from Javascript into Rust; taking heavy advantage of lifetime-based memory management and "fearless concurrency", it's 14x faster than my Javascript version and 10x faster than the C reference implementation (the timing comparison in the OP is obsoletele, look downthread).

I've got Rust in production!

Image compression API for ImageOptim now uses my image encoder written in a mix of Rust & C.

I'm adding new code in Rust, but the existing C parts will probably stay until there's some semi-automated way to translate C syntax (not semantics) to Rust. I've converted some C parts to Rust, but just changing foo(int bar) to fn foo(bar: usize) was such a boring laborious and just-a-bit-too-complex for regex task, that I'm waiting until somebody writes a tool for this.

1 Like