Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pencil: A Microframework Inspired by Flask for Rust

fengsp.github.io

Post reply on HN
Print view View original

41–50 of 58 posts

Re: Pencil: A Microframework Inspired by Flask for Rust

#41

Post by eridius »

steveklabnik wrote: post #27
maxcan wrote: post #16

Great start. Instead of numeric codes, perhaps use an enum for all the acceptable status codes? As Jane Street Says, make illegal state unrepresentable.

This is a good slogan, but there's some subtleties when it comes to HTTP status codes. That is, there are the defined ones, but any number is legit, so you end up with an enum with a member that's basically "anything we don't know about", so it's not as clear-cut as it is in other situations.

And of course a problem with this is any status code now has two representations: the canonical enum variant, and the catch-all variant with the same numeric value.

Re: Pencil: A Microframework Inspired by Flask for Rust

#42

Post by openasocket »

pcwalton wrote: post #37
openasocket wrote: post #24

Earlier quoted context omitted.

Go's networking library actually does call epoll/kqueue/etc on the backend, so it is using nonblocking io. Using nonblocking IO will provide better performance because it will increase the number of concurrent requests it can serve. It's not a silver bullet, and can be very difficult to implement at the application layer to avoid blocking, but it will give markedly better performance.

> Go's networking library actually does call epoll/kqueue/etc on the backend, so it is using nonblocking io. I know, of course. If you reread my comment, you'll notice that it wasn't focusing on the particular syscall that the system uses. > Using nonblocking IO will provide better performance because it will increase the number of concurrent requests it can serve. Because of (a), (b), and/or (c), which I addressed i…

Right, so Hyper would be faster if it used true asynchronous I/O, right? That was my whole point. I just brought up Go so I had something to compare it to.

Re: Pencil: A Microframework Inspired by Flask for Rust

#43

Post by f2f »

pcwalton wrote: post #38
openasocket wrote: post #33

Earlier quoted context omitted.

>But one of the reasons you're able to process more with async I/O is bypassing the costs of the thread-per-connection model. One reason, not the only, or the most important. The primary advantage of non blocking IO is that the CPU isn't sitting idle while waiting for an IO operation to complete. We aren't wasting an entire core to write the response.

That's not how blocking I/O works! Sitting in a busy loop on the CPU burning power polling the I/O device was, like, how the Apple II may have worked, but it hasn't worked like that on any major OS since at least 1990. Operating systems perform context switches on I/O.

> Operating systems perform context switches on I/O.

which are very cheap :)

Re: Pencil: A Microframework Inspired by Flask for Rust

#44

Post by f2f »

openasocket wrote: post #42
pcwalton wrote: post #37

Earlier quoted context omitted.

> Go's networking library actually does call epoll/kqueue/etc on the backend, so it is using nonblocking io. I know, of course. If you reread my comment, you'll notice that it wasn't focusing on the particular syscall that the system uses. > Using nonblocking IO will provide better performance because it will increase the number of concurrent requests it can serve. Because of (a), (b), and/or (c), which I addressed i…

Right, so Hyper would be faster if it used true asynchronous I/O, right? That was my whole point. I just brought up Go so I had something to compare it to.

Hyper may very well be much faster, but it isn't. Which is the whole issue with the Rust vs Go debates: one is possibly much better, but the other one gets all the code written for it in 1/6th of the time (Rust came out the same time Go did, to great fanfare).

Are we willing to wait 6x longer for rust to catch up? Some people are, most people aren't.

Re: Pencil: A Microframework Inspired by Flask for Rust

#45

Post by pcwalton »

f2f wrote: post #44
openasocket wrote: post #42

Earlier quoted context omitted.

Right, so Hyper would be faster if it used true asynchronous I/O, right? That was my whole point. I just brought up Go so I had something to compare it to.

Hyper may very well be much faster, but it isn't. Which is the whole issue with the Rust vs Go debates: one is possibly much better, but the other one gets all the code written for it in 1/6th of the time (Rust came out the same time Go did, to great fanfare). Are we willing to wait 6x longer for rust to catch up? Some people are, most people aren't.

I don't know whether you're talking about a 6x development speed differential or a 6x performance difference between Rust and Go HTTP stacks or what, but I am pretty sure that by making up numbers like that you're language warring for no reason.

Re: Pencil: A Microframework Inspired by Flask for Rust

#46

Post by pcwalton »

f2f wrote: post #43
pcwalton wrote: post #38

Earlier quoted context omitted.

That's not how blocking I/O works! Sitting in a busy loop on the CPU burning power polling the I/O device was, like, how the Apple II may have worked, but it hasn't worked like that on any major OS since at least 1990. Operating systems perform context switches on I/O.

> Operating systems perform context switches on I/O. which are very cheap :)

And if you accept that (which I'm not sure I do, but anyhow) then you accept that there isn't much difference between userspace M:N and blocking 1:1 threading.

Re: Pencil: A Microframework Inspired by Flask for Rust

#47

Post by f2f »

pcwalton wrote: post #45
f2f wrote: post #44

Earlier quoted context omitted.

Hyper may very well be much faster, but it isn't. Which is the whole issue with the Rust vs Go debates: one is possibly much better, but the other one gets all the code written for it in 1/6th of the time (Rust came out the same time Go did, to great fanfare). Are we willing to wait 6x longer for rust to catch up? Some people are, most people aren't.

I don't know whether you're talking about a 6x development speed differential or a 6x performance difference between Rust and Go HTTP stacks or what, but I am pretty sure that by making up numbers like that you're language warring for no reason.

yes, in this case i am language warring for no reason. i'm an unapologetic go devotee but i like rust just the same. i wish people would just get on with things and write software, rather than comment on minutiae on message boards.

Re: Pencil: A Microframework Inspired by Flask for Rust

#48

Post by sunng »

jdreaver wrote: post #5

I've found that whenever I start a small web project in a new language, I always look for the "Flask" of that language. I love using a framework that gives the bare essentials and nothing else. I don't use Rust, but your code examples look great! I understand that Rust has less opportunity for "magic" to clean things up (for example, in Python you can use a decorator to specify a route for a function), but otherwise…

> "gives the bare essentials and nothing else"

Rust is that thing exactly.

Re: Pencil: A Microframework Inspired by Flask for Rust

#49

Post by kibwen »

barosl wrote: post #19

Copying my comment on this from Reddit: 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…

For those reading, note that mitsuhiko did end up responding to this on Reddit: https://www.reddit.com/r/rust/comments/49jv81/introducing_pe...

Re: Pencil: A Microframework Inspired by Flask for Rust

#50

Post by Manishearth »

jdreaver wrote: post #5

I've found that whenever I start a small web project in a new language, I always look for the "Flask" of that language. I love using a framework that gives the bare essentials and nothing else. I don't use Rust, but your code examples look great! I understand that Rust has less opportunity for "magic" to clean things up (for example, in Python you can use a decorator to specify a route for a function), but otherwise…

You actually can use pythonish decorators in Rust, I wrote a proof of concept library for that: https://github.com/manishearth/rust-adorn (it's not really intended to be used, but if folks want to use it I'm willing to clean it up)
Post reply on HN