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've designed this project in Go following Go naturally imposed design patterns and found that I did not need inheritance.", said the Go programmer.
"Well, mmm, duh?", thought programmers of other languages.
"I've designed this project in Rust, following Rust-imposed design principles, and found monomorphism sufficient", said the Rust programmer.
"Well, mmm, duh?", thought programmers of other languages.
"I've designed this project in Python, using Python-style design and I've found that I did not need strictly typed functions", said the Python programmer.
"Well, mmm, duh?", thought programmers of other languages.
"I've designed this project in language X, which impose Y and as such I've found that you actually don't need Z", said the X programmer.
"Well, we got the picture already", said the HN reader.
Absolutely, but the interesting bits are in the metrics. How many lines of code does it take in each language? How many distinct concepts are required for the solution? To what degree is the mastery of each concept required?
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.
Everyone can have IPv6 today by using a tunnelbroker.
I used the free tunnel from https://www.he.net/ in the past, when I didn't have native v6. Today I don't need it anymore.
There's a comment above that indicates tunnel brokering can't handle NAT situations (at least CGNAT).
RFC3053[0] seems to indicate this can be a problem as well:
> 3. Known limitations
This mechanism may not work if the user is using private IPv4
addresses behind a NAT box.
Are you saying it works even behind a NAT?
EDIT: According to HE's own FAQ[1]:
> If you are using a NAT (Network Address Translation) appliance, please make sure it allows and forwards IP protocol 41.
That doesn't sound like something most ISPs are likely to support. Not sure about home routers but if it has to be configured manually we're back to square one.
I don't know exactly anymore, because I'm now with a different ISP which natively supports v6. So can't reproduce.
I mean I (probably) could, but don't want to, because now I have IPv4 via CGNAT, but not with a private IP, a public dynamic one probably shared with who knows how many others.
But I can use IPSEC/OpenVPN/Wireguard to somewhere else with that. Though my CPE supports GRE.
Anyways, there are large implementation differences in CGNAT from ISP to ISP and even different access technologies within the same.
What do you mean by that exactly? Initially it's just an outgoing tunnel to one of their many exits, to reach any site which is reachable via v6. How you integrate that into your setup is up to you. Since they are (one of?) the pioneers you have many scripts available on many platforms which support that.
When you mean incoming tunnel, it's no different from the many dynamic DNS solutions, where it's again up to you to integrate that. But even for this they have something:
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/
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.
Judging from your comment history, are you perhaps used to writing asynchronous code in Rust? In most languages, `Futures` start executing from when they are spawned. This is opposed to Rust, where they execute when they are `.await`ed.
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 ^_^
IIUC, work to be done for a promise is (typically) placed in the task queue when the promise is created, and will be eligible to start running the next time you get back to the event loop, which is part of what an `await` does.
The asynchronous portion of the work is enqueued when the function is called, but does not start executing until it's scheduled, which can't happen until the current task ends or is blocked by an await. This is useful, as it means a promise can't settle before you've had a chance to add handlers; otherwise you might sometimes get UnhandledPromiseRejections because of an unavoidable race condition.
I said arguably correct because there's nothing stopping the function from doing a portion of the work synchronously, which would mean the work as a whole starts with the function call.
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.
Just wanted to easy one worry of you: the age, popularity and maturity of your application has no influence on whether or not these permission requests are granted. The approval process is formally defined and mostly depends on what your application does exactly.
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.