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?
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.
If anyone likes to compare apples with oranges and benchmarking web frameworks, actix-web framework (optimised for benchmarking, naturally) is leading in many categories: https://www.techempower.com/benchmarks/#section=data-r17&hw=...
With actix-web, you can run asyncio and sync code in the same server. It lets you take full advantage of Rust's concurrency.
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(|_| ())`).
Will actix-web become obsolete or be replaced when Rust releases async/await in 2019?
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.
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:
https://blog.sentry.io/2016/10/19/fixing-python-performance-...
Performance is great, but the breadth of usage enabled by the small run-time (including no GC) makes it more exciting.
* 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
We have a partial list of companies that describe their usage here: https://www.rust-lang.org/en-US/friends.html
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.
I had no idea rust was that prevalent
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.
Rust is competing with C and C++.
Yes, maybe not on a satellite's firmware, but on a Gemalto firmware, certainly.
https://www.gemalto.com/m2m/solutions/modules-terminals/indu...
https://www.gemalto.com/m2m/solutions/modules-terminals/indu...
Just two examples from their portfolio.
Naturally it depends on how much memory is available and real time constraints.
However something like MicroEJ is already happy with an ESP32 variant, and I guess Rust could replace its C layer.
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.
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).
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.
> 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?
Cyclone, Safe C, Checked C, static analyzers deliver with the compiler, ...
The problem is on the receiving end, some devs won't change no matter what.
So far Android and Solaris (SPARC) seem to be the only platforms with memory validation compilation turned on.
* 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.
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.
[1] https://github.com/rust-lang/rfcs/pull/2592
[2] https://github.com/rust-lang-nursery/futures-rs/blob/master/...
I personally wouldn’t build a website in Rust, but a webserver? Yeah, maybe.
-> 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).
(at the moment, it's tightly coupled to our game, however)
Who said it should be picked for web development?
It's however good for systems programming, libraries, embedded, data crunching, network systems, and so on...
These perhaps?:
https://github.com/SergioBenitez/Rocket
https://github.com/actix/actix-web
https://github.com/carllerche/tower-web
Not saying that is the primary use, but still a valid question as long as these libraries are being built/pushed.
I think things are much more viable for "services" rather than "sites" right now. And the npm thing is a service.
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.
I have many hammers, one for small nails, on for large nails, a rubber one for joining things, even large sledge hammers. Each has its job.
But if I could only have one, that was flexible enough to use across all situations where I need to hit things, that would be great.
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++.
Do you also plan to replace SQL with Rust?
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.
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.
Had Bjarne not taken that decision and C++ would having drinks with Modula-2, Pascal, Oberon and others.
So it was both a bless and a curse.
Rust seems to be increasingly adopted in spite of being different, so lets see when it gets a nice OS SDK sweet spot.
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.
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.
enum Value { Null, Bool(bool), Number(Number), String(String), Array(Vec<Value>), Object(Map<String, Value>), }
How would this look in Go?
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 don't really like any of the 3 languages you mentioned though.
Also the compiler is pleasant and gives you helpful advice on how to make your program compile.
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.
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