4 ms·

I've only started to investigate rust for server side programming ( websocket in particular) but saw many discussions about the limitations rust has regarding p

by bsaul 12y ago

I've only started to investigate rust for server side programming ( websocket in particular) but saw many discussions about the limitations rust has regarding parallel programming. Yet, iirc servo did parallel rendering of html page, so that seems a contradiction. Anyone here knows about that ? Specifically, i'm currently hesitating between golang and rust for coding a small Websocket chat server. I'm ready to use beta code because rust seems more promising to me in the long term than golang, but not if the language itself has severe fundamental limitations on server side programming.

m0th87 12y ago
Depends on the kinds of parallelism you want. Rust has built-in support for parallelization, but tasks are mapped 1:1 to threads. Currently M:N threading is also supported, but that will be removed. Consequently, applications requiring lots of tasks (including highly-concurrent websocket servers) won't do well with the built-in mechanism. Context: https://news.ycombinator.com/item?id=8459888 https://news.ycombinator.com/item?id=8459888
- rictic 12y ago
  Green threads (M:N) do seem to be available as a library though: http://doc.rust-lang.org/green/ http://doc.rust-lang.org/green/
  - m0th87 12y ago
    That too is being removed: https://github.com/rust-lang/rfcs/pull/230 https://github.com/rust-lang/rfcs/pull/230
    - adrusi 12y ago
      Its being removed from the standard library. As I understand it will still be maintained as a separate library.
    - joelthelion 12y ago
      It's not being removed, it's being moved from the core of the language to an external library.
  - cmrx64 12y ago
    Their new resting place: https://github.com/alexcrichton/green-rs https://github.com/alexcrichton/green-rs
- higherpurpose 12y ago
  Sounds like Go is better for web servers because of better concurrency support for millions of users, while Rust is better suited for desktop apps that take advantage of all the PC's cores?
  - fread2281 12y ago
    If you want true lightweight threads, you need haskell or erlang.
  - carllerche 12y ago
    Actually, Rust is much closer to the system than Go is making it possible to implement lighter weight web services using Rust than Go. Rust features like not having a GC allows for much more predictable performance. Go's concurrency features are nice if it's your kind of thing, but will get in your way when hitting that "last mile" of performance. For example, if you were to implement something like haproxy, you would probably want to use Rust over Go for performance.
- tormeh 12y ago
  Can someone explain me why that is? It just seems like it is the dumbest thing in the world to me. The OS may be good at scheduling, but why not have a built in library providing you with an alternative? Native threads are usually really slow to start and stop, because they have high memory use and even modern OSs can only handle on the order of 10000 of them. When I saw this decision my first reaction was "Well, that was a promising language. Shame about that." I can't be the only one...
  - steveklabnik 12y ago
    A systems programming language without access to a systems feature isn't much of a systems language. Also, it doesn't _preclude_ green threads. As others have mentioned, Rust is low-level enough that all of this is a library issue, not a language issue. You can write whatever concurrency primitives you need, and they'll be no less privileged as the ones the standard library gives you.
    - tormeh 12y ago
      Well, yes, but anything that's merely a convenience and not in the standard library won't see much use, as I've understood programmer nature.
      - steveklabnik 12y ago
        Rust's standard library will be much less privileged than in other languages, due to Cargo existing from the start. It's going to be much more slim than most, we've already pulled lots of things out into their own packages. Also, given that only part of the standard library will be stable at 1.0.
  - Jweb_Guru 12y ago
    This is actually not the case on Linux. Starting up a thread is really fast. One of Rust's contributors found that it was just as fast at spawning threads as Rust was at spawning green threads when both were pinned to one core. Additionally, for a variety of reasons Rust's tasks were not smaller than OS threads, because they need to be bigger for a lot of things (calling into C, for example) and segmented stacks were found to be much too slow. Go gets around these problems by allocating a new stack when the current one runs out of space, but doing that properly requires being able to trace all the pointers into the stack to figure out where to transfer them--in other words, it requires a garbage collector :) So that solution wasn't really viable for Rust. Finally, having to support both concurrency models required Rust to make significant sacrifices in its libraries, in both complexity and performance. Go was able to make the decision to focus entirely on green threading, but Rust did not take that approach, so it was stuck in a "worst of both worlds" situation. It is possible that there is a better solution that avoids all these problems, but it will have to be found outside the main Rust tree.
