
Rust web framework, Iron - lding43
http://ironframework.io/
======
tinco
The first thought that should pop into your head is probably, why use this
instead of language XYZ, where XYZ is Ruby/Java/Python/Go. It's actually a
pretty interesting question because Rust is very much unlike those languages
in the sense that it's a true systems programming language like C/C++ are.

No one would (should!) ever consider writing a webservice in C++, simply
because it's unsafe to do so, it's much easier in other languages and the
performance downsides of those languages don't matter any way (i.e. Ruby
powers a bunch of high throughput websites yet it's notoriously 200x slower
than any other language).

But here comes Rust, it takes away the unsafety, arguably being even safer
than the managed languages in some aspects, is (in most aspects) easier to use
than C++ (coming close to the managed languages in ease of use), yet has
similar performance aspects (theoretically identical performance aspects) to
C/C++.

There's a web gateway in our cluster that receives binary blobs over REST and
puts them onto the message queue. In total not much over 100 lines of Ruby.
We've thought about reducing the server load a bit by porting it to Go or some
other more performant language. We probably wouldn't go for Rust, since Go is
simply easier to learn (should a new person ever have to perform maintenance).
Just the possibility of implementing it in Rust in roughly the same timespan
and code complexity while having a theoretically optimal performance is very
interesting.

~~~
pjmlp
I can write web services in Haskell, OCaml, .NET, Java, Ada, Delphi, D, Go.

All compile to native code and I don't have to fight with the borrow checker.

Rust needs a good story to be sold as alternative for web development.

We don't need system programming features in a web application. Unless maybe
when offering a web interface to an embedded device, instead of coding it in
C.

EDIT: Before the downvotes continue, I am not attacking Rust and feel it is
good that it also gets web frameworks.

The point being that for web development there are already better alternatives
and unless one needs Rust special language features, there isn't a compelling
reason to use it instead of the more mature alternatives which also make use
of native code.

~~~
pcwalton
The borrow checker also eliminates data races (and a variety of other bugs),
something that most of the other languages on your list do not. While avoiding
GC is probably the most prominent reason for the borrow check's existence, it
is not the only one. You shouldn't have to fight with it.

(Haskell in particular has a much more restrictive borrow checker than that of
Rust: purity.)

~~~
tinco
As a Haskell programmer I feel this isn't exactly true. Haskell's garbage
collector and referential transparency make immutability not really an issue.
Impure code is simply of a different type, so it's easy to avoid. What makes
dealing with the borrow check hard is that it triggers on code that
intuitively is correct, it can be hard to envision why it's not. I feel
Haskell does a better job at diverting you from incorrect code.

That said, dealing the borrow checker is just a skill. You take out a few
hours to learn to deal with it, and then you just can. As you said it's super
powerful and definitely your ally, so saying its a downside of Rust is
silliness.

~~~
pcwalton
> What makes dealing with the borrow check hard is that it triggers on code
> that intuitively is correct, it can be hard to envision why it's not.

Because it's more expressive than just forbidding mutability. You _could_
program in Rust the same way you program in Haskell, by encapsulating
mutability in functions with different types (&mut). Then the flow sensitivity
and other issues would never bother you.

Rust's flow-based control of mutability is strictly more expressive than the
monad system of Haskell. If you don't like that expressivity, don't use it.

------
jonreem
Main author of iron here, on mobile but happy to answer any questions.

