Introducing Teepee: the next step for rust-http

http://chrismorgan.info/blog/introducing-teepee.html

by chrismorgan • 12 years ago

43 10 12 years ago

mwcampbell• 12 years ago

Glad to see someone putting in some effort to create a well-designed, versatile HTTP library for Rust. I hope it takes off, and that Rust becomes a viable language for developing HTTP-based services that are both safe and efficient.

onedognight• 12 years ago

A separate project is pointless. Just break the old one. Rust doesn't need your old version. And git has it for anyone that does in the interim.

chrismorgan2• 12 years ago

Given that it is a complete rewrite, breaking rust-http is an unnecessary evil; people are using rust-http successfully and I see no reason to cause them unnecessary trouble. Until Teepee's HTTP client and server are ready, rust-http will be maintained so that it can still run on Rust master, though it will not be developed any further; Rust does need the "old version" for now.

gtaylor• 12 years ago

Seems like rust-http 2.x would work for this purpose. It's subjectively a much more descriptive name than "Teepee", too.

riquito• 12 years ago

To the OP: did you write http libraries in other languages or rust-http is your first experience?

chrismorgan2• 12 years ago

I had worked in raw HTTP before with a bit of parsing, but rust-http was my first experience actually implementing a proper HTTP library.

JPKab• 12 years ago

From the perspective of a person who wants to invest time in the near future to learning a highly performant systems language, I'm having a hard time deciding between Go and Rust.

Any thoughts on the matter here? Obviously there's going to be a lot of learning material for Go courtesy of its stability and age, but I get the feeling that Rust is Go without the warts.

pohl• 12 years ago

One question you could ask yourself that may help clarify your choice is what precisely do you want the phrase "systems language" to imply?

Both the very first question in the official Go FAQ and the front page of the Rust site use the phrases "systems language" and "systems programming language" respectively, but one could argue that they are not both referring to the same idea.

aaronblohowiak• 12 years ago

Which warts?

For this discussion, let's ignore the current state of Rust's maturity and ecosystem on faith that they will at least rival Go's.

They are both compelling offerings that can (in capable hands) deliver performance that you cannot get out of a Ruby/Python/JS for CPU-bound tasks. They also both offer strategies for parallelism and concurrency that embrace modern hardware. Neither offers a Erlang/OTP-level distributed fault-tolerance. They both have closures and the ability to decouple interface from implementation. They both offer signed/unsigned ints/floats of multiple sizes. They both have fixed and variable sized vector implementations.

I suggest that you pick the language that matches your philosophy.

Go is simple on purpose, and comes with a robust and opinionated standard library. Rust is sophisticated and has many options for developers.

Go is very much like a garbage-collected memory-safe C with type inference, lightweight threads and a thread-safe message queue datatype built in. Rust is more like if someone took modern C++, baked support for advanced pointer types into the syntax of the language, and made the compiler aware of their implications.

Go leaves thread safety to the user and does not have a robust notion of const or immutability. Conceptually, everything in Go is garbage collected (the compiler is smart about stack vs heap allocation through static escape analysis and there are tools that help you to identify when things actually get heap allocated if you need to avoid that for performance reasons.) Rust has a type system where immutability is a first-class concept and has rules about how a parent object's im/mutability transfers to its sub-objects. In rust, there are a few different choices for lifecycle management including linear typing (unique pointers,) reference counted and garbage collected. In rust, refcounted and gc'd variables may not be shared across threads. http://cosmic.mearie.org/2014/01/periodic-table-of-rust-type...

Go does not have a destructor, per se (there is a thing you can do that can run when something is gc'd, but you shouldn't do this in most cases). Rust has destructors. Neither have constructors.

Go has "duck typing" interfaces -- if an object implements all the methods in an interface, then it implicitly implements that interface. Rust has generics and parameterized types. Implementing interfaces in Rust is explicit.

This is an abbreviated and hopefully mostly-accurate overview of the differences in the languages that reflect the differences in the language philosophies. Go is simple, Rust is sophisticated. If you think having type-parameterized interfaces is an important thing for a language to have, you'll probably prefer Rust. If you think generics are more trouble than they are worth as long as you have interfaces, you'll probably prefer Go.

I presently write production systems in Go and Ruby, and will probably look more into rust when they stop making breaking changes to the language.

616c• 12 years ago

More strong work from the inner circle of Rust devs. Cool work Chris!

Introducing Teepee: the next step for rust-http

Related Stories