18 ms·

Can't wait to try out Rust on sever though. I'd like to have compiled, performant, small footprint and simple http REST server written in language that is not G

Can't wait to try out Rust on sever though. I'd like to have compiled, performant, small footprint and simple http REST server written in language that is not Go or Haskel. EDIT: I said not Go, because I don't like its type system, and whenever I have to cast something to interface I have a strong flashback from the old Java 1.3 days. On the other hand. It's purely personal opinion.

nkozyra 12y ago
Since Go will gladly handle said requirements, is this last point simply arbitrary? As Go and Rust share a lot of similarities, what is it about Go that's so unappealing for this use case?
- eudox 12y ago
  The type system?
  - nkozyra 12y ago
    The type system doesn't preclude any of the requirements he listed (other than it simply not being Go)
- twic 12y ago
  Do Go and Rust share a lot of similarities? Apart from compiling into native code and being relatively new, what? It seems to me that Go and Rust are much more different than alike. Go has GC, Rust has lifetimes. Go has a simplistic type system, Rust has a sophisticated one. Go allows shared mutable state, Rust does not. These are pretty deep differences.
  - 1ris 12y ago
    Both implement the the CSP concurrency model, for example. Both have a C-like syntax. They are both object-oriented, but very different in that from java/c++/.net.
- deleted 12y ago
  [deleted]
VeejayRampay 12y ago
Out of curiosity, why is it that you wouldn't want Go for such a task? Is it the lack of maturity, dislike for the language itself?
- Ygg2 12y ago
  Probably the GC. Rust once finished and proved should be safe for concurrent usage AND without GC cleanup. That's a major feat of engineering.
  - matthewmacleod 12y ago
    That's a major feat of engineering Absolutely, but it's not a reason to not use Go. The web is probably the platform with the least possible damage caused by GC. It's OK if people like the language and want to use it for web development, though. I'm personally pretty excited about it, because I'm not a huge fan of Go and Rust looks pretty neat.
  - nkozyra 12y ago
    "On the topic of performance, keep in mind that Go gives the programmer considerable control over memory layout and allocation, much more than is typical in garbage-collected languages. A careful programmer can reduce the garbage collection overhead dramatically by using the language well; see the article about profiling Go programs for a worked example, including a demonstration of Go's profiling tools." And "The current implementation is a parallel mark-and-sweep collector but a future version might take a different approach." (which I'm certain it will) http://golang.org/doc/faq#garbage_collection http://golang.org/doc/faq#garbage_collection
    - pcwalton 12y ago
      > On the topic of performance, keep in mind that Go gives the programmer considerable control over memory layout and allocation, much more than is typical in garbage-collected languages. That's true (although I would question the use of "allocation" there—I think Java has as much control over when you allocate as Go does), but "some control" is not always enough control.
Ygg2 12y ago
If I remember Rust binaries, due to default static linking end up rather large. There is work to remove all unnecessary things from libstd into other libraries. That said, I can't wait for rust teepee server to land, it shapes up to be a rather interesting project.
- chrismorgan 12y ago
  The binary is large, but the memory footprint small. And the startup time is small, too… servers that start up in under five milliseconds—delightful for me, with my Django background.
- jff 12y ago
  Compare the footprint of your single static binary to a python program + the appropriate python 2.7.whatever & specific library versions which must be shipped with the program since odds are the user doesn't have the right version installed...
- eridius 12y ago
  Dynamic linking cuts the binary size down considerably, but of course it requires the Rust libraries to be installed on the machine. You can also turn on LTO for even more savings.
b0b_d0e 12y ago
For some reason, no one has mentioned that there is a very usable rust REST framework right now that you can try out https://github.com/Ogeon/rustful https://github.com/Ogeon/rustful I'm not the author of this, so I can't tell you what features are missing, but the features that are there work very well from what I can tell. When it comes to web frameworks in Rust, there aren't many options yet (as stated in are we web yet) but the few that are out there are in active development.
- steveklabnik 12y ago
  > For some reason Discovery of Rust projects is super hard right now. I'm quite into both REST and Rust and didn't know about your framework :/
  - b0b_d0e 12y ago
    > Discovery of Rust projects is super hard right now. Good point! But I'm not sure of any other way to get projects noticed besides word of mouth and posting about them on sites like Hacker news and such. In fact that is where I first heard about rustful. > didn't know about your framework My framework is actually at https://github.com/jroweboy/oxidize/tree/incoming https://github.com/jroweboy/oxidize/tree/incoming (master branch is sorely out of date) and I feel I still have a long way to go before I get that finished :)
- drbawb 12y ago
  I'm happily using the ZeroMQ bindings to serve an HTTP and WebSocket service w/ Mongrel2 servicing requests and Rust providing the handlers. Not a pure Rust stack, but it does a very admirable job serving responses for such a young language. (I also love have fallen in love w/ how mongrel2 handles websockets. I find it fits very well w/ Rust's message passing between tasks.) So it's not like writing a webservice in Rust is completely impossible. I will admit that "we aren't web yet," but I'm glad to see the community working on it.
  - idlewan 12y ago
    That's the exact path I've taken in another language (Nimrod). Mongrel2 is a really good way to have all the nitty-gritty of http handled while you worry exclusively about two ZeroMQ sockets (from and to Mongrel2). It makes it a whole lot easier and safer.