Here's a link to the first chapter of an iron tutorial I've been working on,
which explains the "hello world" example in great detail and introduces some
of irons core abstractions:
[https://github.com/iron/byexample/blob/master/chapters/hello...](https://github.com/iron/byexample/blob/master/chapters/hello.md)

~~~
viraptor
Thanks for all the work on iron / hyper / web-related rust! You've done some
impressive amount of coding!

I was wondering what are your plans regarding iron-related extras. It seems
like logger, staticfile, and others are not updated as often as iron itself
(some fixes I noticed lately were PRs, staticfile fails on travis). Do you
have plans on how to expand iron in the future? Will you produce more basic
blocks yourself, or do you expect some community modules to start growing as
people use iron itself?

~~~
jonreem
I try to maintain and ensure the basic building blocks are usable and high
quality, but I am just one person, and there is much to do. There are several
other people associated with iron who also help with maintenance and feature
additions to the key packages under the iron organization, and they make
everything much much easier (thanks again!).

There are already some community crates that integrate with iron, providing
things like handlebars templating; I hope that as the community expands, more
third party crates will appear and make using iron even easier.

If anyone is interested in working on iron or wants to write a community crate
using it, you should reach out on the #iron channel on the Mozilla IRC
network. I and others hang out there and we can answer questions and provide
help.

------
steveklabnik
Crates.io uses Rust as a backend, Ember on the front. It uses about 35MB of
resident memory, and (other than some weird DNS issues that aren't the
server's fault) is just super rock solid. (It doesn't use Iron, though.)

I'm still not sure the application tier isn't best served by something that's
easier to prototype in, but if you already know Rust, the web stuff is shaping
up pretty nicely.

We also got Hyper, Iron, and Nickel entries into the Techempower benchmarks,
I'm really interested in seeing the eventual results.

~~~
viraptor
Just curious - what are you using on the backend? From-scratch rust code?

~~~
steveklabnik
[https://github.com/rust-lang/crates.io](https://github.com/rust-
lang/crates.io)

It uses 'conduit', which is a web framework that's basically only used by
crates.io, as far as I know.

~~~
jamwt
We use conduit at Dropbox as well, but mostly for PEP 333 type reasons
("universal" request/response types and a pluggable coupling layer between
handlers and servers.)

~~~
steveklabnik
Ah, neat! Thanks for filling me in. I almost never hear people talking about
it.

------
hammerdr
Warning: very little knowledge of Rust and Iron

Can someone explain why there is an extra Ok(...) in this? (I want to call it
a function, but I'm not even familiar enough with Rust to be sure that it is a
function).

Is it something that could be removed? Right now it just looks like
boilerplate.

Edit: Thanks everyone! Ok is similar to a Right or Success of a Either/Result
type of object.

~~~
viraptor
You mean in the handler? The return value has to be of a type
`IronResult<Response>`. That means it can be either `Ok(...)` for success or
`Err(...)` for failure.

In other languages/frameworks (python/pecan for example) you'd throw an
exception in case of things going wrong. In Rust exceptions are for very
exceptional things only (it's called panic). So the more calm way is just to
return `Err(...)`.

It's not a function, it's more like a tagged union (in rust called an enum).
So in practice it's like C's union, but you do know which member was chosen
and only that one is accessible.

~~~
GyrosOfWar
Small correction: Rust doesn't have exceptions. panic!() crashes the current
thread with an optional error message, but it doesn't do stack traces and
there's no try/catch in the language (there's the try!() macro, but it works
with Result<T, E> values, has nothing to do with panics).

~~~
heinrich5991
It records stack traces. Use the environment variable `RUST_BACKTRACE=1` to
print them.

------
ejcx
Every time I see new languages and frameworks being used for web applications
I get scared.

One reason I am super gung-ho about Golang for an API or website, is it came
with the net httplistener package, html/template package, and has several
fairly well made open source packages (and standard packages) for secure
sessions, CSRF tokens, output filtering, shelling out, so much more...

Without these types of features, people are doomed to build web-apps no more
secure than everyone's first, broken, PHP webapp.

I'm not sure what the purpose of a truly system's oriented back-end is similar
to this[0], it kinda of scares me. Some have mentioned for embedded systems. I
don't know if people are using rust in embedded systems yet. But please be
aware of just how wild-west writing a full webapp or API with this would be.

[0] -
[http://www.gnu.org/software/libmicrohttpd/](http://www.gnu.org/software/libmicrohttpd/)

~~~
pcwalton
All of the features you mentioned have Rust equivalents in the crates.io
ecosystem. So what in particular do you prefer about Go?

~~~
viraptor
What's the CSRF library? I couldn't find one on crates.

~~~
pcwalton
Yeah, I guess crates.io is missing that one. It should be straightforward to
write though.

