4 ms·

Well done! I'm generally against shoehorning languages into environments where they don't belong, but I can't wait to try using Rust for webdev.

by izolate 11y ago

steveklabnik 11y ago
You might enjoy http://arewewebyet.com/ http://arewewebyet.com/
- 15155 11y ago
  No mention of non-blocking IO or a concurrency model that isn't 1:1 with OS threads. What's the plan on those fronts if they won't be in 1.0?
  - steveklabnik 11y ago
    That they'll be coming in later releases. IO is a library concern in Rust, not a language concern. There are already crates that offer some of this, like mio.
    - tormeh 11y ago
      >x is a library concern in y, not a language concern. The end user doesn't really care. The line between the standard library and the language is usually invisible.
    - 15155 11y ago
      > IO is a library concern in Rust, not a language concern. It often is a language concern: no async/await in the compiler or language-assisted yielding/scheduling means difficult or impossible concurrency model. With Rust's borrow checker, IO (already unsafe C FFI) + callbacks are hard to write in a pleasing and safe way.
  - lambda 11y ago
    You're right, that site should be updated with those as other parts of the ecosystem that aren't yet mature. There's work on non-blocking IO at https://github.com/carllerche/mio https://github.com/carllerche/mio, which is looking like one of the more promising approaches, as well as https://github.com/carllerche/eventual https://github.com/carllerche/eventual which provides higher-level abstractions over it. There has been some discussion of adding some language support for something like async/await/yield from other languages, but nothing concrete in the near future on the language front. So, there's usable third-party libraries for it (at least, if you're on a Unix like platform), language support is in the realm of "it would be nice someday".
- dfabulich 11y ago
  What's the deal with compiling Rust to JS? (That's not discussed on the website.)
  - steveklabnik 11y ago
    Some people have gotten emscripten working, even with graphics and stuff: http://bl.ocks.org/AerialX/1041460cb9dd5876658c http://bl.ocks.org/AerialX/1041460cb9dd5876658c My remembering is that it uses a different LLVM version than we use, which is very cutting-edge. So we need them to update before it works well.
bpicolo 11y ago
As someone who tried it for a bit, it really is not the right use case. : P
mahyarm 11y ago
With the large box flexibility you get with webdev, I don't know why you would want to use it except for specialized parts. Like a RAW -> jpg transcoder.
- steveklabnik 11y ago
  One reason: really, really low resource usage. Crates.io is reasonably complex, linking to libgit and such, and still uses roughly 25MB of RAM, constant. A Ruby process is ~30 MB off the bat last I checked, and Rails, well...
  - mahyarm 11y ago
    But how does it compare to go in this case?
    - steveklabnik 11y ago
      I don't really program in Go, maybe someone who does can chime in. I'm not aware of any sort of recent direct comparison in this area.
    - hobofan 11y ago
      Haven't made any direct comparisons (and that would be hard) but from my experience from working with both I would say that you probably won't notice a big difference in RAM usage (< 10% difference).
- akavlie 11y ago
  Web library maturity aside, is the language inherently less suitable for webdev than Go?
  - mahyarm 11y ago
    Not really suitable, more from a dev speed perspective vs Go. You have a GC for example, and the opinionated nature makes managing a large code base better. Also a GC pause isn't a big deal for web apps as far as I know. A reason why I would choose Rust possibly is because you can prevent data races although with it's memory management model.
parley 11y ago
I've been porting some JSON/HTTP API servers from Go to Rust recently, and it's been a really nice experience. Rust has convenient struct serialization just like Go, and Hyper is coming along as a nice (relatively) low-level HTTP library. If you want a higher abstraction HTTP server, go with Iron that builds on Hyper. The I/O libraries have more work to be done (mostly for the async story), but they're ok for now and the plans I can see look promising. I see a bright future for those of us who like to write robust and high performing API servers, so don't shy away from Rust in that domain! EDIT: Forgot to say that everyone's very friendly in #rust-webdev where Hyper/Iron authors and others can be found.

