[mullsork]

May I ask what kind of backend you're developing? I've always been curious about development speed for Rust/Go in terms of JSON APIs, i.e. if it's remotely feasible to say replace Node.JS with Rust. I'd expect a drop in development phase but an increase in stability & correctness.

[steveklabnik]

npm has started writing new backend services in Rust instead of node. (Not all new services, but they have multiple ones in production now.)

You'd want to check out https://tokio.rs/ and the (released very soon, but not quite yet!) hyper 0.11 that integrates with it.

[crzwdjk]

I've been developing a small self-contained web app to serve as a scoreboard for roller derby. It consists of a server written in Rust that mostly serves a bunch of static pages and javascript files, as well as a JSON API that the javascript calls into to provide the dynamism. Thus far, serde-json has been an amazingly low-friction way to design JSON APIs, and Rocket has been a relatively convenient way to organize web apps. The closest competitor to my app is written in Java and needs about 200 MB of memory at steady state just on the server. My version runs with an RSS of about 3 MB and considerably better performance.

[te_chris]

If you're looking for a replacement for node, I'd take a much deeper look at Elixir/Erlang than Rust (first up at least). You get easy concurrency, full functional language, good libraries (Phoenix is a great web framework), stability etc. Rust looks super cool, but there are high-level languages which can also offer good web performance.

[kernelbandwidth]

This is true if you're agnostic to or prefer dynamic typing. If you're using Node, that's probably true, but at the high level I tend to think of Haskell, OCaml, F#, and Scala as the comparisons.

As someone who likes neither dynamic typing or Ruby's syntax, I do agree that Elixir looks very cool, and have considered it for jobs that favor development speed over compile-time correctness.

[bjz_]

Not having a decent type system (dialyzer is slow and does not have parametric and bounded polymorphism) is a massive strike against Elixir.

[kernelbandwidth]

Sure! This is us: http://www.litmushealth.com/

Our APIs are JSON and Avro based, if that's what you're asking.

The company does two major things: connect to sensor systems and collect data, and provide ML/Data Science/(other buzzwords for math) tools for clinical trials and medical studies. In many ways this means Rust is a "reasonable" but not necessarily "ideal" fit -- we could certainly afford the overhead of a GC, so the no-GC aspect of Rust doesn't really buy us anything major, though it does provide some nice performance and memory usage in the parts below us in the stack (Iron/Hyper, soon Tokio). That said, the more we get into the "big data" and ML stuff, the more value there is in having a good C FFI and good performance profiles.

We get a lot of value from the other aspects of Rust though. Traits (typeclasses) are powerful and flexible. More importantly, they promote that old, but good, Java ideal of "programming to interfaces" without all the other baggage. Rust's support for FP is quite good (though the lack of HKTs means there's no monads, at least not "actual" monads ala the Haskell Monad typeclass). The fact that Rust closures are actually traits means you can make some really smooth interfaces that transition from just a static function to a closure and finally to a 'proper' object.

The Macros 1.1 release recently and the Serde library hitting 1.0 have been a big deal. JSON APIs are trivial to write and get all the benefits of strong typing and Option/Result on the deserialization side.

One mistake I think people make with Rust is thinking that because you can do things in a really efficient style, you should. This leads to thinking that Rust isn't as good for "applications" work because you have to think about heap vs. stack allocations and lifetimes and such. But if you were going to use a GC, you can probably afford dynamic dispatch and some extra allocations anyway. Relax, clone the data/box the trait, and come back later if the performance matters. If you wrote the thing in Python, you weren't going to get a choice about boxing things and optimizing would be way harder anyway. Basically, if you treat Rust like an impure (and strict) Haskell or OCaml/F#, it'll actually work pretty well once you learn some idiosyncrasies.

Sorry, bit of a long tangent, but yes, like I said in the last comment, Rust asks a little more up front and in return you get better stability, correctness, and refactoring ability. Testing is easy, especially with unit testing built into the compiler flags and Cargo. Cargo really helps with the "works on my machine" issue and deployments. Pulling in libraries is painless, and while the ecosystem is still small compared to (for example) Java, it's growing, enthusiastic, and so far has covered what we need most of the time.

[mullsork]

Hey I know I'm late with this response but I just wanted to say thanks for the thorough response!