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.
"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.
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...
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.
So far as I can tell, if you want a fancy ORM, you're using a mainstream web language like Ruby or Python. Golang is obviously more mature on the HTTP serverside than Rust, but it is nowhere close to Rails, and is particularly weak on persistence. My understanding is that the same is true of Clojure, too.
Go can’t do a fancy ORM because of its weak type system. Rust’s type system and compiler plugin support (still being polished, but entirely usable) allow for some really nifty things. An ORM like Django’s is absolutely possible in Rust—and with strong typing and serious error checking into the bargain.
We can also end up with things like HTML templates compiled into your binary and the HTML validated at compile time. Even things as precise as type checking on something like <time datetime="{{ time }}"> can be managed with Rust. And I intend to.
For Clojure, some pretty good web frameworks (with ORM and everything) are starting to pop up [1] [2] [3] [4], but they're still early revisions and thus are prone to bugs and security holes [5].
However, due to the JVM nature, one could use some of the well-tested and well-defined Java Web Framework from Clojure (with a lightweight wrapper, of course). I'm not really sure if people are actually doing that in production, though. [6] [7]
Or you could use GWT and have an extremely mature server-side language/ORM/everything-else, and a rich web client, all written in the same language and sharing the same class model.
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.
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 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.
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.
This is more of a general question, but is rust going to have a C-compatible ABI? In other words, if I define a function in Rust, can I export it into a .so/.dll and load it up in MyFavoriteLanguage and call that function like I can with C? Or would it require some kind of C wrapper around Rust that interfaces with my language?
One of the three existing Rust deployments is a Ruby gem written in Rust. Technically, it's a Ruby gem written in C, which calls out to Rust. So yes, it's very possible, today.
Servo uses rust-http, which I wrote; Teepee is not yet to the stage where it can be used, but I expect that once it is Servo will switch to it as is convenient.
(BTW, I’m curious: where did the spelling TeePee come from?)
[+] [-] hendzen|12 years ago|reply
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.
[+] [-] jerf|12 years ago|reply
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.
[+] [-] chrismorgan|12 years ago|reply
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...
[+] [-] stcredzero|12 years ago|reply
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.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] tptacek|12 years ago|reply
[+] [-] chrismorgan|12 years ago|reply
We can also end up with things like HTML templates compiled into your binary and the HTML validated at compile time. Even things as precise as type checking on something like <time datetime="{{ time }}"> can be managed with Rust. And I intend to.
I’ll be talking about how some of these sorts of things can work out at Strange Loop this year: https://thestrangeloop.com/sessions/fast-secure-safe-the-web....
[+] [-] terhechte|12 years ago|reply
However, due to the JVM nature, one could use some of the well-tested and well-defined Java Web Framework from Clojure (with a lightweight wrapper, of course). I'm not really sure if people are actually doing that in production, though. [6] [7]
[1] http://caribou.github.io/caribou/docs/outline.html
[2] http://hoplon.io/
[3] http://www.luminusweb.net/
[4] https://github.com/pedestal/pedestal
[5] https://news.ycombinator.com/item?id=7472841
[6] https://github.com/apache/tapestry-5/tree/master/tapestry-cl...
[7] https://github.com/jblomo/heion
[+] [-] eudox|12 years ago|reply
Clojure has Korma[0], Common Lisp has Crane[1] and Integral[2].
[0] https://github.com/korma/Korma
[1] https://github.com/eudoxia0/crane
[2] https://github.com/fukamachi/integral
[+] [-] Pxtl|12 years ago|reply
It's fast, expressive, and the modern Mono+ASP.Net web-stack is open-source (older stuff is still proprietary).
[+] [-] syjer|12 years ago|reply
[+] [-] johnyzee|12 years ago|reply
[+] [-] levosmetalo|12 years ago|reply
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.
[+] [-] b0b_d0e|12 years ago|reply
[+] [-] nkozyra|12 years ago|reply
As Go and Rust share a lot of similarities, what is it about Go that's so unappealing for this use case?
[+] [-] VeejayRampay|12 years ago|reply
[+] [-] Ygg2|12 years ago|reply
That said, I can't wait for rust teepee server to land, it shapes up to be a rather interesting project.
[+] [-] orthecreedence|12 years ago|reply
[+] [-] bjz_|12 years ago|reply
[+] [-] steveklabnik|12 years ago|reply
[+] [-] bryanlarsen|12 years ago|reply
[+] [-] chrismorgan|12 years ago|reply
(BTW, I’m curious: where did the spelling TeePee come from?)
[+] [-] scriptdevil|12 years ago|reply
(Link currently down)
[+] [-] chrismorgan|12 years ago|reply
[+] [-] ackdesha|12 years ago|reply