7 ms·

Not to be a curmudgeon but why would one want to use Rust for web development for a non-toy project? I am a big fan of Rust, but as it aims to be a better C++,

by hendzen 12y ago

Not to be a curmudgeon but why would one want to use Rust for web development for a non-toy project? I am a big fan of Rust, but as it aims to be a better C++, it is probably a better fit for OS development, game engines, embedded systems, databases, complex desktop applications (Photoshop/Word/Chrome), etc. While Rust is quite expressive for a systems programming language, its banner features are the borrow checker (+ lifetimes, etc) and powerful static type system. Rust emphasizes zero-cost abstractions with compiler-enforced memory & thread safety. The popular web development languages are dynamically typed and interpreted, with an emphasis on rapid development, which is a very different niche than Rust claims to fill. Perhaps Rust could be used to build a highly optimized server for a large site, but at that point it would probably better to write the application to run on the JVM. Although the JVM may be slower (within a constant factor, and assuming Rust is eventually as fast as C++) and more memory-intensive than the optimized native code produced by Rust's LLVM based compiler, the JVM's extensive tooling and run-time profiling tools make it a natural choice for high performance web servers.

chrismorgan 12y ago
Rust is certainly not ready yet, but I think you’ll be surprised how great Rust can end up; I believe it will end up superior to the options available, though its systems focus will certainly have certain cognitive burdens; it is not going to be superior in every way. People typically associate web servers with dynamic languages. I am ready to challenge that notion; there are various things that people don’t think of that a language like Rust makes possible, and those sorts of things are the focus of my talk at Strange Loop this year, in September: https://thestrangeloop.com/sessions/fast-secure-safe-the-web-that-can-still-be https://thestrangeloop.com/sessions/fast-secure-safe-the-web...
- mwcampbell 12y ago
  Your Strange Loop talk description presents some good reasons for using statically typed languages, but why Rust specifically? Why not the JVM, using Scala or even Java 8? Sure, a Rust program compiled to native code can start faster, and be fast right away without any JIT warm-up. But is it worthwhile to optimize for those things? Especially since the JVM already has a much larger set of libraries and tools. And while Rust's lack of GC would probably yield impressively low memory usage figures, I wonder if that matters in server applications. The idea of a server that starts up fast, is fast from the start, and has minimal memory usage is appealing to me, but I suspect that it's irrational to optimize for these things except in niche applications like web interfaces in routers.
  - chrismorgan 12y ago
    I’ll be covering more about why Rust specifically in the talk; there are some really nifty things in its compiler and type system which allow for more than languages like Scala and Java 8. I’ve mentioned some of them in some of the other comments here; given the interest shown here, I think I’ll say more about what I hope for in the long term in a few weeks’ time. Oh, It also gives you a lot in the way of correctness which languages like Scala and Java 8 don’t give you.
    - hythloday 12y ago
      I looked at your other comments but couldn't see anything enlightening. I really enjoy Scala's type system and would love an excuse to learn Rust; what can Rust's type system do that Scala's can't? (I saw you mention an ORM; what additional safety could Slick gain if it were using Rust's type system?)
      - pcwalton 12y ago
        Rust has data-race-free concurrency. The compiler won't let you compile code that has data races unless you write "unsafe {}".
        frowaway001 12y ago
        So Rust would be able to figure out that some transactions might be prone to rollbacks? What's the name of Rust's database library which does that?
  - twic 12y ago
    I am also skeptical about Mr Morgan's claim. I am, therefore, really looking forward to his talk!
  - Ygg2 12y ago
    For one he can stop worrying about nulls and start worrying about appeasing the compiler :P Rust compiler is a harsh, ever changing mistress.
