3 ms·

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? A

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.

dikaiosune 11y ago
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: http://stevehanov.ca/blog/index.php?id=95 http://stevehanov.ca/blog/index.php?id=95 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."
- Rusky 11y ago
  A blog I've really enjoyed on that subject is Mechanical Sympathy: http://mechanical-sympathy.blogspot.com/ http://mechanical-sympathy.blogspot.com/
  - nickpsecurity 11y ago
    First thing I see is an encoder and list of good design rules. This blog could be a gold mine if other articles are similar. Thanks for the link.
  - ddorian43 11y ago
    Also the forum https://groups.google.com/forum/#!forum/mechanical-sympathy https://groups.google.com/forum/#!forum/mechanical-sympathy
- sitkack 11y ago
  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.
  - lmm 11y ago
    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.
- adrianN 11y ago
  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.
allan_s 11y ago
Rust made sense for me for that case because: 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
- kyllo 11y ago
  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.
Matthias247 11y ago
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.
- ossreality 11y ago
  This comment is hilarious to me. How the fuck is F# more suited for services than Rust? I don't even know where to start.

dikaiosune 11y ago

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: http://stevehanov.ca/blog/index.php?id=95 http://stevehanov.ca/blog/index.php?id=95 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."

Rusky 11y ago
A blog I've really enjoyed on that subject is Mechanical Sympathy: http://mechanical-sympathy.blogspot.com/ http://mechanical-sympathy.blogspot.com/
- nickpsecurity 11y ago
  First thing I see is an encoder and list of good design rules. This blog could be a gold mine if other articles are similar. Thanks for the link.
- ddorian43 11y ago
  Also the forum https://groups.google.com/forum/#!forum/mechanical-sympathy https://groups.google.com/forum/#!forum/mechanical-sympathy
sitkack 11y ago
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.
- lmm 11y ago
  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.
adrianN 11y ago
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.

allan_s 11y ago

Rust made sense for me for that case because: 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

kyllo 11y ago
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.

Matthias247 11y ago

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.

ossreality 11y ago
This comment is hilarious to me. How the fuck is F# more suited for services than Rust? I don't even know where to start.