Is it just me, or is using Rust for web apps kinda odd?
The efficiency and explicit memory ownership in Rust makes it a lot easier to avoid some of the scalability problems you run into in dynamic languages. The amount of material you can find online on people discussing hunting down memory leaks in Rails, or discussing how they just scale up by throwing gobs of RAM and extra servers at the problem or restarting their app every day or two, is all stuff that is much easier to avoid in a language like Rust. It is possible to leak memory in Rust, but due to how explicit you are about how memory is owned, it's less likely and more likely to be easier to track down if you do.
It is a bit more conceptual overhead to learn Rust than many dynamic languages, but I think that overhead is well spent as it can pay off in performance, stability, and maintainability later on.
Sure I might need 250mb of RAM for a Rails app but there's 10+ years of real life thought and care put into the framework and about the same in external gems/blog posts/etc..
I'm ok with spending $5/month on an instance to serve a Rails app for 95% of use cases and I'm a load balancer away from multiplying my throughput if I need to scale out.
If I could snap my fingers and have the same ecosystem in Rust I would switch instantly but it's not the world we live in.
I'm not sure if even 5 years will be enough because Go 1.0 has been out almost 4 years and it's still not even in the same galaxy as Rails in terms of ecosystem.
So if you're just going to be exposing a RESTful API backend for a JavaScript based frontend, or even for a Rails app frontend to talk to, Rust makes a lot more sense.
Also, the only way an ecosystem gets bootstrapped up is by people scratching their own itches. By starting to write web services in Rust now, and implementing those things that aren't yet implemented, you can help to bootstrap it up. Of course, that only works if you have the extra time to spare to do so, but for those things that only need one or two extra things that don't yet exist, it may pay off due to the lower chances of having to debug runtime errors, less time and complexity spent trying to make it scale out, etc.
Ex: http://edgeguides.rubyonrails.org/api_app.html
On the Python side of things, I'd use tools like SQLAlchemy and a few other packages.
Every web application I've built can still be efficiently modeled with a relational database. An ORM that lets me model things quickly and allows me to avoid shooting myself in the foot by easily monitoring raw queries is going to win in my book when it comes to picking a tech stack to work with.
The major ecosystem problem is that no one can just wake up and be like... I'm going to spend the next year making a Rust version of Rails. These features and ideas need to come from real life use cases, that's really 99% of Rails' success.
It can be done in any language of course, but you're 10 years behind the curve.
In a perfect world, it wouldn't be a port, but something that meshes really well with real world use cases while taking advantage of what Rust has to offer.
I don't mind change (I embrace it), but it needs to be for a REALLY good reason.
It should be perfectly natural to use compiled languages to serve web requests.
Rust is a very expressive language, and with its focus on safety a very good candidate for distributed systems.
I for one, given my experience using Tcl for an application server, find odd to use scripting languages for web.
That said, I think it's great to do things like this. Someone has to pave the way. And, if a good API/web ecosystem builds up in Rust there's no reason _not_ to use it.
At the moment though, I think a more _natural_ fit for Rust would be for something a little lower level than an API server.
And if you have a lot of users, Rust can help lower your monthly bill by requiring fewer resources. The safer memory guarantees from the compiler is a great bonus on top of all that.
Rust makes the most sense to me in a GraphQL/Falcor type backend. The lower number of endpoints combined with Rust's perf and focus on correctness seem like a better fit than templating out web pages.
One thing I've been curious about: is it the case that there are no pauses, or that you know when they happen?
I know one of the concerns with GC is it can just kind of happen whenever and pause whatever else you've got going on. It also has to do extra work to track down what sort of memory is reachable or not.
Now is rust's RAII-style approach actually faster or do you just have more control over it? It doesn't have to trace reachable memory from the roots like a GC, but it still does have to do some work, right?
Rust does also support reference counting when you want it, which can bring its own set of performance issues in certain circumstances. Think more about general slowness due to constantly incrementing and decrementing references in an atomic fashion when you pass RC-ed data between functions, rather than the pauses seen with garbage collection. But how bad that is depends greatly on how and where you're using reference counted variables, and the addition of the lifetime/borrow system makes it easier to avoid some of the more egregious cases here.
Additionally, some people are doing work on GCs that work with Rust. The two links below have some good descriptions of the progress and challenges related to that.
http://blog.pnkfx.org/blog/2015/10/27/gc-and-rust-part-0-how... http://manishearth.github.io/blog/2015/09/01/designing-a-gc-...
That being said, I don't think that should be anybody's primary motivation for a production application. :)
The flow is this : an event comes in, you need to answer to it very quickly by doing synchronous tasks, and sometimes you also need to trigger asynchronous tasks in parallel, wait for their result, and assemble it before sending the result ( / upadte the gui).
Basically, synchronous algorithls are solved by any language. The core issue that remains both on the client and the server is handling shared state and parallelism.
One thing that's really cool about rust is that it can choose a conversion function based on the type of thing you are assigning to.
In other words, in "let x = foo()", foo() can do a different thing depending on the type of x.
I found that out working on a simple rust program interacting with postgresql.
Not saying that one feature makes all the difference, but you find nice advantages like that all around. Taken together, they might lead you to a more creative overall solution, and it might be a game changer.
Don't know how safety claim of Rust ensures on server side, here seems more on the application layer.
However, if just writing some apis, then any language will do, I don't see Rust is particular odd in that sense, if you are willing to forget about ecosystem, while at the same time I don't believe it has a edge over other language.