11–20 of 58 posts
That looks so simple . Even simple enough for embedded systems. I like it! Maybe I need to look at Flask, too.
Very nice and readable. What are the plans for this? Anyone share to comment if there is a development roadmap or if its just an exercise in programming.
It looks like it's a bit of a pet project at the moment, but these sorts of things have a habit of taking off in a big way sometimes. Probably a big "it depends".
That said, I've been very happy with Iron thus far.
That looks so simple . Even simple enough for embedded systems. I like it! Maybe I need to look at Flask, too.
Flask is my favorite tool for writing web apps in python. Django is nice, but I like the idea of building a framework up around the application, instead of shoehorning an application into a framework, and Flask lets you only bring in the parts you need.
As Jane Street Says, make illegal state unrepresentable.
Very nice and readable. What are the plans for this? Anyone share to comment if there is a development roadmap or if its just an exercise in programming.
https://github.com/fengsp/pencil/graphs/contributors It looks like it's a bit of a pet project at the moment, but these sorts of things have a habit of taking off in a big way sometimes. Probably a big "it depends".
Anyone know of any benchmarks? This seems to be built on top of hyper. I remember checking out hyper a couple months ago and being disappointed with its performance. Last I checked it was using synchronous IO, and was performing about an order of magnitude worse than equivalent Go. That could certainly change, but I'm hesitant to use Rust for an HTTP server like I would with Go until I see better performance.
The primary difference between async and synchronous I/O is (a) better memory usage due to not having a stack per connection; (b) you can avoid the overhead of context switches to wake up an I/O thread; (c) thread spawning performance is faster due to the kernel not having to be involved. Golang's advantages in (a) and (b) are much less than what is typically thought of as "async I/O", because it still semantically uses a thread-per-connection and so is performing the same operations that a synchronous I/O implementation performs, just with a different implementation strategy.
Great, I'll definitely have to try this! I've used several Rust web frameworks, including Iron[1], Nickel[2], and Rustful[3]. Each of them has their own strengths and weaknesses, so I've been launching new web sites using all of them to see what fits me best. (Until now, Rustful felt the most comfortable. But I like the others too!) Now I have one more thing to evaluate!
Before diving into this, one thing that caught me at a glance is the order of the arguments in the routing rules. It is using `/user/`, but I think `/user/` is more natural. A small difference, but I believe this is one thing that Bottle[4] did right. When types come later, it is easier to omit them if there's a default (e.g. `` has the same meaning as ``) and it is also consistent with the existing type annotation syntax of Rust. I suspect Flask uses the current order only because of the backward compatibility concerns. But only mitsuhiko can tell for sure.
Also, it would be great if `ViewFunc` is extended to accept the functions other than the ones returning `Result`, e.g. `Result` and `Result, _>`. It is true that there exist the `From` implementations in `Response`, but it is generally more convenient to return `String` directly from the handlers rather than manually forming `Response::from("...")`. I think I can prepare a PR if you like!
Thanks again for another attempt to use Rust as a web language!
I would love to see how Rust will influence the web development sphere and I'd like to see if it would cut down on some common bugs that are made in production web development.