[kernelbandwidth]

A lot of people describe Rust as a systems language (and it is!) and often that's followed up as a "better C". But it's also more than that!

Despite Rust looking a lot like C++ and often occupying a similar role as C, it's heritage is just as much that of an ML, and it shows in the semantics and type system. So while a lot of people do use it as a safer C, I often find it to be a "pragmatic Haskell".

My company does much of our back-end in Rust, and we've found it to be an excellent application language. A lot of this is the type system and the tooling. Cargo, the package manager and build system is excellent, builds are far more reproducible and I've spent far less time debugging builds (as opposed to code) than just about any other language I've used. Rust's type system is great if you like that kind of thing, and I find Rust to be particularly easy to debug and refactor. RAII and destructors/drop semantics come in handy more often than you'd think, and the "fearless concurrency" thing is real.

That said, lifetimes do occasionally cause some pain, the learning curve isn't the kindest, and the patterns are different from a lot of other languages. Personally though, I've found Rust to be very productive after getting over the initial learning hump and understanding the borrow checker more. This is gets more true the larger the project gets, as Rust tends (in my experience) toward the trade off of putting a fair bit of complexity up front in exchange for a slower accumulation of complexity as the project increases in size and scope. It's a trade off that I'm often happy to make, but is always a judgement call.

[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!

[dronemallone]

Could you please explain why and how the Rust compiler is better than compilers for other languages? After all, every language compiles down to machine code/assembly. So, the reason that one language is "better" than the other has to do with the fact that the compiler for one language is "better" than another.

[kbenson]

It's not that the compiler is better, it's that the language requires you to specify some things other languages don't (or infers a default if not defined), and uses that to enforce specific conditions. It's very similar to using types in languages compared to not having types.

In the same way that type information can be used by the compiler to optimize out some operations, the type information and the variable lifetime and ownership information/rules allow for specific optimizations that are harder to assume in C.

That is, you can do the exact same operations in C and Rust, and because you were forced to define more constraints in Rust (or defaults were inferred without you defining them), the compiler can make stronger assertions about what is being done, so it allows for the possibility of more optimizations.

[kernelbandwidth]

Well, one major advantage for the Rust compiler is that it compiles Rust code, which I happen to have a decent bit of.

Joking aside, I'm not arguing that the Rust compiler is "better" than any other compiler. The Rust team seems to have done a great job with it, but I'm neither a PLT guy nor a compiler writer so I can't profess an informed opinion there. What I am interested in though is the Rust language semantics (which the compiler enforces, just as every correct compiler enforces the semantics of the language it compiles). Rust-the-language provides benefits that we (my company's engineering team) finds to be valuable for writing our software -- a strong, flexible, static type system; Option/Result types; the ownership model that promotes good practices and prevents a lot of concurrency bugs that a GC would not help with; drop semantics which allow interesting and powerful techniques with smart pointers. As a bonus, Rust-the-ecosystem includes some excellent and ever growing tooling that lets us focus more on solving development and business problems.

As for Rust-the-compiler, others have already done a better job than I think I can, so I'll let those comments speak to the issue.

Other people accomplish great things with other tools. Rust works really well for us though, and I like to share that.

[biokoda]

C/C++ compiler will compile your code if it is correct. Rust will not compile code if it can detect that it will not work or it is not safe even though the syntax is correct. It can guarantee the program is memory safe (double free, user after free, null dereferencing, using uninitialized memory, array bounds checks).

This makes large refactorings so much easier. It also makes working on large projects with lots of people much easier.

[turboladen]

I have to say that, despite working with only a few compiled languages, errors and warnings emitted from rust's compiler are far more helpful than any other I've used.

[fnord123]

The rust compiler rejects more programs which helps prevent wasting time testing at runtime.