6 ms·

What was behind your decision to pick Rust? My understanding is that Rust is meant as replacement for C++ in places where C++ performance is needed (browsers, s

by Touche 11y ago

What was behind your decision to pick Rust? My understanding is that Rust is meant as replacement for C++ in places where C++ performance is needed (browsers, systems programming (maybe)), etc. A web server does not fall into that category, so why did you pick it?

jerf 11y ago
"A web server does not fall into that category, so why did you pick it?" That's too categorical a statement. It depends on a lot of things. Sure, there's a place in the world for PHP pages that take two or three full seconds to render, but it doesn't matter because they're doing something useful and don't get hit a thousand times per second. There's also a place for things that render in under a millisecond because they're getting hit at an incredible rate, and if they also have some sort of interdependencies then Rust can make a lot of sense. Plus as I've said before, the whole "you're stuck in IO anyhow so who cares how fast the render code runs" dogma has sometimes gone too far. (I know you didn't say anything about that, but I'm guessing based on experience it's what lies behind your point.) My experience in switching from slow languages to fast languages, even doing the same IO, is that you do tend to see real performance gains unless your page was absolutely trivial. Slow languages really are slow in practice.
- jurre 11y ago
  > PHP pages that take two or three full seconds to render I don't use php personally, but most of my rails apps render full pages in under 100ms. I'd imagine php performance to be at least on-par with a full rails app.
  - jerf 11y ago
    I'm thinking Wordpress, or bespoke status pages for internal apps. Of course you can get a PHP page out in under a millisecond if you try hard enough, but it's often not used in that sort of place. (And it often is, but that still doesn't mean it often isn't.) Rails, for that matter, is known for being easy to produce multi-second pages too. Slow languages are slow in practice, too.
    - jerf 11y ago
      It actually amazes me that people find the statement that slow languages are actually slow offensive and worthy of downvoting. As I said, it is my experience that simply switching from slow to fast languages even on "IO dominated" workloads has real, visible effects. If you haven't tried it, consider trying it before becoming offended at the idea that your tool may not be appropriate for all use cases. Yes, it can matter when your language is 50 times slower than another.
  - mtberatwork 11y ago
    Once you start seeing hundreds or thousands of requests coming in per second and you see your cpu utilization sky rocket, then the "slowness" of the interpreted languages really comes into full play. Most apps/websites will never achieve this kind of load or scale though.
    - Touche 11y ago
      > interpreted languages really comes into full play. There are plenty of non-interpreted languages that don't require GC though. When you pick Rust you are picking manual memory management. Does even Google opt for non-GCed languages for their web servers?
      - steveklabnik 11y ago
        We've been having a debate lately, within Rust, if "manual" is really the right term here. { let x = Box::new(5); // malloc } // free Is this really _manual_? In a sense it is, but it's very different than what most people think about. "Automatic" is kind of a good word, but Objective-C/Swift's "ARC" already covers that, and we don't do refcounting, so that could be misleading too. Maybe "deterministic"?
        kibwen 11y ago
        Memory management in C is also "deterministic", just forget to ever free. :P
        DasIch 11y ago
        How about lexical memory management as a nod to dynamic vs. lexical scoping?
        steveklabnik 11y ago
        That might work for now, but something we're working on for the future is making borrows non-lexical, so....
- Touche 11y ago
  > That's too categorical a statement. It depends on a lot of things. I didn't mean it to be. Of course there are extreme cases where GC pauses are unacceptable on a web server, but those are relatively rare. Even Google mostly uses Java (although they are heavy C++ users, is it for their web servers?). There are always extreme cases, which is why I asked the question. > My experience in switching from slow languages to fast languages, even doing the same IO, is that you do tend to see real performance gains unless your page was absolutely trivial. Slow languages really are slow in practice. Slow vs. fast is not black and white. Is Go slow? Is Lua slow? I Java (on a warmed up JVM) slow? We're talking about GC vs. non-GC languages here. Do you really see a difference in performance gains?
  - deleted 11y ago
    [deleted]
  - acconsta 11y ago
    >Even Google mostly uses Java I'm not so sure about that. The core services (e.g. Search, Maps, Earth, Big table, Map reduce) seem to be C++. Ads is possibly an exception.
    - Touche 11y ago
      We're talking specifically about the web application servers here. I wouldn't be surprised that something like Search is C++, it's one of the most visited pages in the world. But I haven't heard specifically that it is. I don't think it's any secret that Java is huge Java users. If not web servers, then for what?
      - acconsta 11y ago
        50% C++, 25% Java http://qr.ae/RP7wXh http://qr.ae/RP7wXh At Google's scale, the performance difference between Java and C++ can means millions of dollars in electricity alone.
        Touche 11y ago
dkhenry 11y ago
Two big benefits are the static typing and compilation so a I get a lot of benefit from catching errors early, and the second big benefit is static linking. Other languages give you that ( namely Go ), but I found the correctness checking from rust is _way_ better and I am forced to have much better designs in my programs. Another Tangential benefit is that I can do lots of great system level things ( High performance data collection, Clustering, Math), and then have a thread pull in a web server and serve out things like statistics and control interfaces. Also its just nice to program in and the tooling is much nicer then C++
- Touche 11y ago
  Thanks for your replying. Static typing I won't argue with you, but is static linking important for a web server? One of the big areas where people choose Go is for cli utilities and static linking is a big reason for that choice. I can see Rust becoming a competitor in this space for the same reason. But for a web server that you control I don't see a huge advantage to static linking.
  - neoCrimeLabs 11y ago
    The one benefit of static linking is reduction of software/library dependencies required for production deployment. In many organizations this means you can develop on any OS/Platform you wish, and then deploy on whatever OS/Platform the ops team is currently running. Many organizations have yet to adopt devops and templated system deployment methodologies, so it's a legit concern.
    - Touche 11y ago
      > In many organizations this means you can develop on any OS/Platform you wish, and then deploy on whatever OS/Platform the ops team is currently running. That's true of dynamic linking as well. Static linking just saves you the trouble of having to install the library dependencies on the server. But for ops that's a pretty tiny, if not non-existent gain. So I don't buy it. When deploying to users it's a huge gain, so I do get that that for things like cli utils.
shmerl 11y ago
Who said Web server doesn't fall into that category? It benefits greatly from better performance.
Scarbutt 11y ago
Depends on your definition of web server, nginx is written in C, even Ruby and Python web servers call to C, they need the performance of C implementations, so I don't see why Rust wouldn't be a good fit for a web server.
deleted 11y ago
[deleted]
jamwt 11y ago
I think that line of thinking ends up not applying to rust terribly much. I know there's been several articles lately about broader applications of rust, and then "is it worth it?" type responses, concerns about "manual memory management", with the implication being there's some heavy tax on not using a GC. I would certainly agree with the presence of this tax while writing C/C++. (Less with C++, RAII, and especially c++11, but still there.) With rust, once you're up the learning curve (which, granted, can take a few months), your productivity is not substantially worse than GC'd languages. You pretty much master the borrow checker's semantics, and the best practices to structure things in ways that play nicely with its expectations. And lifetime-related errors don't occupy all that much of your development time. Source: my team has been re-writing some components of Dropbox's multi-exabyte storage system in rust (from go) over the last 9 months.
- pjungwir 11y ago
  I am fascinated that no one uses Objective C on the back end. Fast, low memory, quick to code in, high-level-enough, a mix of static and dynamic typing, and no garbage collection. Also plenty of expertise you can hire for, maybe already within your company. I think if Obj C had a good story for deploying on Linux (and not losing modern features like ARC), it would make sense to use it, so we'd see sites doing it and open source tools like a good webapp framework. It is because you would need to run OS X servers? (And is that even true?)
  - the-kenny 11y ago
    I think being so heavily pushed by Apple is actually a downside for ObjC here. I really enjoyed programming ObjC when I was programming for iOS and Mac. That was mostly because of the very rich API shipped with Apple products. Can you point me to a list of libraries written in ObjC that work without Apple specific code? (E.g. without using anything starting with 'NS')
    - mpvl 11y ago
      Gnustep

by Touche 11y ago

jerf 11y ago

"A web server does not fall into that category, so why did you pick it?" That's too categorical a statement. It depends on a lot of things. Sure, there's a place in the world for PHP pages that take two or three full seconds to render, but it doesn't matter because they're doing something useful and don't get hit a thousand times per second. There's also a place for things that render in under a millisecond because they're getting hit at an incredible rate, and if they also have some sort of interdependencies then Rust can make a lot of sense. Plus as I've said before, the whole "you're stuck in IO anyhow so who cares how fast the render code runs" dogma has sometimes gone too far. (I know you didn't say anything about that, but I'm guessing based on experience it's what lies behind your point.) My experience in switching from slow languages to fast languages, even doing the same IO, is that you do tend to see real performance gains unless your page was absolutely trivial. Slow languages really are slow in practice.

jurre 11y ago
> PHP pages that take two or three full seconds to render I don't use php personally, but most of my rails apps render full pages in under 100ms. I'd imagine php performance to be at least on-par with a full rails app.
- jerf 11y ago
  I'm thinking Wordpress, or bespoke status pages for internal apps. Of course you can get a PHP page out in under a millisecond if you try hard enough, but it's often not used in that sort of place. (And it often is, but that still doesn't mean it often isn't.) Rails, for that matter, is known for being easy to produce multi-second pages too. Slow languages are slow in practice, too.
  - jerf 11y ago
    It actually amazes me that people find the statement that slow languages are actually slow offensive and worthy of downvoting. As I said, it is my experience that simply switching from slow to fast languages even on "IO dominated" workloads has real, visible effects. If you haven't tried it, consider trying it before becoming offended at the idea that your tool may not be appropriate for all use cases. Yes, it can matter when your language is 50 times slower than another.
- mtberatwork 11y ago
  Once you start seeing hundreds or thousands of requests coming in per second and you see your cpu utilization sky rocket, then the "slowness" of the interpreted languages really comes into full play. Most apps/websites will never achieve this kind of load or scale though.
  - Touche 11y ago
    > interpreted languages really comes into full play. There are plenty of non-interpreted languages that don't require GC though. When you pick Rust you are picking manual memory management. Does even Google opt for non-GCed languages for their web servers?
    - steveklabnik 11y ago
      We've been having a debate lately, within Rust, if "manual" is really the right term here. { let x = Box::new(5); // malloc } // free Is this really _manual_? In a sense it is, but it's very different than what most people think about. "Automatic" is kind of a good word, but Objective-C/Swift's "ARC" already covers that, and we don't do refcounting, so that could be misleading too. Maybe "deterministic"?
      - kibwen 11y ago
        Memory management in C is also "deterministic", just forget to ever free. :P
      - DasIch 11y ago
        How about lexical memory management as a nod to dynamic vs. lexical scoping?
        steveklabnik 11y ago
        That might work for now, but something we're working on for the future is making borrows non-lexical, so....
Touche 11y ago
> That's too categorical a statement. It depends on a lot of things. I didn't mean it to be. Of course there are extreme cases where GC pauses are unacceptable on a web server, but those are relatively rare. Even Google mostly uses Java (although they are heavy C++ users, is it for their web servers?). There are always extreme cases, which is why I asked the question. > My experience in switching from slow languages to fast languages, even doing the same IO, is that you do tend to see real performance gains unless your page was absolutely trivial. Slow languages really are slow in practice. Slow vs. fast is not black and white. Is Go slow? Is Lua slow? I Java (on a warmed up JVM) slow? We're talking about GC vs. non-GC languages here. Do you really see a difference in performance gains?
- deleted 11y ago
  [deleted]
- acconsta 11y ago
  >Even Google mostly uses Java I'm not so sure about that. The core services (e.g. Search, Maps, Earth, Big table, Map reduce) seem to be C++. Ads is possibly an exception.
  - Touche 11y ago
    We're talking specifically about the web application servers here. I wouldn't be surprised that something like Search is C++, it's one of the most visited pages in the world. But I haven't heard specifically that it is. I don't think it's any secret that Java is huge Java users. If not web servers, then for what?
    - acconsta 11y ago
      50% C++, 25% Java http://qr.ae/RP7wXh http://qr.ae/RP7wXh At Google's scale, the performance difference between Java and C++ can means millions of dollars in electricity alone.
      - Touche 11y ago

dkhenry 11y ago

Two big benefits are the static typing and compilation so a I get a lot of benefit from catching errors early, and the second big benefit is static linking. Other languages give you that ( namely Go ), but I found the correctness checking from rust is _way_ better and I am forced to have much better designs in my programs. Another Tangential benefit is that I can do lots of great system level things ( High performance data collection, Clustering, Math), and then have a thread pull in a web server and serve out things like statistics and control interfaces. Also its just nice to program in and the tooling is much nicer then C++

Touche 11y ago
Thanks for your replying. Static typing I won't argue with you, but is static linking important for a web server? One of the big areas where people choose Go is for cli utilities and static linking is a big reason for that choice. I can see Rust becoming a competitor in this space for the same reason. But for a web server that you control I don't see a huge advantage to static linking.
- neoCrimeLabs 11y ago
  The one benefit of static linking is reduction of software/library dependencies required for production deployment. In many organizations this means you can develop on any OS/Platform you wish, and then deploy on whatever OS/Platform the ops team is currently running. Many organizations have yet to adopt devops and templated system deployment methodologies, so it's a legit concern.
  - Touche 11y ago
    > In many organizations this means you can develop on any OS/Platform you wish, and then deploy on whatever OS/Platform the ops team is currently running. That's true of dynamic linking as well. Static linking just saves you the trouble of having to install the library dependencies on the server. But for ops that's a pretty tiny, if not non-existent gain. So I don't buy it. When deploying to users it's a huge gain, so I do get that that for things like cli utils.

shmerl 11y ago

Who said Web server doesn't fall into that category? It benefits greatly from better performance.

Scarbutt 11y ago

Depends on your definition of web server, nginx is written in C, even Ruby and Python web servers call to C, they need the performance of C implementations, so I don't see why Rust wouldn't be a good fit for a web server.

deleted 11y ago

[deleted]

jamwt 11y ago

I think that line of thinking ends up not applying to rust terribly much. I know there's been several articles lately about broader applications of rust, and then "is it worth it?" type responses, concerns about "manual memory management", with the implication being there's some heavy tax on not using a GC. I would certainly agree with the presence of this tax while writing C/C++. (Less with C++, RAII, and especially c++11, but still there.) With rust, once you're up the learning curve (which, granted, can take a few months), your productivity is not substantially worse than GC'd languages. You pretty much master the borrow checker's semantics, and the best practices to structure things in ways that play nicely with its expectations. And lifetime-related errors don't occupy all that much of your development time. Source: my team has been re-writing some components of Dropbox's multi-exabyte storage system in rust (from go) over the last 9 months.

pjungwir 11y ago
I am fascinated that no one uses Objective C on the back end. Fast, low memory, quick to code in, high-level-enough, a mix of static and dynamic typing, and no garbage collection. Also plenty of expertise you can hire for, maybe already within your company. I think if Obj C had a good story for deploying on Linux (and not losing modern features like ARC), it would make sense to use it, so we'd see sites doing it and open source tools like a good webapp framework. It is because you would need to run OS X servers? (And is that even true?)
- the-kenny 11y ago
  I think being so heavily pushed by Apple is actually a downside for ObjC here. I really enjoyed programming ObjC when I was programming for iOS and Mac. That was mostly because of the very rich API shipped with Apple products. Can you point me to a list of libraries written in ObjC that work without Apple specific code? (E.g. without using anything starting with 'NS')
  - mpvl 11y ago
    Gnustep