Rusky

49 ms·

481.
by Rusky 7y ago
The article covers this, they have further plans for existing installs.
482.
by Rusky 7y ago
> The only reason I can see is in ensuring that text is losslessly convertible to other UTFs, particularly UTF-16 (which exists for historical reasons), but this just seems like a matter of when the information is lost (is it during conv
483.
by Rusky 7y ago
It doesn't do anything locally but it does (as part of going back to the executor) let arbitrary other code run, which is basically what a method call does.
484.
by Rusky 7y ago
> My impression of async/await is that it’s one part of making concurrency grokkable, and I’m not sure whether the debate was taking all that into account That's a different question than "where does the await go" and
485.
by Rusky 7y ago
If we're gonna have await share syntax with some other language feature, method syntax is IMO better than field syntax- it semantically blocks the function until the callee is complete, it evaluates to a temporary instead of an lvalue,
486.
by Rusky 7y ago
Here's the proposal: https://internals.rust-lang.org/t/explicit-future-constructi... One of the goals behind it was to align async control flow with sync/thread-based control flow, to make it more intuitively
487.
by Rusky 7y ago
The point of the article is that you can get that same declarative interface at much lower cost, with a more efficient implementation.
488.
by Rusky 7y ago
Better performance than completely recreating the DOM, sure. But all the time spent constructing and diffing the virtual DOM is pure overhead compared to simply doing that 1 real transformation directly.
489.
by Rusky 7y ago
> 4. Official C++ extension despite being completely useless consumes several gigabytes of space for "indexed" files (I wonder if it is so bad to not hurt sales of Visual Studio). I chuckled at this, because the implementation
490.
by Rusky 7y ago
That depends entirely on the implementation (and leaves open the question of ABI and binary file format).
491.
by Rusky 7y ago
This (and its optimized cousin MSAA) has a huge performance and bandwidth cost relative to its quality increase. It fixes conflation on shared edges (the problem you describe) but 16x supersampling only gives you 16 possible opacities to
492.
by Rusky 7y ago
Yes, though you probably wouldn't call them green threads anymore at that point. (I mean, Rust async/await is implemented that way modulo syntax and it's not called green threads. But that's beside the point.) In fact Ru
493.
by Rusky 7y ago
I agree, there's plenty of ways to work around it, and I'd prefer any of them to the syntactic mess we're in now. I'm not the one making the decisions, though. :)
494.
by Rusky 7y ago
> This proposal does raise another question: why not just green threads, and remove the concept of async functions entirely? Making another reply because this is completely unrelated... Rust already tried that. The problem is that Rust h
495.
by Rusky 7y ago
Switches between keeping the args for the function's full duration, or returning a closure (async or not) that doesn't hold onto them. Here's the problem in terms of normal OS threads: fn f<'a>(r: &'
496.
by Rusky 7y ago
I tried to lean pretty hard into "this syntax is just like threads" in that internals.r-l.org post, when I wrote it, proposing almost exactly what you describe here. Unfortunately problem #1 is not a result of confusion or unneces
497.
by Rusky 7y ago
Well, the real benefit of `await` in an imperative language is that it works inside/across all the usual imperative control flow- loops with break/continue, early return, etc. Whether it's an expression or a binding is mostly
498.
by Rusky 7y ago
Do notation does not solve that problem. It solves the problem of chaining `.and_then` calls, but this is one layer up- do notation would still require each of those awaits to be a separate `a <- b` "statement," which couldn&
499.
by Rusky 7y ago
That's correct. In a sense Javascript await isn't the thing that propagates errors, that's just the language's usual exception behavior plumbed through the Promise.
500.
by Rusky 7y ago
Yes, an async block (or `suspend` closure in Kotlin) just wraps up its contents in a future, applying the same state machine transform as would be applied to a top-level async function.
501.
by Rusky 7y ago
This would have been my favorite approach, and there was a discussion about doing it in Rust: https://internals.rust-lang.org/t/explicit-future-constructi... There were two main objections: First, a Rust async function
502.
by Rusky 7y ago
In Kotlin this is not an issue, because you simply can't call an async function at all until you've added the async keyword (actually `suspend` in Kotlin). If you want to call an async function from a sync context, you just wrap i
503.
by Rusky 7y ago
That was discussed in a previous post, but yes that's why. And in Rust, the biggest postfix expression is the extremely common `?` operator, expected to be used with most futures.
504.
by Rusky 7y ago
There's no technical reason the Rust borrow checker couldn't run without annotations either- that's a design choice, similar to the way Rust requires function types even though it could infer them. It makes inter-function con
505.
by Rusky 8y ago
getElementById() is perfectly allowable under Rust's rules, though it may not look like what you expect (and to be fair Rust doesn't make it easy to write today). The most straightforward way to get it working would be to return a
506.
by Rusky 8y ago
> I think you're reading a bit more into this than I intended and I guess that's fair. That's what I'm reacting to, mostly. But also to the idea that it's some kind of universal, uncontroversial positive for a la
507.
by Rusky 8y ago
Rust isn't "a comparatively bad starting position." Those obstacles I listed are not just cases of "d'oh, if only we had thought of this earlier." They're conscious, intentional design choices to trade off
508.
by Rusky 8y ago
It's just not that simple: https://twitter.com/withoutboats/status/1027702531361857536?... Rust doesn't have higher kinded types, every closure has a unique type that implements up to three different tra
509.
by Rusky 8y ago
Re: your edit, isn't mutating the `&str` exactly what we're doing? Your new diagram implies that `input` itself is mutable and that's what's being overwritten, but that's not what `input: &mut &str` mean
510.
by Rusky 8y ago
> The use of a special kind of lifetime annotation, where the lifetime has to match exactly, can be used to get around this limitation. This is already expressible in Rust, using invariant lifetimes. You can hand someone an opaque invari

More ›