I am under the impression that for most web backend APIs Rust is a bit over-kill, as the majority of time is spent in HTTP request/response cycles, database IO etc. In this case mature CRUD frameworks like Django/Rails or even Play seem more appropriate. BTW I understand the benefits Rust gives you of stronger type-safety etc. vs something like Python/Ruby/JS...
However when I search for "Rust jobs" I find a lot of ads with "backend" in the description, but not much more detail. Does this mean these projects involve writing backend APIs in Rust, or rather mission/performance critical parts of the backend in Rust? Or am I simply conflating "backend" with public APIs over HTTP?
Real-world clarification would be much appreciated in terms of what people generally mean when they talk about backend Rust development.
"backend" implies that there is also a "frontend" somewhere. I'm sure you will find as many interpretations of such terms as there are applications.
In our current projects we do indeed refer to "frontend" and "backend". We use them in a way analogous to physical shops or other businesses. Shops have "shop fronts", other businesses have "front desks". They refer to such things as "back rooms". So "front" is what faces the outside world and is the interface with customers and clients. "back" is all the work going on behind the scenes that customers never get to see.
Meanwhile the "backend" is a lot of corralling and processing of data incoming from remote sensors and other machines. Communication between our servers. Databases and so on. There is a lot of Rust code in their performing performance critical work, we need good throughput and low latency, which cannot be done with the likes of node.js. Python and the like. But still we do have a lot of Python in there as well.
Performance is not the only reason for using Rust. Backends provide the ground truth and the bulk of the business logic – they should be as correct as possible, so a strict, statically-typed language can be a better choice than a dynamic scripting language.
It may be either. Jargon is not precisely-defined, unfortunately. You'll have to ask those responsible to elaborate.
The issue of REST API's and "front/back end" are orthogonal. The front end may well serve up web pages, REST API's and web socket streams to clients out in the world. In turn the back end may well serve REST API's and web socket streams to the front end.
It's API's all the way down...
To my mind a use case for Rust is in creating reliable software with high and predictable performance. That is to say all software. Front, back, sideways, on servers, on embedded systems, whatever. That is what we are doing here.
I'm not sure what you mean by "offline" there. I usually take "offline" to mean some processing that is done as a big job that has no real-time requirements. We process large amounts of data, continuously, all the time. A lot of that processing is what we call "back end". It happens out of sight of the end users. In the "back office" as they say in the physical world.
It might be. I see no reason for it though. We use Nginx at the very front of our front ends. Only acting to handle HTTPS and certs, and as a proxy passing requests on to our actual servers that are created in Rust using Rocket.
I really don't want to go back to a wobbly, poorly performing, mess of scripts created in Python or node.js or whatever.
I'm not sure that "agile" has anything to do with it. Agile is an approach to design and development. It says nothing about what language one is using.
Sure it feels so much easier and quicker to knock up a quick script in whatever scripting language. Perhaps even easier to modify such creations when they are still small code bases. This gets increasingly, and rapidly, more difficult as projects grow, especially if more than one person is working on it.
At this point you find you can have far more confidence in modifying Rust code without breaking anything. Thanks to Rust's strict type checking and lifetime checking.
Right so this is one of my motivations for exploring Rust/Go etc. and I think why a lot of Python/Ruby/JS developers are exploring it. I think we've come to a point where the majority of our "accepted" languages are not up to the task of development at scale.
The error handling is maybe better than exceptions in that you are kind of forced to deal with them up-front. That said, the compiler doesn't stop you from dealing with errors (though of course in Rust you can unwrap, but that's a bit more explicit. Further coding in Go is not fun. It's terribly monotonous, mainly because of the error handling. This constant error handling also makes it hard to visually parse.
I see plenty of run-time errors (due to null pointers) that should be caught at compile time.
In terms of typical CRUD APIS perhaps dealing with a loosey goosey language is, in the long-term, worse than having to glue more stuff together like you'd have to do with Rust as opposed to say Django.
In particular, I like the idea of having my domain model be type-checked code (as opposed to string-based descriptors loaded from who knows where, or plain English prose that is out-of-date). Having that same level of tight integration with a database would be nice, but we are not there yet AFAICT.
I'm not so experienced in Go so won't comment much. Save to say that back when node.js was the new kid on the block and both node and Go were new to me, my experiments showed that Go was not much faster than node.js for a major task we wanted to do and suffered from worse "jitters" than node.js. Not good as we needed low latency. We went with JS at the time for it's simplicity and the fact that using the same language on the server as in the browser was convenient.
I'm wondering what you mean by "glue more stuff together" there. I know noting of Django but using Rocket and a handful of other dependencies to create a REST API in Rust does not seem very onerous. Similar in fact to bolting modules together when doing the same in node.js. I personally have an aversion to overarching frameworks that end up dictating how your whole project is written.
Django handles migrations and pretty much everything else under the sun for the majority of use-cases. Another nice thing with Django/Rails is a built in admin script framework that normalizes how you'd use scripts to interact with your bootstrapped models etc. Auth and all that stuff is either built-in or there are accepted, well tested libraries. And nice for prototyping, at least in Django, is a pretty powerful admin GUI interface for your models. I wouldn't want to write that all by hand. I did an experiment with Go that required me to do much more hand-coding and I gave up trying to prove to my boss that it was worth it. Perhaps the story with Rust is better, or I am over-estimating the convenience of these items, but they are things I have used over and over again in the real world.
I am open to being wrong, as always, and believe would love to use a more robust language even for prototyping. The problem with prototyping is it often becomes production code.
We live in different worlds. I don't even have any idea what "normalizes how you'd use scripts to interact with your bootstrapped models" might mean.
As such I can't comment on the state of whatever is available in Rust to perform the functionality of the frameworks you mention. I suspect it is not there yet.
Except I feel that it is not a good idea to give up whatever you have and start rewriting it all in Rust just for the sake of adopting a new language. Not unless what you have now really does not meet the requirements you have. Not unless you really want to take on such a framework in Rust as a project in itself.
Likely a "softly softly" approach would help. If the is some small part of your system that underperforms or gives endless problems with bugs and such, then it is a candidate for reimplementing in Rust. If that works out then you have a case for tackling other components with similar issues or new components. The point being there has to be a valid and convincing reason for switching to Rust here and there rather than demolishing the whole house and starting over again.
Pretty much always. Actually I think all code that has made it to production is still prototype code. It's the prototype for the next release. Things can change majorly between releases. And so on, until the product is unmaintained, unused and dead. Or its a prototype for your next project.
I wouldn't think of re-writing for the sake of rewriting. I am just exploring Rust as I have very little experience with languages like C and Rust. I actually started teaching myself a bit of C, going through some book just so I'd understand better what problems Rust is trying to address.
On a separate note I'm kind of tired of developing the same thing over and over--that is full stack web development for typical web apps/mobile. Apart from being tired of solving the same thing over and over again, the culture of web development tends to be loosey goosey, even with some improvements like TypeScript. I think this may be partially because it tends to draw people with less of a CS focus. It may also be a relic from the early days of the Web when the browser just wasn't a mature development environment.
Suffice to say I am also looking to get into another development field...I'm just not sure what yet. Some kind of lower-level Systems Programming. I like what I see from Rust so far because it doesn't let you get away with crap, can operate closer to the machine, yet has great tooling (Cargo etc.), fantastic documentation, and great elements from the functional world, including Result/Option enums etc.