nkozyra 12y ago

Since Go will gladly handle said requirements, is this last point simply arbitrary? As Go and Rust share a lot of similarities, what is it about Go that's so unappealing for this use case?

eudox 12y ago
The type system?
- nkozyra 12y ago
  The type system doesn't preclude any of the requirements he listed (other than it simply not being Go)
twic 12y ago
Do Go and Rust share a lot of similarities? Apart from compiling into native code and being relatively new, what? It seems to me that Go and Rust are much more different than alike. Go has GC, Rust has lifetimes. Go has a simplistic type system, Rust has a sophisticated one. Go allows shared mutable state, Rust does not. These are pretty deep differences.
- 1ris 12y ago
  Both implement the the CSP concurrency model, for example. Both have a C-like syntax. They are both object-oriented, but very different in that from java/c++/.net.
deleted 12y ago
[deleted]

VeejayRampay 12y ago

Out of curiosity, why is it that you wouldn't want Go for such a task? Is it the lack of maturity, dislike for the language itself?

Ygg2 12y ago
Probably the GC. Rust once finished and proved should be safe for concurrent usage AND without GC cleanup. That's a major feat of engineering.
- matthewmacleod 12y ago
  That's a major feat of engineering Absolutely, but it's not a reason to not use Go. The web is probably the platform with the least possible damage caused by GC. It's OK if people like the language and want to use it for web development, though. I'm personally pretty excited about it, because I'm not a huge fan of Go and Rust looks pretty neat.
- nkozyra 12y ago
  "On the topic of performance, keep in mind that Go gives the programmer considerable control over memory layout and allocation, much more than is typical in garbage-collected languages. A careful programmer can reduce the garbage collection overhead dramatically by using the language well; see the article about profiling Go programs for a worked example, including a demonstration of Go's profiling tools." And "The current implementation is a parallel mark-and-sweep collector but a future version might take a different approach." (which I'm certain it will) http://golang.org/doc/faq#garbage_collection http://golang.org/doc/faq#garbage_collection
  - pcwalton 12y ago
    > On the topic of performance, keep in mind that Go gives the programmer considerable control over memory layout and allocation, much more than is typical in garbage-collected languages. That's true (although I would question the use of "allocation" there—I think Java has as much control over when you allocate as Go does), but "some control" is not always enough control.

Ygg2 12y ago

If I remember Rust binaries, due to default static linking end up rather large. There is work to remove all unnecessary things from libstd into other libraries. That said, I can't wait for rust teepee server to land, it shapes up to be a rather interesting project.

chrismorgan 12y ago
The binary is large, but the memory footprint small. And the startup time is small, too… servers that start up in under five milliseconds—delightful for me, with my Django background.
jff 12y ago
Compare the footprint of your single static binary to a python program + the appropriate python 2.7.whatever & specific library versions which must be shipped with the program since odds are the user doesn't have the right version installed...
eridius 12y ago
Dynamic linking cuts the binary size down considerably, but of course it requires the Rust libraries to be installed on the machine. You can also turn on LTO for even more savings.

b0b_d0e 12y ago

For some reason, no one has mentioned that there is a very usable rust REST framework right now that you can try out https://github.com/Ogeon/rustful https://github.com/Ogeon/rustful I'm not the author of this, so I can't tell you what features are missing, but the features that are there work very well from what I can tell. When it comes to web frameworks in Rust, there aren't many options yet (as stated in are we web yet) but the few that are out there are in active development.

steveklabnik 12y ago
> For some reason Discovery of Rust projects is super hard right now. I'm quite into both REST and Rust and didn't know about your framework :/
- b0b_d0e 12y ago
  > Discovery of Rust projects is super hard right now. Good point! But I'm not sure of any other way to get projects noticed besides word of mouth and posting about them on sites like Hacker news and such. In fact that is where I first heard about rustful. > didn't know about your framework My framework is actually at https://github.com/jroweboy/oxidize/tree/incoming https://github.com/jroweboy/oxidize/tree/incoming (master branch is sorely out of date) and I feel I still have a long way to go before I get that finished :)
drbawb 12y ago
I'm happily using the ZeroMQ bindings to serve an HTTP and WebSocket service w/ Mongrel2 servicing requests and Rust providing the handlers. Not a pure Rust stack, but it does a very admirable job serving responses for such a young language. (I also love have fallen in love w/ how mongrel2 handles websockets. I find it fits very well w/ Rust's message passing between tasks.) So it's not like writing a webservice in Rust is completely impossible. I will admit that "we aren't web yet," but I'm glad to see the community working on it.
- idlewan 12y ago
  That's the exact path I've taken in another language (Nimrod). Mongrel2 is a really good way to have all the nitty-gritty of http handled while you worry exclusively about two ZeroMQ sockets (from and to Mongrel2). It makes it a whole lot easier and safer.