For reference I have over a decade of JavaScript experience in industry and my async Rust rewrite of a large JS project was *more* concise then the heavily refactored and polished NodeJS version (a language I consider more concise then most). If you are having to copy and paste excessively in Rust that is an issue but it is not necessarily intrinsic to the language.
For what it's worth traits largely prevented copy and paste and where traits fail there are macros. The classic inheritance example you link to is a tiny percentage of my code and an orders of magnitude smaller time sink when compared to the code maintenance problems I faced in other languages.
I tunnel everything through webRTC. It's a bit exotic but it gets you a direct bidirectional data connection to the self hosted device. You can put all users' self hosted content through a single domain name & SSL cert or you could have subdomains automatically provisioned for each device.
I look forward to the day everyone can have IPV6. For now many of us still have to deal with NAT sadly - especially if we're open sourcing our software for users to deploy on any network.
The Makerbot Automated Build Platform was terrible in many ways so an eternity ago I forked ReplicatorG and got it printing continuously from a queue.
Once I did that I really appreciated being able to leave my printer running all day and have it produce bins full of parts. I especially appreciated being able to add prints to the queue while iterating on my CAD designs.
So, shameless plug: Inspired by that experience with the Makerbot I've been writing an entirely new print conveyor-ready print queue for the raspberry pi. Coming this fall at https://tegapp.io/
Ok, 3rd edit. The promises are awaited in sequence but since they are both started before the first await they are run in parallel.
Your question about Rust futures makes a ton more sense now. This only works because a promise is self-executing / not inert like a Rust Future. Thank you kind stranger! Your async-foo is strong ^_^
So basically the question as it's asked doesn't make sense as I understand Rust and if someone took that to be intentional could be interpreted as language FUD (which could then deserve a down vote). An update to prevent the spread of misinformation about the language would be cool.
PS. I've only been using Rust on the daily for the last 8 months so I am by no means an expert. If there is a reason for your assertions that I'm missing I'd like to know. Thnx!
I could be wrong but I interpreted the down votes as about incorrectly equating of Rust and C++ allocations. There are a few replies that address this better then I can (I'm limited here in that I grok Rust but not C++) but I believe the comment would have been more correct to draw similarities between C and Rust explicit allocation then C++ and Rust.
I'm in a similar boat with regards to launching a new, unknown product in the snap store. As an interim solution I'm planning to ask users to do use the beta flag: `snap install my-app --beta` which gets me around the secure sandbox requirements.
Very cool to see more people experimenting in this area. I've similarly implemented GraphQL over WebRTC for https://tegapp.io/ and had great initial success 3D printing over data channels.
One thing I didn't immediately see in this code (excuse me if I just missed it - this was a quick read through) is a chunking mechanism to limit data channel messages to their 2^16 byte maximum. If your looking for a drop in solution saltryrtc has something you might be able to use: https://github.com/saltyrtc/chunked-dc-js
GRPC and similarly GraphQL over WebRTC gets you a long ways towards controlling local servers over the net however the problem of how to handle signalling in a way that works both online and offline is still a big hurdle. Personally, I'm pretty excited to see where these WebRTC servers can go with DAT and IPFS decentralized signalling solutions.
For what it's worth traits largely prevented copy and paste and where traits fail there are macros. The classic inheritance example you link to is a tiny percentage of my code and an orders of magnitude smaller time sink when compared to the code maintenance problems I faced in other languages.