Rusky

42 ms·

421.
by Rusky 7y ago
> Depending on your FFI, if you don't allow the FFI code to hold pointers into you language's stack, you're all good. Rust does this with virtually all FFI.
422.
by Rusky 7y ago
First-class continuations are too unrestricted to match the performance of Rust-style async/await. If you take on a few limitations you can get there, but then those are exactly the things people complain about.
423.
by Rusky 7y ago
An implementation of green threads-style register saving cannot be as memory-efficient as async/await, because it's more dynamic. Green threads must save all (callee-save) registers, support arbitrary dynamic stack growth, and wor
424.
by Rusky 7y ago
It's not the same, but Rust async/await tasks are also in the order of bytes, and you can get similar "structured concurrency"-like control flow with things like `futures::join!` or `futures::select!`. Ceu looks very nea
425.
by Rusky 7y ago
Yes, that's the usual workaround.
426.
by Rusky 7y ago
You do not create a thread for each- that would defeat most of the purpose of futures. Instead you call `Future::poll`, which runs a future until it blocks again, and provide it a way to signal when it is ready. That signal would be handed
427.
by Rusky 7y ago
Fortunately, `futures::join!` isn't provided by Rust- it's provided by library code. I am not aware (off the top of my head) of an existing equivalent to your `Promise.map` example, but it is also implementable in userspace in Rus
428.
by Rusky 7y ago
> futures are tasks run on some other thread. This is usually false, in Rust and elsewhere. Futures are tasks that run on whatever thread is scheduling them. They are an even lighter-weight version of green threads/fibers/M:N
429.
by Rusky 7y ago
Javascript has two differences that contribute here: * First, it runs the callee synchronously until the first await, which can fire off network requests, etc. * Second, continuations are pushed onto queues immediately- the microtask queue
430.
by Rusky 7y ago
It gets you to the network's captive portal.
431.
by Rusky 7y ago
The reason for this requirement is lifetime subtyping: https://doc.rust-lang.org/nomicon/subtyping.html Type parameter variance is inferred from usage (e.g. covariant for normal fields, contravariant for function argum
432.
by Rusky 7y ago
It generalizes to arbitrary state machines- check out the reference near the end to session types. Each state is a type, methods consume their receiver (the "move state") and return the new state. You can't accidentally keep
433.
by Rusky 7y ago
That example is generated by a macro, not part of anyone's actual program source...
434.
by Rusky 7y ago
Kotlin coroutines are just async/await with different syntactic defaults. That is, when you call a `suspend fun` it is awaited by default, and if you want to get a promise/future/etc from it instead that's when you wri
435.
by Rusky 7y ago
In that particular example you won't get boxes of boxes- `baz` gets instantiated for each impl of `Baz`, so the call to `self.foo()` is resolved statically and the return type is fully known.
436.
by Rusky 7y ago
VS mixed mode debugging doesn't need language support. You can already call back and forth between Rust and C# and the debugger will handle it fine.
437.
by Rusky 7y ago
Rust has some of the best Windows support, in my experience. It uses native ABIs and object/debuginfo formats (not MinGW), and I debug it from Visual Studio.
438.
by Rusky 7y ago
The post isn't talking about the drop method of the Drop trait, which is used to hook into the drop functionally. It's talking instead about std::mem::drop, a standard library function that drops a value before it would ordinarily
439.
by Rusky 7y ago
This is not correct; moves must leave the value in a valid state, because its destructor will still run. The correct version is actually the same as Rust's: template <class T> void drop(T) {} (Moving into a local in
440.
by Rusky 7y ago
Rust does have safe static variables. You just need a) to use interior mutability (`static mut` is a very strange feature that should probably never have existed) and b) to ensure that its type is `Sync` (since multiple threads can obtain r
441.
by Rusky 7y ago
It would still not work. All std::move does is cast to T&&, enabling overload resolution to pick a function with T&& as its parameter type.
442.
by Rusky 7y ago
It is not an exception; #[may_dangle] does not change the time drop runs. All it does is promise that drop will not access borrowed data, allowing that data to die before drop: https://doc.rust-lang.org/nightly/nomico
443.
by Rusky 7y ago
This is incorrect. Values still go out of scope and have their destructors run at the same time. NLL only affects values without destructors.
444.
by Rusky 7y ago
Yes, you're missing that the type `T&&` is a reference, not a value, and so does not run the object's destructor when it goes out of scope.
445.
by Rusky 7y ago
NLL does not change those semantics; drop still runs at the end of the scope. It counts as a "use" for the purposes of NLL and thus keeps values with destructors alive.
446.
by Rusky 7y ago
You don't even need "not the most optimum implementation" (assuming you're talking about index-based graphs or something). You can make non-leaking pointer-based graphs in safe Rust using reference counting (basically wh
447.
by Rusky 7y ago
That's the common case, but you can still make a reference counting cycle, or have a thread hang while holding onto something, or even just call `mem::forget` on an allocation. This is different from Rust's guarantees about memory
448.
by Rusky 7y ago
You deal with this in a Rust kernel in exactly the same way you deal with it in a C kernel: by using different APIs for allocation. Linux doesn't use malloc; a Rust kernel need not use Box::new either.
449.
by Rusky 7y ago
Some async runtime libraries have started offering an attribute on `fn main` to make it async, which is pretty close to the same thing.
450.
by Rusky 7y ago
That's true, and it's why the alternative to GC is generally not "malloc and free" or "RAII" but "custom allocators." Games are very friendly to that approach- with a bit of thought you can use arenas

More ›