Can someone explain to me what a good use-case for Rust would be? I mean, why would I pick it over C#/Go/Python for web development? Does it only outperform them, or is it also a pleasant language to use?
I think the consensus among Rustaceans is that using Rust for web development today is an...aggressive choice. Especially with async/await not yet stabilized. I think most of the people doing it either have very specific requirements (wasm experiments maybe) or do it because it's fun to be on the ground floor of a new thing.
That said, I find Rust very pleasant to use. I don't have to make as many defensive copies of things or reach for as many immutable data structures, because I have much stronger guarantees around what code is allowed to mutate what data. I'm a fan of static typing, and I really like that enun matches will fail to compile by default if you haven't handled all the cases. There's a lot of explicitness like that, and I find explicitness pleasant. But of course different people feel differently about that, and there's also the widely acknowledged learning curve for lifetimes and borrowing.
Rust web dev-- aggressive? I struggle more with relational data modeling and refactoring my early design decisions than I struggle with Rust for web dev. I am not happy that the futures I painfully walked over hot coals to make work will be easily replaced by async/await but that's on me for not waiting until some undisclosed time in 2019 for async/await to release.
> I am not happy that the futures I painfully walked over hot coals to make work will be easily replaced by async/await
Glad I'm not the only one who was struggling with gigantic and confusing error messages that were fixed by trial and error (usually adding a `.map_err(|_| ())`).
No; async/await produces Futures, which is what actix-web uses.
It will use a slightly older futures, but that's why there's a compatibility layer, and I'm sure they'll update fairly quickly after stabilization and so you could just use that version as well.
Rust shines where you need robust code, speed (including reliable multicore processing, low memory usage) and possibly low-level interaction with the OS or hardware.
For me the robustness is great. It's not just memory safety, but strong type system without nulls is superb for avoiding stupid bugs (no more "undefined is not a function").
If you're writing a small blog, you probably don't need any of this — you won't hit resource limits, and you'll manage to write 100 lines properly in any language.
But if you need to process gigabytes of data, Rust may be super helpful:
If I were writing a small blog today, I would probably still go with Rust, just for the robustness. Catching bugs at compile time is so much nicer no matter how good your unit test coverage is (and especially when coverage is not great).
Performance is great, but the breadth of usage enabled by the small run-time (including no GC) makes it more exciting.
Rust is a general purpose programming language, and as such, has a wide array of use-cases. Current production uses of Rust include:
* Extending other languages, like Ruby, Python, and JavaScript, for various tasks. Usually when performance is paramount.
* Web services (though see below)
* Infrastructure, such as Amazon's announcement today: https://news.ycombinator.com/item?id=18539539 and quite a few other things, like Chef's Habitat product, Boyant's linkerd2, Dropbox's core infrastructure, or System76's hardware flashing tooling
* Cryptocurrency stuff of various kinds
* Databases, such as PingCap's TiDB
* Operating systems, like Google's Fuchsia (This one is arguably not "production", but they are one of the largest employers of Rust programmers, and keep hiring... so maybe consider this, maybe don't.)
* Version Control systems, like Facebook's Mononoke, or the internals of mercurial itself, as well as things like Pijul
* Cryptography, in some cases working alongside C to slowly port things over
* Video games, mostly indie stuff, though some AAA studios have started to use Rust for various things, and a new studio, Embark, is going all-in
This year, we identified four areas we really wanted to improve Rust on:
* Embedded development
* Network services
* WebAssembly
* CLI tools
These are other common areas we see people wanting to use Rust in the near future, or areas where we could significantly improve Rust for that given case.
EDIT: I forgot to answer your other question
> Does it only outperform them, or is it also a pleasant language to use?
Performance is a key thing we hear from people in web development, but increasingly, it's also memory usage, both in amount and stability. Less memory means less money spent on servers, and steady usage makes scaling calcuations easier. For example, crates.io is a rust-based web application, and it uses about 30MB memory resident at all times, last I checked. That's very little. More serious systems use more, but often significantly less than the JVM.
Rust is a modern, memory safe systems language. The code you write compiles to native machine which executes in a predictable way every time you run it.
If you need to write firmware for, say, a satellite, C# and Python are out because they have an intermediate step between your deployable and the machine instructions you eventually execute. You have an external dependency which adds a level of unpredictability. All three of your example languages are out because they are garbage collected languages, which makes them inherently unpredictable at runtime. The last thing you want is an OOM in the middle of a rocket engine burn.
Go and C# are competing with Python, Java, Ruby, etc. All languages you would write a web application in, but not a satellite's firmware.
1. You can get an OOM error (or a stack overflow) in most languages (including Rust).
2. Safety-critical hard realtime systems require far more determinism guarantees than a language/runtime alone can provide. For example, they require deterministic scheduling of threads (usually round robin with very strong prioritization guarantees and bounded task-switching latence), and so require a realtime OS. Also, safety-critical realtime systems have ways of guaranteeing bounded memory growth, for both the stack and the heap. These exist in specialized languages for realtime such as SPARK (an Ada variant) and SCADE.
3. Java is actually used in safety-critical hard realtime systems, including avionics, but in a special, hard realtime JVM that has different kinds of deterministic guarantees (when run on a realtime OS), including memory allocation, scheduling and hard deadlines for asynchronous events (see https://www.aicas.com/cms/en/rtsj). What's particularly cool about realtime Java is that it allows for a safe mix of realtime and non-realtime threads, as even in realtime systems, the actual realtime part is usually a small portion of the program.
Someone hasn't payed attention to the AOT compilers available for C# and Java, their widely deployment on embedded platforms, PTC, MicroEJ, Aicas, WebSphere Real Time, Android Things, wearOS, Ricoh, Cisco, Netduino, Meadow, IoT Core and many others.
Yes, maybe not on a satellite's firmware, but on a Gemalto firmware, certainly.
You should think of Rust as a better systems language, a better C. This was something that Go was pitched as but as a GC language it just doesn't fit a bunch of systems applications.
What I think is driving Rust and will continue to drive Rust is how it compares to C/C++ in certain key areas:
- Ownership is enforced at compile time. C++ obviously has smart pointers now (ie std::unique_ptr and std::shared_ptr) but these come with not insignificant runtime cost. What's more you end up passing around raw pointers anyway at least some of the time.
- C/C++ do suffer from and will continue to suffer from memory corruption, buffer overruns and undefined behaviour resulting from this. This has been and will continue to be the source of security vulnerabilities.
- Security is becoming so important and software so large and complex that the need for memory safety without sacrificing runtime speed will become increasingly important.
I honestly see a point where there'll be a need for a safe OS that is written in Rust or something like it.
One other thing about Web development: I think this is one area where Rust offers no real benefits (other than memory safety). Honestly I think the best model for serving HTTP requests is the cooperative multitasking model used by Hack (FB's PHP successor) where everything the request uses and does is created and torn down within the scope of a single request. This is a model that's far easier to reason about.
I came from years of doing Java where we had to deal with full GC pauses (something Go isn't immune to either).
You should think of Rust as a better systems language, a better C.
I think C++ is a more apt comparison. C is such a barebones language. Yes, it's very unsafe and Rust goes a long way to fix those issues, but Rust brings a lot of other features along with it which dial the language complexity up to 11.
I would like to see a simple language that fixes C's biggest problems. I think that would be really interesting to work with. Nobody seems to want to do it though, or if they have, they haven't been able to get any attention.
One of C's big problems is that it doesn't provide many efficient abstractions, and fixing that problem will lead you to something which is not like C for the same reasons Rust is not like C.
I agree that Rust is more like C++, especially since C++11, than it is like C. Rust has type deduction, closures, iterators, and Traits (which behave a lot like C++ class methods).
> I would like to see a simple language that fixes C's biggest problems. I think that would be really interesting to work with. Nobody seems to want to do it though, or if they have, they haven't been able to get any attention.
Honest question from an embedded C developer who's learning Rust, but still very beginner:
Wouldn't using a subset of Rust provide the same thing you're asking for?
* Processing 300GB of zipped text/access logs (my first attempt was in python and was much slower)
* Writing a git hook / git repo processor (again, first attempt was in python doling out to the git process alot. It was nice to compile a single binary for the hook, instead of worrying about having the correct python version installed)
* I'm writing a web service in Rust right now. It's a little rough around the edges honestly, but once async/await lands, I think I'll be much happier. The type safe templating and endpoint definitions I'm using are very nice, but probably not unique to rust. The compiler is also slow.
So probably not the best bet for webdev yet, but useful in other contexts.
> once async/await lands, I think I'll be much happier
The current futures proposal is on track for stabilization[1]. You can use futures with async/await today in nightly, and what you use will probably be exactly what lands in stable soon.
The biggest missing piece is documentation, but thats starting to improve. My go-to for examples is the futures test suite[2]. And if you want more features, futures-preview 0.3alpha adds a bunch of useful future combinators[3]. futures-preview now just wraps nightly's std::future, which is very nice.
Except for the missing documentation, rust's futures are looking great. You can have a play today if you feel keen to jump in. But, as you said it will take some time for the web development ecosystem to mature around the futures API.
It’s more like C than any of the high-level languages you mentioned, so yeah, it usually outperforms most of them. It’s basically “memory-safe C” with some modern constructs thrown in for good measure.
I personally wouldn’t build a website in Rust, but a webserver? Yeah, maybe.
Getting concurrency right is difficult, even in Go (I know, I have been there, it was a huge pain in the a$$). Rust guarantees via the borrow checker that the code is data race free. This alone is a huge advancement. I would argue that Rust contains as much boilerplate as Java, but Rust is as fast as C++ and safer than both.
-> You trade some code noise for safety and speed. Compared to C++ the code has even less noise.
Turning code into concurrent code is super easy in Rust. Just use the Rayon crate and change iter() functions into par_iter() and you are done (if the borrow checker doesn't complain).
If you want a really fast webserver. Tokio's[1] zero-cost abstractions are amazing. Further, the examples provided make futures/async/low-level socket work quite understandable.
Why is everyone so focused on pigeon holing languages like this? There was a time when I wrote web services in C, then C++, a little Perl, and mostly Java. Then we needed dynamic pages and turned to Javascript, and now that’s on the backend with node.
Personally I love Rust. I would choose to use it for web development top to bottom at this point, even with the current limitations of WASM (which is getting better) on the client side.
I’ve never used a language that can be brought to bear from the top of the stack to the bottom with the safety that Rust brings.
That’s of course me, and I wouldn’t force others to use it. I can finally use one language for everything, and that makes me happy. It’s entirely up to you to choose your language, and if you want to use a new one that has growing communities in each of these area, Rust is a great one to choose.
Rust still has a lot to catch up on Qt, JavaFX, Android, Cocoa, Forms, WPF, UWP, Unreal, Unity, Hibernate, EF, code generation/reverse engineering from architecture modelling tools, ....
Personally, as polyglot developer, I rather use the best tool for each part of the stack.
Currently I see Rust better taylored for the low level layers that Windows, Android, macOS, iOS, MicroEJ still write in C or C++.
I see all of the gaps you mention as things that are being worked on activily. For some of the things you mention there are already decent Rust libraries: Hibernate => Deisel; Unity/Unreal => there are a bunch of things being worked on eg Piston and others (not yet fully featured of course); code generation => macros_rules! and proc macros, and custom derives can be extended to support this; javafx => yew?.
I’m not saying there are things available for all of these areas, nor am I saying that I think necessarily others should choose to rely on the language in some of these areas, unless you want to directly contribute to filling in those gaps (there are many people who are doing this). What I am saying, is that based on my experience with the language, especially in the context of Web Development, I would pick it for frontend and backend development at this point.
I agree that there are areas it really shines in right now, and if you’re working in those areas than I definitely push people in that direction. But yeah, for native GUI stuff, if you need to do more that toy stuff, it’s not ready yet.
> Do you also plan to replace SQL with Rust?
I’ve considered it! As a way of more replacing DB side procedures: https://github.com/clia/pgxr (an example of one option). What we can do with SQL is use code generators to type check the SQL at compile time.
A web service is not web development though. At least I didn't consider "web development" in the parent's sense with "running a backend REST service", but more like "running websites".
The way I'd describe Rust is, it's what C++ would have been if it used ML as a source of inspiration rather than Simula, and didn't care about preserving syntactic compatibility.
To unpack, this means that it's still a language that is very "close to the metal" in terms of lack of overhead, and broadly follows the don't-pay-for-what-you-don't-use C++ maxim. But at the same time, it's a very high-level language with lambdas and ADTs and destructuring.
Rust might be good for algorithmic trading, and is good for other real-time uses. It's good for building wasm modules. It's good for most any kind of performance sensitive or resource constrained application. If you need high throughput, low latency network services, it's good for that. CLI tools. You can build libraries to expose through C FFI, and even plug them into nodejs to do heavy lifting for existing js codebases. I think its good for anything c and c++ get used for and a lot more.
It's not that good for rapid prototyping, won't please many big enterprises who don't trust it and can't hire maintainers easily, and it can't do much on mobile phones. There are also some types of integration work where you'd be wasting your time with rust due to lack of domain specific crates.
throwing annotations on structs and letting the library generate suitable serializers and deserializers works reasonably well in Go, as long as the JSON is not too unstructured. The same applies for Java and C# (here the JSON libs might be even better). And obviously for Rust too via serde.
Maybe. However your representation isn't without drawbacks either: All fields are typed by strings, and are thereby not strongly typed. And each additional level (in an array or object) requires mandatory boxing and allocations. The codegen variants on pure structs don't have this drawbacks.
I would say your representation is favorable when someone wants to work with arbitrary JSON in a flexible fashion. However if schemas and code generators are available, I would prefer to use those.
I think "web development" is too generic to say something like that.
I'd consider a small data processing service, maybe a service invoked from the web server you're already using in Ruby or whatever, is a perfectly pleasant place to use Rust, and often likely to be 1:1 identical to those other languages.
I've been deploying Rust to AWS Lambdas for months for a side project. I chose rust because it's just my favorite language to work in - I'm very productive in it. I also really wanted predictable, solid performance, and Rust is a great fit for that.
I don't really like any of the 3 languages you mentioned though.
I honestly don't know. I primarily work in Python professionally. Java before that. I guess of that list C# seems the most tolerable but I have the least experience with it.
I'm a front-end developer, but I picked up Rust originally to do some audio processing in the browser/node - a thing that's still a little to heavy and time-critical for JavaScript.
Also the compiler is pleasant and gives you helpful advice on how to make your program compile.
It will outperform them (although not by much in the case of Go and C#), and it's also a pleasant language to use. It has a number of features like traits and enums which make it possible to expresa business logic in a way that can feel more natural than OOP classes.
It's also fantastic for reliability. In the same way that Java and C# represent a step up from python/php/js in compiler driven correctness, Rust represents another jump of similar magnitude.
Depending on what you're measuring, it can outperform Go and c# by an appreciable margin. I built http APIs in all three languages which depended on json parsing speed and PRNG speed and the Rust version was well ahead, but these were pretty naive implementations, no 3rd party PRNGs or anything.
> Does it only outperform them, or is it also a pleasant language to use?
I think you'll find a wide range of responses to this question, as personal preferences tend to vary quite a bit. For my two cents, I really enjoy using Rust, and I find myself super productive in it compared to other languages. In broad terms, I find Cargo to be miles ahead of any other build tools/language-specific package managers in terms of ergonomics, and in broad terms, I find the language to be expressive enough to save me a lot of time in having to define things I would have to in other languages and the compiler powerful enough to ensure that I don't break things when doing so. Granted, it takes time to learn how to leverage the expressiveness, and I can understand that not everyone will value this as much as things like being able to ramp up new developers quickly. I'll give the caveat that I don't actually do much web development, so my comments about expressivity/ergonomics describe the language itself and not the web ecosystem.
tl;dr Pleasant is subjective, but yes, some people (like myself!) really enjoy using it
