Rusky

58 ms·

361.
by Rusky 6y ago
I would argue that "a data race that doesn't cause a race condition" is still, itself, a tiny race condition- just a contained one. But you're right, this is just choice of terminology. :)
362.
by Rusky 6y ago
Futures are part of the answer, and more specifically the way that the Wakers passed to Future::poll use dynamic dispatch to re-schedule the task. Other major abstractions that are missing so far include async versions of the Read and Write
363.
by Rusky 6y ago
Data races are a kind of race condition, no?
364.
by Rusky 6y ago
It's possible, the downsides are a bit silly when you look at how the Future trait was designed to allow tasks to be runtime-agnostic. There is ongoing work to standardize more runtime interfaces so that more libraries can be runtime-a
365.
by Rusky 6y ago
Right, a Rust lambda is not a COM object on its own, but by the same token you can't just stash one in a COM object's property either- COM object properties don't have a type for "Rust lambda," or "C++ lambda&q
366.
by Rusky 6y ago
The raw pointers are wrapped in `ComPtr` defined here: https://github.com/microsoft/winrt-rs/blob/master/src/com_pt... Those `ComPtr`s are then wrapped in convenience types that handle method dispat
367.
by Rusky 6y ago
It works fine- Rust only forbids multiple `&mut T`s to the same object, but `&mut T` doesn't exist outside of Rust, so code in other languages doesn't have to care about that rule at all. These bindings can just expose non
368.
by Rusky 6y ago
A lot of WinRT APIs are usable from "normal" desktop win32 apps, but some are restricted to the sandboxed/appx/etc model. The most prominent of these is probably the XAML GUI stuff, but those are becoming available every
369.
by Rusky 6y ago
> Even if your pretty familiar with rust you still have to break it apart and explicitly place the types in the "Let" statements to know the intermediate types in order to look up the method documentation. Maybe this is just me
370.
by Rusky 6y ago
It could potentially do that, but there are a lot of things that "normal" monomorphized generic code can do (and does routinely) that would be very very difficult to implement dynamically. This post goes into a lot of detail on th
371.
by Rusky 6y ago
It's hardly esoteric when it affects some of the most common (and commonly-inlined) methods in the entire language, which are a large part of Rust's unique idioms.
372.
by Rusky 6y ago
Modern C++ is in a similar situation with iterators, indexing, etc. and it's still often faster for LLVM to get through. MIR optimization can help close the gap but that still involved generating "garbage" that takes extra ti
373.
by Rusky 6y ago
Part of it may be code style, but another part comes from just how much LLVM IR the frontend generates for just about any code style. Part of the reason LLVM runs so much faster on C than on Rust is that Clang is smarter about generating le
374.
by Rusky 7y ago
Much of the performance problem comes from layers on top of NTFS itself- it's not just the virus scanner. Ext4 might be faster but I doubt it would be enough to ditch WSL2 for those use cases that need it.
375.
by Rusky 7y ago
> I couldn't bother to decipher how paths and `extern crate` had changed. I don't know if you're looking for this, or if it will help, but here's the way I think of it: In 2015, `use` paths are relative to the root mo
376.
by Rusky 7y ago
> The cognitive impact is directly proportional to how easily we can abstract the changes into a coherent story. Exactly! This is how language and API changes are usually designed , and announcing them the same way is a great idea.
377.
by Rusky 7y ago
QUIC no longer includes HTTP, so "of course not" is a bit strong. It's easily applicable to a lot more scenarios than HTTPS over TCP.
378.
by Rusky 7y ago
I'm not a Linux kernel developer, but it does have a few similar mechanisms AFAIU. If a driver needs to perform more work in response to an interrupt than would fit into the actual handler, it can use cooperatively scheduled "task
379.
by Rusky 7y ago
As I originally pointed out, the difference between C++ and C++/CLI is that C++/CLI is not just a superset of standard C++. Things are changed or missing, not just added. You can't just take a pre-existing standard C++ progra
380.
by Rusky 7y ago
You don't have to use emscripten or its language extensions to build C or C++ for WebAssembly. And in the other direction, emscripten's raison d'etre is unmodified C and C++, by providing the platform APIs those unmodified
381.
by Rusky 7y ago
The CLR is not "most other VMs." You might say it's the exception that proves the rule. ;) Further, as I've pointed out to you before, the CLR does not really support unmodified C and C++ as well as WebAssembly does. I
382.
by Rusky 7y ago
> Presumably WebAssembly would end up with a persistent model, as well, if the GC model went deep enough. That's not going to happen. The primary point of WebAssembly GC support is for integration with the host, with GC for the gues
383.
by Rusky 7y ago
That was done entirely on purpose, to make validation simpler. It does make things harder for compilers that want to support irreducible control flow, but the workaround is a single "relooper" algorithm that doesn't really fu
384.
by Rusky 7y ago
I believe they're using BIOS in a more general sense. You're right that UEFI replaces the old BIOS APIs that bootloaders used, but there's still firmware (e.g. coreboot) below or part of its newer APIs.
385.
by Rusky 7y ago
Rust still has some room to improve over C++ here. Because it knows up-front which operations generic code can use on its type parameters, it can do things like "polymorphization": https://github.com/rust-lang&#x
386.
by Rusky 7y ago
> Also, fool me once... To be fair, their past offerings still work fine, they're just in maintenance mode. Which is exactly what a lot of people want- they stop changing and everything you built with them just keeps working.
387.
by Rusky 7y ago
The problem with that approach is it inhibits a lot of perfectly-sensible optimizations. If you force the compiler to leave it up to the machine, you force it to preserve the same stack layout, the same memory write, and the same execution
388.
by Rusky 7y ago
You're not wrong, I wrote off the insubstantial stuff as rhetorical and started my comment with "being generous." :P But on the other hand, even some of these less-helpful points have an element of truth: * A lot of people&#x
389.
by Rusky 7y ago
To the contrary, modern C++ has solved very few, if any, of the problems described in the article. Being generous: * There's now `std::string_view` to address some of the problems with `std::string`, but the rest are still there. The
390.
by Rusky 7y ago
GraalVM does support low level languages, and that's one of the most impressive things about it. For example, TruffleRuby runs both Ruby and its associated C extensions on it, bringing major performance improvements due to sharing an o

More ›