deleted 12y ago
[deleted]
bhauer 12y ago
Although not directly related to your use-case, I wanted to mention that we received a pull request [1] implementing a test of the Iron framework. Expect to see this in Round 10 of our framework benchmarks project. [1] https://github.com/TechEmpower/FrameworkBenchmarks/pull/1101 https://github.com/TechEmpower/FrameworkBenchmarks/pull/1101
rubiquity 12y ago
Parallel rendering of an HTML page means an improvement of one renderer to 2 or more renderers. Writing a web server means possibly handling thousands to millions of concurrent requests, which isn't really doable with Rusts 1:1 threading model. But the reality of concurrency and hardware is that all we have at the end of the day are threads anyway. So in Rust you could have a thread running an event-loop that serves your web sockets. People are building these sorts of abstractions for Rust but they are a work in progress as far as I know. MIO[0] is one such example. Rust is a programming language for systems programming and "server side programming" is just a subset of systems programming. 0 - https://github.com/carllerche/mio https://github.com/carllerche/mio
- bsaul 12y ago
  Thanks for your enlightening response. Wouldn't building event loop based server require non-blocking i/o libraries ? Does rust have that ?
  - rubiquity 12y ago
    To the best of my knowledge Rust's stdlib doesn't have non-blocking libraries yet. But since Rust is "close to the metal" you can easily use any of the non-blocking system calls in glibc. Mio (https://github.com/carllerche/mio#features https://github.com/carllerche/mio#features) seems to be doing just that.
  - kxo 12y ago
    That's exactly what they require. mio is one such example, I am working on another implementation.

by bsaul 12y ago

m0th87 12y ago

Depends on the kinds of parallelism you want. Rust has built-in support for parallelization, but tasks are mapped 1:1 to threads. Currently M:N threading is also supported, but that will be removed. Consequently, applications requiring lots of tasks (including highly-concurrent websocket servers) won't do well with the built-in mechanism. Context: https://news.ycombinator.com/item?id=8459888 https://news.ycombinator.com/item?id=8459888

rictic 12y ago
Green threads (M:N) do seem to be available as a library though: http://doc.rust-lang.org/green/ http://doc.rust-lang.org/green/
- m0th87 12y ago
  That too is being removed: https://github.com/rust-lang/rfcs/pull/230 https://github.com/rust-lang/rfcs/pull/230
  - adrusi 12y ago
    Its being removed from the standard library. As I understand it will still be maintained as a separate library.
  - joelthelion 12y ago
    It's not being removed, it's being moved from the core of the language to an external library.
- cmrx64 12y ago
  Their new resting place: https://github.com/alexcrichton/green-rs https://github.com/alexcrichton/green-rs
higherpurpose 12y ago
Sounds like Go is better for web servers because of better concurrency support for millions of users, while Rust is better suited for desktop apps that take advantage of all the PC's cores?
- fread2281 12y ago
  If you want true lightweight threads, you need haskell or erlang.
- carllerche 12y ago
  Actually, Rust is much closer to the system than Go is making it possible to implement lighter weight web services using Rust than Go. Rust features like not having a GC allows for much more predictable performance. Go's concurrency features are nice if it's your kind of thing, but will get in your way when hitting that "last mile" of performance. For example, if you were to implement something like haproxy, you would probably want to use Rust over Go for performance.
tormeh 12y ago
Can someone explain me why that is? It just seems like it is the dumbest thing in the world to me. The OS may be good at scheduling, but why not have a built in library providing you with an alternative? Native threads are usually really slow to start and stop, because they have high memory use and even modern OSs can only handle on the order of 10000 of them. When I saw this decision my first reaction was "Well, that was a promising language. Shame about that." I can't be the only one...
- steveklabnik 12y ago
  A systems programming language without access to a systems feature isn't much of a systems language. Also, it doesn't _preclude_ green threads. As others have mentioned, Rust is low-level enough that all of this is a library issue, not a language issue. You can write whatever concurrency primitives you need, and they'll be no less privileged as the ones the standard library gives you.
  - tormeh 12y ago
    Well, yes, but anything that's merely a convenience and not in the standard library won't see much use, as I've understood programmer nature.
    - steveklabnik 12y ago
      Rust's standard library will be much less privileged than in other languages, due to Cargo existing from the start. It's going to be much more slim than most, we've already pulled lots of things out into their own packages. Also, given that only part of the standard library will be stable at 1.0.
- Jweb_Guru 12y ago
  This is actually not the case on Linux. Starting up a thread is really fast. One of Rust's contributors found that it was just as fast at spawning threads as Rust was at spawning green threads when both were pinned to one core. Additionally, for a variety of reasons Rust's tasks were not smaller than OS threads, because they need to be bigger for a lot of things (calling into C, for example) and segmented stacks were found to be much too slow. Go gets around these problems by allocating a new stack when the current one runs out of space, but doing that properly requires being able to trace all the pointers into the stack to figure out where to transfer them--in other words, it requires a garbage collector :) So that solution wasn't really viable for Rust. Finally, having to support both concurrency models required Rust to make significant sacrifices in its libraries, in both complexity and performance. Go was able to make the decision to focus entirely on green threading, but Rust did not take that approach, so it was stuck in a "worst of both worlds" situation. It is possible that there is a better solution that avoids all these problems, but it will have to be found outside the main Rust tree.

deleted 12y ago

[deleted]

bhauer 12y ago

Although not directly related to your use-case, I wanted to mention that we received a pull request [1] implementing a test of the Iron framework. Expect to see this in Round 10 of our framework benchmarks project. [1] https://github.com/TechEmpower/FrameworkBenchmarks/pull/1101 https://github.com/TechEmpower/FrameworkBenchmarks/pull/1101

rubiquity 12y ago

Parallel rendering of an HTML page means an improvement of one renderer to 2 or more renderers. Writing a web server means possibly handling thousands to millions of concurrent requests, which isn't really doable with Rusts 1:1 threading model. But the reality of concurrency and hardware is that all we have at the end of the day are threads anyway. So in Rust you could have a thread running an event-loop that serves your web sockets. People are building these sorts of abstractions for Rust but they are a work in progress as far as I know. MIO[0] is one such example. Rust is a programming language for systems programming and "server side programming" is just a subset of systems programming. 0 - https://github.com/carllerche/mio https://github.com/carllerche/mio

bsaul 12y ago
Thanks for your enlightening response. Wouldn't building event loop based server require non-blocking i/o libraries ? Does rust have that ?
- rubiquity 12y ago
  To the best of my knowledge Rust's stdlib doesn't have non-blocking libraries yet. But since Rust is "close to the metal" you can easily use any of the non-blocking system calls in glibc. Mio (https://github.com/carllerche/mio#features https://github.com/carllerche/mio#features) seems to be doing just that.
- kxo 12y ago
  That's exactly what they require. mio is one such example, I am working on another implementation.