It just seems like an odd use case for rust. I can see how it would be attractive as an alternative to c++ or other systems language. But for shuffling data?
Also, since you mentioned PostgreSQL, if you can make the db handle json the shuffling part should be really trivial. Give node.js + pg-promise a spin for comparison.
But then again, I haven't used Rust for anything serious, so am happy to be wrong.
1. rust handle erros in a VERY expressive way, and I do want my services to log ANY errors, and to be sure to miss any (kind of like what go permits too , but Rust Errors are more flexible) , so with rust it's hard to forgot a case of error and finished with "errr my API did a 500 but i don't know why"
2. It's a (nearly) self contained binary with low memory overhead, I can have dozen of microservices like this on my workstation / CI environments without making the machine cries
So I can deploy it on cloud provider X or workstation Y without needing to worry if it has the version of node / python / php I need
3. it creates very small docker image if you're using docker
(so it beats node/python/php here)
4. if I want to make my services multi-threaded and have some internal cache for some reason I'm sure the compiler will not let me create concurrent access problem that I would otherwise only detect in production when it's too late (beats every other languages , including go , the go race detector of go is nice, but it's at runtime so not the same league)
5. no nil pointer exception things (beat other languages here too)
6. strong typing but flexible (no go, I don't want to cast everything in {}interface everytime i need to make things a bit more generic, though I know it's just a personnal opinion), because no I don't want my developer to either develop a "is_true" function , or worst to rely on type casting for if to work.
7. the compiler as my first set of test
it's a whole category of things you don't need to write test for because it's already handled by the compiler.
8. highlevel when you needs, low level when you want, I know that the language is not my bottleneck (or then I've reached the point where I don't care because my system is performant enough) , but if I need to serialize my struct into a json, I can in some line of codes.
9. plenty other little things , like scoping variables, immutable by default , possibility to have your SQL request check at compile time if you use postgresql plugin, using first-class debuggers to do step by step if you need , interfacing with C libraries pretty easily
Your above reasons why for Rust basically all apply to Haskell too, except it's higher level and garbage collected, which is why I think Haskell is the best language to write a web service in.
But, you could write embedded software, device drivers and even operating systems in Rust, that's the domain where Rust could and hopefully will dominate.
Like all things in life, higher abstraction level of Haskell is not free. The price is more complex language (which many people don't have the capacity to properly learn) and less predictable runtime behaviour.
As a self-taught programmer who's getting pretty comfortable with Haskell and also starting to dive into low-level languages (C, x86, Rust) I don't think Haskell is that conceptually complex. It's very abstract but it's also quite consistent. Because its semantics are designed around mathematical laws rather than shuffling bits between CPU registers and RAM, it doesn't have a lot of gotchas, WTFs, special cases, or safety rules to keep in your head. In Haskell, everything is an expression, all functions are closures, and all bindings are recursive, which means that you can inline or extract out expressions with incredible freedom, which makes refactoring so much easier.
Yes the runtime behavior is definitely less predictable with lazy evaluation, which is fine for web servers but terrible for systems programming.
I've always liked the idea of using "systems" languages for data shuffling, because of the ability in some cases to stretch hardware several orders of magnitude further. I read this a while ago and just dug it up:
It's a bit silly, but I do think that Rust could be a very good solution here. For one thing, in my experience it is much easier to write than C++, especially for something you'd feel comfortable pointing at users.
It would be cool to see some articles that are the reverse of "scale all the things," something like "sympathize with all the caches."
Writing a web server from scratch in an unsafe language seems like an invitation to get hacked to me. So maybe in Rust this would make sense, but C++ is a dangerous proposition, I think.
People often talk about scaling in a lopsided manner. Meaning scaling is only up, well scaling works both directions. For an architecture or runtime to be scalable, it needs to shrink as the demands placed on it fall. Scalability works in both directions.
Yes and no. Realistically you often have other constraints. E.g. for a lot of code I wrote at my last^2 job there would be no value in scaling below a single micro EC2 instance (I ran each service on its own instance and got value out of doing so), and almost all languages can scale down that far.
I agree here. I'm often attracted to new stuff, so working with something new (like Rust) would be a plus in a job description, but I also think is the wrong tool for this kind of task - which would yield a minus for the job description.
This is the classic domain of scripting languages (PHP, Ruby, node, ...), where a huge ecosystem exactly for this kind of tasks exists. But yes, type safety and error handling is not the best there.
If a good type system and a good ecosytem is desired then F# or a JVM language (Scala with Play Framework, Kotlin, ...) could be used, which would from my perspective give a more productive setup for this task.
I don't want to say that Rust is not good, but (just like C++) I think it's best use cases are other applications then webservers, e.g. high performance audio and video processing or bare metal software.
Also, since you mentioned PostgreSQL, if you can make the db handle json the shuffling part should be really trivial. Give node.js + pg-promise a spin for comparison.
But then again, I haven't used Rust for anything serious, so am happy to be wrong.