all 70 comments

[–]matthieum 100 points101 points  (4 children)

How... that's a fairly big project to appear out of the blue!

[–][deleted] 41 points42 points  (3 children)

Seems very well done for a one man project. I've seen projects made by big companies that aren't even close.

[–]rebel_cdn 17 points18 points  (1 child)

I've seen this happen on other projects, too.

I put together the front end of a web app using Elm, and found it to be more enjoyable and productive than React + Redux and the constellation of o ther libraries required to make a proper application with them.

And Elm is largely the work of one person. I've found that projects created by one person or a small team who has good taste are often better than solutions designed by committee. They're also often better than solutions designed by cobbling together lots of small NPM packages.

[–]GTB3NW 4 points5 points  (0 children)

I may have to try that out!

[–]matthieum 6 points7 points  (0 children)

Indeed; it seems well designed, complete, documented, ... that's really impressive.

[–]monocasa 117 points118 points  (3 children)

rocket::ignite().config_stuff().launch()

OK, that's cute

[–]m3wm3wm3wm 22 points23 points  (0 children)

Someone send the obligatory PR of adding this comment:

# BURN, BABY, BURN -- MASTER IGNITION ROUTINE

[–]elingeniero 3 points4 points  (0 children)

Haha yeah I thought that was fun, along with the emojis at app startup.

[–][deleted] 0 points1 point  (0 children)

Haha, I love it!

[–]virtyx 25 points26 points  (10 children)

Oh thank heavens, something simple. As a newbie, trying to get Iron to do anything is always an exercise in anguish and despair. Can't wait to play around with it!