deleted 12y ago
[deleted]
jerf 12y ago
"Not to be a curmudgeon but why would one want to use Rust for web development for a non-toy project?" Web development is horrifically, unbelievably bent around two facts: 1. There has been no convenient, highly popular and supported language for development that also has best-of-breed performance. You can have one or the other. (Yes, I've probably heard of your obscure fast-as-C language that has a great web stack... to a first approximation, nobody else has.) 2. Web development languages have been profoundly, deeply single-threaded, to the point that the web world began to take it as an unmitigated virtue that a page started with a request, generated a response, and dropped everything in the world that it knew at the end of the request. State is something that must be managed carefully, but especially in this era of people writing web applications that may literally have gigabytes available per concurrent user (obviously, not everybody, but this is a non-trivial use case!), the statelessness dogma has seriously broken people's mental models vs. what the hardware is actually capable of. With Rust, you should be able to write fast, concurrent web applications that actually do something concurrently and aren't constantly marshaling across requests for the client to re-initiate AJAX calls or other such silliness, it'll be fast, and with its emphasis on memory safety, statically safe as well (something that you're not going to get very easily out of Java, and certainly not from a programmer just sitting down and pounding out some Java). It isn't going to be the solution to every problem, but it's going to be the solution to more problems than people realize right now, because we've so deeply internalized our essentially-PHP models of how the web works that we can't hardly even see how things ought to actually be working. Rust isn't the only language biting at this apple. Go is obviously another one. But Rust has a pretty decent shot at taking a big chunk, if it plays its cards right. You say the popular web development platforms are all dynamically typed... I'm increasingly coming around to the position that was an accident of history, rather than an immutable fact.
- MrBuddyCasino 12y ago
  So I guess I'm gonna be that guy. According to http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/, the 2nd position is held by a Java framework, losing only 13,5% to the C++ overall winner. Granted, you need a 3rd party library to have something similar like goroutines / fibers / actor concurrency / whatever, but its all there if you want it.
stcredzero 12y ago
Not to be a curmudgeon but why would one want to use Rust for web development for a non-toy project? I am a big fan of Rust, but as it aims to be a better C++, it is probably a better fit for OS development, game engines, If there was an easy way of using Rust as a websocket server, I would be using that for my project instead of Go. The option to use reference counting is a Big Win when it comes to high degrees of parallelism on multicore processors. When you have GC, the GC thread comes along and causes cache misses for all of the other threads running on different processor sockets. With reference counting, garbage is "collected" locally.
- fulafel 12y ago
  Ref counting is murder on caches. Every read will cause a rmw on the ref count cache line. Modern generational GCs are reasonably nice on caches in most cases.
  - dllthomas 12y ago
    Every handoff, not every read, right? Of which there might be more or fewer.
  - AlisdairO 12y ago
    This is not so much the case in rust because you only increment the reference count when you're passing around copied refs to an item. If you instead borrow a ref counted item, you don't need to increase the ref count - because rust will statically enforce that the borrow lasts less time than the item it borrows from (which is enough to keep the item alive). With good coding practices, you can eliminate the large majority of ref count increments/decrements.
  - yuriks 12y ago
    Such cache line will (because it is adjancent to the refcounted data) almost always be in cache anyway. Rust's refcounting is much cheaper than C++'s refcounting because it doesn't need to be atomic. (There is a separate type for atomic RC, and it is enforced by the compiler that you use it when needed.)
- 12y ago

by hendzen 12y ago

chrismorgan 12y ago

Rust is certainly not ready yet, but I think you’ll be surprised how great Rust can end up; I believe it will end up superior to the options available, though its systems focus will certainly have certain cognitive burdens; it is not going to be superior in every way. People typically associate web servers with dynamic languages. I am ready to challenge that notion; there are various things that people don’t think of that a language like Rust makes possible, and those sorts of things are the focus of my talk at Strange Loop this year, in September: https://thestrangeloop.com/sessions/fast-secure-safe-the-web-that-can-still-be https://thestrangeloop.com/sessions/fast-secure-safe-the-web...

mwcampbell 12y ago
Your Strange Loop talk description presents some good reasons for using statically typed languages, but why Rust specifically? Why not the JVM, using Scala or even Java 8? Sure, a Rust program compiled to native code can start faster, and be fast right away without any JIT warm-up. But is it worthwhile to optimize for those things? Especially since the JVM already has a much larger set of libraries and tools. And while Rust's lack of GC would probably yield impressively low memory usage figures, I wonder if that matters in server applications. The idea of a server that starts up fast, is fast from the start, and has minimal memory usage is appealing to me, but I suspect that it's irrational to optimize for these things except in niche applications like web interfaces in routers.
- chrismorgan 12y ago
  I’ll be covering more about why Rust specifically in the talk; there are some really nifty things in its compiler and type system which allow for more than languages like Scala and Java 8. I’ve mentioned some of them in some of the other comments here; given the interest shown here, I think I’ll say more about what I hope for in the long term in a few weeks’ time. Oh, It also gives you a lot in the way of correctness which languages like Scala and Java 8 don’t give you.
  - hythloday 12y ago
    I looked at your other comments but couldn't see anything enlightening. I really enjoy Scala's type system and would love an excuse to learn Rust; what can Rust's type system do that Scala's can't? (I saw you mention an ORM; what additional safety could Slick gain if it were using Rust's type system?)
    - pcwalton 12y ago
      Rust has data-race-free concurrency. The compiler won't let you compile code that has data races unless you write "unsafe {}".
      - frowaway001 12y ago
        So Rust would be able to figure out that some transactions might be prone to rollbacks? What's the name of Rust's database library which does that?
- twic 12y ago
  I am also skeptical about Mr Morgan's claim. I am, therefore, really looking forward to his talk!
- Ygg2 12y ago
  For one he can stop worrying about nulls and start worrying about appeasing the compiler :P Rust compiler is a harsh, ever changing mistress.

deleted 12y ago

[deleted]

jerf 12y ago

"Not to be a curmudgeon but why would one want to use Rust for web development for a non-toy project?" Web development is horrifically, unbelievably bent around two facts: 1. There has been no convenient, highly popular and supported language for development that also has best-of-breed performance. You can have one or the other. (Yes, I've probably heard of your obscure fast-as-C language that has a great web stack... to a first approximation, nobody else has.) 2. Web development languages have been profoundly, deeply single-threaded, to the point that the web world began to take it as an unmitigated virtue that a page started with a request, generated a response, and dropped everything in the world that it knew at the end of the request. State is something that must be managed carefully, but especially in this era of people writing web applications that may literally have gigabytes available per concurrent user (obviously, not everybody, but this is a non-trivial use case!), the statelessness dogma has seriously broken people's mental models vs. what the hardware is actually capable of. With Rust, you should be able to write fast, concurrent web applications that actually do something concurrently and aren't constantly marshaling across requests for the client to re-initiate AJAX calls or other such silliness, it'll be fast, and with its emphasis on memory safety, statically safe as well (something that you're not going to get very easily out of Java, and certainly not from a programmer just sitting down and pounding out some Java). It isn't going to be the solution to every problem, but it's going to be the solution to more problems than people realize right now, because we've so deeply internalized our essentially-PHP models of how the web works that we can't hardly even see how things ought to actually be working. Rust isn't the only language biting at this apple. Go is obviously another one. But Rust has a pretty decent shot at taking a big chunk, if it plays its cards right. You say the popular web development platforms are all dynamically typed... I'm increasingly coming around to the position that was an accident of history, rather than an immutable fact.

MrBuddyCasino 12y ago
So I guess I'm gonna be that guy. According to http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/, the 2nd position is held by a Java framework, losing only 13,5% to the C++ overall winner. Granted, you need a 3rd party library to have something similar like goroutines / fibers / actor concurrency / whatever, but its all there if you want it.

stcredzero 12y ago

Not to be a curmudgeon but why would one want to use Rust for web development for a non-toy project? I am a big fan of Rust, but as it aims to be a better C++, it is probably a better fit for OS development, game engines, If there was an easy way of using Rust as a websocket server, I would be using that for my project instead of Go. The option to use reference counting is a Big Win when it comes to high degrees of parallelism on multicore processors. When you have GC, the GC thread comes along and causes cache misses for all of the other threads running on different processor sockets. With reference counting, garbage is "collected" locally.

fulafel 12y ago
Ref counting is murder on caches. Every read will cause a rmw on the ref count cache line. Modern generational GCs are reasonably nice on caches in most cases.
- dllthomas 12y ago
  Every handoff, not every read, right? Of which there might be more or fewer.
- AlisdairO 12y ago
  This is not so much the case in rust because you only increment the reference count when you're passing around copied refs to an item. If you instead borrow a ref counted item, you don't need to increase the ref count - because rust will statically enforce that the borrow lasts less time than the item it borrows from (which is enough to keep the item alive). With good coding practices, you can eliminate the large majority of ref count increments/decrements.
- yuriks 12y ago
  Such cache line will (because it is adjancent to the refcounted data) almost always be in cache anyway. Rust's refcounting is much cheaper than C++'s refcounting because it doesn't need to be atomic. (There is a separate type for atomic RC, and it is enforced by the compiler that you use it when needed.)
12y ago