Introducing Teepee: the next step for rust-http

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.

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.

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.

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.