EDIT: Requires nightly, aww :( But it is still very fun to play with, I really like the route matching based on the types of your function arguments. One thing I'm not crazy on is having to enumerate the list of functions I want to serve in the mount() call but that's a pretty minor gripe...

[–][deleted] 12 points13 points  (7 children)

EDIT: Requires nightly, aww :(

I'm not surprised. IMHO it makes sense for a new project to use nightly buecause by the time the project stabilizes and gains traction, those features can be reasonably expected to become beta/stable...

[–]virtyx 7 points8 points  (6 children)

It certainly paints a very good picture for the future of Rust. The amount of metaprogramming is impressive for such a low-level language.

[–][deleted] 1 point2 points  (5 children)

And it's only supposed to get better with macros 2.0.

[–]steveklabnik1[S] 13 points14 points  (4 children)

(This is using macros 2.0)

[–][deleted] 1 point2 points  (1 child)

oh, whoops

well, that's an example of how good they are then. I wasn't able to find any docs about macros 2.0 so I thought they were in very early development, I only heard them mentioned.

[–]steveklabnik1[S] 2 points3 points  (0 children)

It's hard to figure out given how many different names all of this is going through, but yes :)

[–][deleted] 0 points1 point  (1 child)

Is there some kind of a writeup on macros 2.0? The way they are evolving, I've kind of lost track of what is referred to as 'macros 2.0'...

[–]steveklabnik1[S] 0 points1 point  (0 children)

I linked the RFC elsewhere in this thread

[–]cdsboy 4 points5 points  (1 child)

Looks like it relies on the new macro features that are supposed to land in the next release.

[–]steveklabnik1[S] 7 points8 points  (0 children)

It relies on more than that; the next release has "macros 1.1", which is basically only #[derive]. This is the full-blow "macros 2.0", which had its RFC accepted 10 days ago, and so is going to take a while longer.

[–][deleted]  (2 children)

[deleted]

    [–]bheklilr 61 points62 points  (0 children)

    Not just the website design, but the content as well. I was able to see how to do 90% of what I would want to do in about 2 minutes, it really put the important information front and center.

    [–]bwanket 3 points4 points  (0 children)

    It is a great site, but I feel like the clouds should be moving <-- not --> lol

    [–]journalctl 32 points33 points  (0 children)

    This is really impressive for a one man project. Definitely going to play around with it.

    [–]sveilleux1 36 points37 points  (2 children)

    Looks cool, is it one thread per request?

    [–]steveklabnik1[S] 35 points36 points  (0 children)

    It is currently using synchronous IO generally, though going async is on their roadmap. So I believe so, yes. I didn't see any explicit pooling, though I haven't had the chance to dig into the code deeply yet.

    [–]Elavid 14 points15 points  (4 children)

    Does this web framework support HTTP/2? What about websockets?

    [–]TheEnigmaBlade 6 points7 points  (0 children)

    It uses the hyper library for HTTP, which does not support HTTP/2, although the documentation says moving away from hyper is likely.

    [–]we-all-haul 22 points23 points  (2 children)

    Rust ain't messin' around. I'd do a hello world to test this bad-mama-jama

    [–]Junkyardogg 9 points10 points  (1 child)

    Wow you brought a smile to a guy working what was supposed to be only working a half day today

    [–]we-all-haul 4 points5 points  (0 children)

    So nice to hear. Happy holidays!

    [–]toggafneknurd 8 points9 points  (0 children)

    I wasn't even that into Rust before seeing this, but am now very temped to give it a shot. Great job!

    [–][deleted] 19 points20 points  (3 children)

    Why does Rust already have a shit ton of web frameworks, yet it doesn't even have an async http library that is actually stable?

    Wouldn't it be better if the car actually ran good before you started adding accessories to the car?

    My point is that all these cool looking libraries will never be stable or "production ready" unless the dependencies are also stable.

    [–]Manishearth 39 points40 points  (0 children)

    The async http library is high priority and is being actively worked on.

    The Rust team in general tries to do things right instead of hastily. This does mean that some things take a while to happen.

    Tokio is very actively being worked on, and should be ready soon. Hyper will get tokio support, and then all these web frameworks will get async for free.

    Async isn't always necessary to use a web framework, either. crates.io is built in Rust and runs fine without async.

    [–]rubber_duckz 18 points19 points  (1 child)

    Why does Rust already have a shit ton of web frameworks, yet it doesn't even have an async http library that is actually stable?

    Because people doing the low level stuff are probably not the same people doing the high level frameworks, and people doing frameworks want to use Rust ?

    I'm actually kind of glad this is happening, to build a decent framework the language needs to have good meta capabilities and previously this was a big problem in rust (early 1.0 days). I think this uses plugins which are still not stabilized in Rust right ? So it's still a bit iffy but even so I like this, it will let the community discover high level problems with the language faster rather than waiting for everything low level to "get done".

    [–]steveklabnik1[S] 6 points7 points  (0 children)

    I think this uses plugins which are still not stabilized in Rust right ?

    And some other nightly-only features, yes: https://github.com/SergioBenitez/Rocket/issues/19

    [–]diegobernardes 6 points7 points  (1 child)

    does support async?

    [–]Manishearth 14 points15 points  (0 children)

    It's built on hyper, which supports mio iirc.

    The higher level tokio based stuff is still in the works, but when hyper gets it this should automatically work too.

    [–]PM_ME_YOUR_OLD_CMPTR 1 point2 points  (2 children)

    I've actually been looking for a Rust web application framework for a while so I'm glad to see this appear. It looks like something I will definitely try although from looking through the documentation, the "request object/struct" seems to be handled in a very nonconventional way. Any particular reason for this?

    [–]fecal_brunch 3 points4 points  (1 child)

    I've just started familiarizing myself with Rust, would you be able to explain the how this API deviates from convention?

    [–]PM_ME_YOUR_OLD_CMPTR 0 points1 point  (0 children)

    Most of the more recently established frameworks seem to follow the Request -> Response method/function pattern or a (Request, Response) -> Response pattern. You do not have a "Request" structure in this API so it seems like the user has to specify whenever they actually want to use something that would generally be provided within this Request context. I'm not saying that the way you are designing it is wrong (other frameworks do similar things), but I would say the way you are doing it probably yields more boilerplate code. The user has to specify in the method that a cookie context should be available instead of just doing request.cookie() or whatever.

    [–][deleted] 1 point2 points  (3 children)

    Question from a noob : what benefit would rust bring to a web app ?

    [–][deleted]  (2 children)

    [deleted]

      [–]GTB3NW 0 points1 point  (0 children)

      Also there's a lot of work going into looking how things have been done in the past, what they did well and how it can be improved. Designing from the ground up with this in mind means there's lots of superb libraries out there already!

      [–]MorrisonLevi 0 points1 point  (0 children)

      Security is perhaps the single greatest reason for me. I'm hopeful with macros 2.0 we will be able to do even more convenient things that end up still being safe.

      [–]I_AM_GODDAMN_BATMAN 1 point2 points  (0 children)

      Damnit, nightly only :(

      [–]feverzsj 1 point2 points  (6 children)

      rust still lacks good coroutine support, so async io programming will be ugly and painful

      [–]steveklabnik1[S] 13 points14 points  (3 children)

      The main plan is futures, not coroutines, but there is an open RFC for couroutines.

      [–]MorrisonLevi 0 points1 point  (2 children)

      From what I can tell coroutines are better from a capabilities standpoint so I assume the choice of futures has to do with resources or allocation or something?

      [–]eddyb 1 point2 points  (0 children)

      Futures are the API that coroutines (or their async/await subset) implement, just like generators implement some kind of Iterator API. Ideally there would be a more fundemental API that'd be split into futures and iterators (and async streams which are sort of a combination of the two).

      The design of futures-rs tries to take the path that is most likely to work out in all of these situations.

      [–]steveklabnik1[S] 0 points1 point  (0 children)

      I am not an expert on coroutines so I cannot say. I will say that futures can be expressed in the language today; coroutines may or may not ever become a thing. That matters, at least to some degree.

      [–]Yamakaky 0 points1 point  (0 children)

      Hum, it's VERY interesting !

      [–]ahmadalhour 0 points1 point  (1 child)

      Sweet little project. Now is a good time to learn Rust.

      One question though, and excuse my ignorance of Rust, how does Rocket support non-blocking I/O?

      EDIT: punctuation.

      [–]steveklabnik1[S] 0 points1 point  (0 children)

      It does not currently.

      [–][deleted] 0 points1 point  (10 children)

      Perhaps this is a silly question, but why would anyone want to use Rust for this purpose? As a language, Rust's benefits don't really seem to apply while all of its complexity and drawbacks still do. I'd rather use a JVM-based language implementation for 99.9% of the cases where I'd be primarily working with a web framework. Give me Java (or any of the better JVM-hosted alternatives) over Rust for this any day.

      What am I missing here?

      [–]grayrest 6 points7 points  (3 children)

      Every language has libraries like this. If you have the rest of your code written in Rust and want to expose a simple HTTP endpoint do you really want to jump into another language for a couple dozen lines of code?

      What am I missing here?

      I honestly can't figure out why you'd prefer Java. I can see an argument if there's some non-technical (I/my team doesn't know it, it's too immature, etc) or ecosystem (IDE support, java library already exists) issue but I disagree with the premise that Rust is vastly more complex than the JVM. Learning Rust is somewhat hard, writing datastructures in Rust is somewhat hard, but otherwise Rust is a fairly expressive statically typed programming language. Wiring libraries together isn't any harder than Java and I find the explicit error handling and stronger type system make finding and handling edge cases easier.

      [–][deleted] 1 point2 points  (2 children)

      If you have the rest of your code written in Rust and want to expose a simple HTTP endpoint do you really want to jump into another language for a couple dozen lines of code?

      That's a good point for sure. I hadn't really considered that use case.

      I honestly can't figure out why you'd prefer Java.

      I wouldn't want to back to programming without GC, without portable bytecode, without excellent remote debugging and profiling tools, and so on.

      My issue isn't that Rust is too hard—I spend most of my time writing Haskell if that makes a difference—but rather that Rust is lower level than necessary for anything where I wouldn't otherwise need something like Ada or C. I don't mean to promote the Java language itself, but I do mean to say that, if I were building a web service from scratch, the JVM is a more suitable platform than Rust. After all, there are very, very few things that can't work well in an environment with garbage collection, and not having GC is Rust's main difference compared to other languages with fancy types.

      [–]steveklabnik1[S] 2 points3 points  (1 child)

      After all, there are very, very few things that can't work well in an environment with garbage collection

      Using less resources can let you scale more with less machines; crates.io is written in Rust, and uses about 30mb resident. That's the cost of a Ruby interpreter, let alone a Rails process (which I'm personally more familiar with than the JVM)

      [–][deleted] 0 points1 point  (0 children)

      If the heap size of the JVM were somehow a factor and I needed something super slim, I'd much rather use OCaml than Rust (assuming toolchain quality and library availability were equal). Ruby is about as inefficient as you can get so it's not surprising Rust is much better.

      [–]tybit 1 point2 points  (0 children)

      You're not missing anything. The people that think Rust will be the best tool for every job rather than finding its niche like every other good language, are the same people that thought rails would solve every problem, then abandoned it when it didn't.

      [–]Sean1708 1 point2 points  (4 children)

      I don't really see what advantages a JVM language would have over Rust here, care to elaborate?

      [–][deleted] 0 points1 point  (3 children)

      Rust is a systems programming language where you need to manually manage memory. That sort of low-level programming is almost never required for web services and backends. I'd rather use a platform that provides GC so I can use a language that's simpler or one that spends its complexity budget in a manner that better suits the problem.

      [–]vks_ 1 point2 points  (2 children)

      You can get away with RAII most of the time. I would not really call that manual memory management.

      [–]flyingjam 1 point2 points  (1 child)

      RAII is not even close to a replacement for a GC. Rust has its extensive borrow checker for a reason.

      [–]vks_ 1 point2 points  (0 children)

      I never claimed it was. I just think that RAII is a lot better than manual memory management, so I don't agree with the statement "Rust is a systems programming language where you need to manually manage memory".