Thank you. Well, if the USA does the opposite then all apps and research will be moved overseas.
This is a complicated topic and I don't know the right answer. I hope people with far greater skills in IP can figure out a meaningful solution that everyone doesn't hate. It might be that there is no good solution.
But TBH, in a Rust world, it’s worth revisiting the assumptions behind the ROS node architecture, since Rust is so strong at scaling to large monolithic applications (due to the strict hierarchical code patterns it encourages).
A transitional Rust approach, that doesn't try to reimplement everything from scratch, could do something like a strangler pattern: Take each ROS node, run them separately in “jails” with a Rust API around each one, then implement the plumbing/management logic in pure Rust.
Yeah the ROS node architecture sucks. However, one reason for that design was so that you can run ROS on distributed systems where things communicate to each other over the network.
Actually another reason people use the architecture is for process level isolation, i.e. limiting the blast radius of memory corruption. But in both cases, Im sure you could design an ergonomic RPC framework that takes care of offloading computation mostly transparently behind the scenes :)
One advantage of async/await is that its easier to cancel things. For example, this leads to the design pattern where you have multiple futures and you want to select the one that finishes first and cancel the rest.
In regular threaded programming, cancellation is a bit more painful as you need to have some type of cancellation token used each time the thread waits for something. This a) is more verbose and b) can lead to bugs where you forget to implement the cancellation logic.
>In regular threaded programming, cancellation is a bit more painful
No, it isn't. Nothing is stopping your threading library from implementing the same thing. It just turns out it is a bad idea to kill threads at random points in time because they may own things like locks. Or in the case of async await doing something that is thought to be atomic.
You're describing exactly why it's painful for threads. If you only cancel co-routines at yield points (which unless you do dark magic is the only time you can cancel them) is always safe.
A co-routine that yields in the middle of an atomic operation is an oxymoron. Anything can happen before you're scheduled again.
Well each time you use the await keyword you are saying its a safe point to exit, which is more predictable than killing at random points. Holding locks across await points is an anti-pattern, and Rust at least can give a hint if you try to do that. Async/await implementations will also generally allow you to run cleanup code on cancellation (but the exact mechanism depends on the language).
In the end, its about expressing a state machine in a more concise implicit way, which is a suitable level of abstraction for most use cases.
> One advantage of async/await is that its easier to cancel things. For example, this leads to the design pattern where you have multiple futures and you want to select the one that finishes first and cancel the rest.
> In regular threaded programming, cancellation is a bit more painful as you need to have some type of cancellation token used each time the thread waits for something. This a) is more verbose and b) can lead to bugs where you forget to implement the cancellation logic.
Yeah of course Rust just makes cancellation so easy by allowing the Futures to be dropped. What about the resources these Futures could have allocated within the context that are not just memory? You are saying it as if async/await somehow solved the whole problem of stack unwinding.
Since rust follows RAII, any and all resources allocated in the context should be deallocated when their destructor (the drop trait) is called. The unfortunate exception to this are resources which require an async call to deallocate properly. Though this can be worked around and there is work being done to fix this properly.
> Since rust follows RAII, any and all resources allocated in the context should be deallocated when their destructor (the drop trait) is called. The unfortunate exception to this are resources which require an async call to deallocate properly. Though this can be worked around and there is work being done to fix this properly.
Yeah as I said async does not, in fact, "provide easily cancellable execution patterns".
only if the resources are just used within this task. If an async function at some point in time generates another task (or even spawns a thread!) that can not be synchronously cancelled then it might outlive the destructor and thereby the async task. It's therefore nowhere near guaranteed that every Future can just be dropped to stop an action in a side-effect free fashion.
I think the comment was about async in general, not just Rust (although that's the topic of OP).
In Python, cancellation causes an exception to be injected at the await site, which allows it to clean up whatever resources it likes (even if that means making other async calls). If you use Trio or the new TaskGroup in asyncio (inspired by Trio) then an exception leaking out of one task causes the others to be cancelled, and then the task group waits for all tasks to complete (successfully, with exception, or cancelled). It's extremely nice and easy to write reliable programs.
In principle, I think many of these ideas could be applied to threaded IO. But I haven't seen it done in practice.
> In principle, I think many of these ideas could be applied to threaded IO.
That's how POSIX deferred [1] cancellation works. An uncatchable exception is thrown from blocking calls if a thread is requested to terminate. As POSIX is C centered, you can imagine that handling exceptions was never popular, but it should work fine in C++. For some reasons it wasn't added to std::thread though.
[1] there is also async cancellation, but friends do not let friends use PTHREAD_CANCEL_ASYNCHRONOUS.
> In Python, cancellation causes an exception to be injected at the await site, which allows it to clean up whatever resources it likes (even if that means making other async calls). If you use Trio or the new TaskGroup in asyncio (inspired by Trio) then an exception leaking out of one task causes the others to be cancelled, and then the task group waits for all tasks to complete (successfully, with exception, or cancelled). It's extremely nice and easy to write reliable programs.
There are a few options I’ve seen for “liveview” type approaches in Python, see e.g. reactpy and streamlit. (Assuming you are not looking specifically for something that transpiles to JS.)
Hi is there any plan to have high level model training tools (one example is things like Pytorch dataset loaders), or is the focus more on inference/deployment use cases?
I've read that, but am not convinced. It's very dependent on the particulars of the situation, the goals, the acceptable losses, and the belligerent forces.
A couple of situations:
1) Tyrannical government or Upstart AI wants to destroy dug in and dispersed local militias. Government will use existing military delivery technologies. AI will use non-human elements so blowback is not a concern. It seems here that gas is cheaper than bombs or bullets.
2) Upstart State or AI wants to do a surprise attack to depopulate or logisticall overwhelm a strategic city. Civilian casualties are desired. Again, gas seems like a clear win, here.
The idea that militaries have NBC protection that will just negate chem/bio warfare is a bit of a dream. The operational friction from having to use all that protective gear and protocols would be huge. Even just little things like not being able to aim properly through a rifle scope depending on which gas mask you're wearing. Also don't underestimate the fear/terror/shock factor of being on the receiving end of this horrible stuff.
The future isn't pretty, unless we can figure out a way to settle down and coexist.
There are also important questions about warning time and strategic responses.
Let's say an upstart AI or group decide to wipe out humanity, or at least a country or continent. What is the time from initial detection to the realization that we as humans are at the end of the world? What do we do then? Do we nuke someone? Something? Everyone?
Any upstart taking over the world strategy is going to have to grapple with this. Chemical weapons have immediate effects. Bio-weapons will take time to spread - time during which they could be detected and possibly mitigated.
I'm sure a lot of actors have taken note of COVID-19's asymptomatic transmission. I'm sure people are thinking of bio binary weapons. Step 1) Silently infect the target population. Step 2) Flip the kill switch and they all die simultaneously.
Maybe variational inference is a possibility? You can try searching for black box stochastic gradient variational inference, easy to use and scales well.
https://docs.rs/itertools/latest/itertools/trait.Itertools.h...