Well done! I'm generally against shoehorning languages into environments where they don't belong, but I can't wait to try using Rust for webdev.

by izolate 11y ago

Well done! I'm generally against shoehorning languages into environments where they don't belong, but I can't wait to try using Rust for webdev.

steveklabnik 11y ago

You might enjoy http://arewewebyet.com/ http://arewewebyet.com/

15155 11y ago
No mention of non-blocking IO or a concurrency model that isn't 1:1 with OS threads. What's the plan on those fronts if they won't be in 1.0?
- steveklabnik 11y ago
  That they'll be coming in later releases. IO is a library concern in Rust, not a language concern. There are already crates that offer some of this, like mio.
  - tormeh 11y ago
    >x is a library concern in y, not a language concern. The end user doesn't really care. The line between the standard library and the language is usually invisible.
  - 15155 11y ago
    > IO is a library concern in Rust, not a language concern. It often is a language concern: no async/await in the compiler or language-assisted yielding/scheduling means difficult or impossible concurrency model. With Rust's borrow checker, IO (already unsafe C FFI) + callbacks are hard to write in a pleasing and safe way.
- lambda 11y ago
  You're right, that site should be updated with those as other parts of the ecosystem that aren't yet mature. There's work on non-blocking IO at https://github.com/carllerche/mio https://github.com/carllerche/mio, which is looking like one of the more promising approaches, as well as https://github.com/carllerche/eventual https://github.com/carllerche/eventual which provides higher-level abstractions over it. There has been some discussion of adding some language support for something like async/await/yield from other languages, but nothing concrete in the near future on the language front. So, there's usable third-party libraries for it (at least, if you're on a Unix like platform), language support is in the realm of "it would be nice someday".
dfabulich 11y ago
What's the deal with compiling Rust to JS? (That's not discussed on the website.)
- steveklabnik 11y ago
  Some people have gotten emscripten working, even with graphics and stuff: http://bl.ocks.org/AerialX/1041460cb9dd5876658c http://bl.ocks.org/AerialX/1041460cb9dd5876658c My remembering is that it uses a different LLVM version than we use, which is very cutting-edge. So we need them to update before it works well.

bpicolo 11y ago

As someone who tried it for a bit, it really is not the right use case. : P

mahyarm 11y ago

With the large box flexibility you get with webdev, I don't know why you would want to use it except for specialized parts. Like a RAW -> jpg transcoder.

steveklabnik 11y ago
One reason: really, really low resource usage. Crates.io is reasonably complex, linking to libgit and such, and still uses roughly 25MB of RAM, constant. A Ruby process is ~30 MB off the bat last I checked, and Rails, well...
- mahyarm 11y ago
  But how does it compare to go in this case?
  - steveklabnik 11y ago
    I don't really program in Go, maybe someone who does can chime in. I'm not aware of any sort of recent direct comparison in this area.
  - hobofan 11y ago
    Haven't made any direct comparisons (and that would be hard) but from my experience from working with both I would say that you probably won't notice a big difference in RAM usage (< 10% difference).
akavlie 11y ago
Web library maturity aside, is the language inherently less suitable for webdev than Go?
- mahyarm 11y ago
  Not really suitable, more from a dev speed perspective vs Go. You have a GC for example, and the opinionated nature makes managing a large code base better. Also a GC pause isn't a big deal for web apps as far as I know. A reason why I would choose Rust possibly is because you can prevent data races although with it's memory management model.

parley 11y ago

I've been porting some JSON/HTTP API servers from Go to Rust recently, and it's been a really nice experience. Rust has convenient struct serialization just like Go, and Hyper is coming along as a nice (relatively) low-level HTTP library. If you want a higher abstraction HTTP server, go with Iron that builds on Hyper. The I/O libraries have more work to be done (mostly for the async story), but they're ok for now and the plans I can see look promising. I see a bright future for those of us who like to write robust and high performing API servers, so don't shy away from Rust in that domain! EDIT: Forgot to say that everyone's very friendly in #rust-webdev where Hyper/Iron authors and others can be found.