
Show HN: Iron, a fast middleware-oriented Rust web server framework - jonreem
https://github.com/iron/iron
======
bhauer
I've been waiting to see some Rust frameworks emerge. Thanks for putting this
together!

Would you be willing to contribute a test implementation to our project [1]?

[1]
[http://www.techempower.com/benchmarks/#section=code](http://www.techempower.com/benchmarks/#section=code)

~~~
zzmp
This looks like a great resource!

Unfortunately, I'm not sure if anything in Rust should be considered
`production-ready` yet, and I haven't worked with any ORM wrappers in Rust
(yet).

I think we could get tests 1 and 6, if you'd be interested. I'll try to get to
those soon.

~~~
necaris
I might help out with this too -- I've been learning Rust recently and I
suspect this would help me get up to speed a bit more.

~~~
theptrk
That sounds great, find us anytime on the irc #iron if you want any advice or
input.

------
dawkins
"Iron averages 2500-3000+ requests per second for hello world"

For a hello world in my laptop I can get typically 30k requests with Go, and
with mono/httpListener ~10k.

I expected it to be much faster.

~~~
jonreem
The benchmarks are a bit lower than we wanted. I think this is mostly due to
an immature ecosystem for doing basic http - working off of c bindings to a
proven, fast framework would probably speed this up by a few times.

~~~
mercurial
By the way, something is up with the server serving the static doc. The link
to the docs is wrong, eg
[https://github.com/iron/router](https://github.com/iron/router) should link
to
[http://docs.ironframework.io/router/](http://docs.ironframework.io/router/),
instead of
[http://docs.ironframework.io/core/router](http://docs.ironframework.io/core/router).
To add insult to injury,
[http://docs.ironframework.io/core/router](http://docs.ironframework.io/core/router)
returns 200 with an empty body instead of 404.

That said, the framework itself looks interesting, though the 'iron/alloy/etc'
terminology is a little bit of an annoyance.

~~~
zzmp
Thanks for the heads up. We reworked our folder structure after writing the
READMEs, and it looks like we forgot to update. I'll get working on that.

The 200 is being served as the default of `rust-http`. Static will never serve
a 404 - it will only defer to the next middleware, and the docs server is
overly simple, so it just goes to default.

~~~
zzmp
This should be fixed. Thanks again.

------
zzmp
The Iron team is here. Feel free to ask us anything!

~~~
mercurial
Simple question. According to [1], middlewares are cloned for each request. Is
there a good built-in way of accessing shared mutable data, such as a
connection pool?

1:
[http://docs.ironframework.io/iron/trait.Middleware.html](http://docs.ironframework.io/iron/trait.Middleware.html)

~~~
jonreem
You are looking for
[https://github.com/iron/persistent](https://github.com/iron/persistent),
which offers two utility middleware for exactly this.

~~~
mercurial
Very nice, thanks.

------
wc-
This looks very nice. I've been following rust and go for a while now and I
finally have a small service to write that would be a good fit for either
language so I'm going to try both.

I noticed one of the repo's more recent issues was caused by a change
upstream. The upstream rust devs seem very accessible, but how often do you
encounter these kinds of breaking changes. Acknowledging that rust is pre-1.0,
is there any way to stay up to date on these kinds of changes before they hit
your app so you aren't blind sided?

~~~
zzmp
We see these changes every other day or so, but they're usually small syntax
changes, and the community's pretty quick to update.

A good way to stay up-to-date is always This Week In Rust, or /r/rust.

~~~
wc-
I know rust is pre-1.0 but wow that's a lot more breaking changes than I
expected...

~~~
steveklabnik
The rate of change slowed, but then, as we get closer to 1.0, the rate of
change has sped back up again. We need to break as many things as possible as
soon as possible, so that we can give the community some time to try it out
before we christen a 1.0 release. Does that make sense?

~~~
higherpurpose
Seems to me like you need at least a year before beginning to think about
releasing 1.0.

~~~
steveklabnik
Naw. The language itself is getting smaller and smaller over time. Most
breaking changes these days (though not all!) are in libraries, which have
individual stability markers, and the stability of the standard library
doesn't block 1.0.

A year is a very, very, very long time in software. Why do you suggest that
long? I'm curious.

~~~
andrewflnr
Possibly so of you break something in a bad way, you have time to find out,
break it again, and then make sure _that_ change is a good one.

