Rusky

25 ms·

271.
by Rusky 5y ago
I am not familiar with the compilers for all of these, but I can make a couple of interesting comparisons: * GHC does exactly what I suggested rustc needs to do- it does the flattening on an earlier, higher-level IR than LLVM's. (It is
272.
by Rusky 5y ago
This is one of the idioms that leads to large amounts of IR! Avoiding that means doing the flattening earlier, in a higher level IR.
273.
by Rusky 5y ago
I like the use of generator functions for the pull-based example- the syntax closely mirrors the push-based example, which drives home the point that the difference between push and pull lies entirely in whether you compose operators via an
274.
by Rusky 6y ago
> Refactoring a program so that most things' lifetimes are the same does not feel to me like it's in the spirit of Rust, because then why have all these complicated systems, but maybe you feel that it is. I think a common senti
275.
by Rusky 6y ago
They're conditionally meaningful: if a small amount of your program is correct, the entire program satisfies some useful properties. This may or may not be something you care about, but it is certainly a meaningful tool that is quite u
276.
by Rusky 6y ago
> Okay, but if I do this everywhere, then I de facto don't have memory safety. No, that's not how this works. You write the unsafe code in one place and make sure it's correct (just like you'd do in C or Jai), and the
277.
by Rusky 6y ago
This style of memory management can be as pervasive as you like! You are reading way more detail out of people's comments than they put there, and then getting upset about your misinterpretation. If every throwaway string in your progr
278.
by Rusky 6y ago
RAII is completely orthogonal to lifetimes, for one thing. You can have either without the other. But, I am familiar with the kind of thing you're complaining about here, and frankly the mere existence of RAII is not its cause. Working
279.
by Rusky 6y ago
> When you conceptualize a bunch of stuff as different objects with different lifetimes, you are going to write code treating stuff as different objects with different lifetimes. That is slow. This is not how lifetimes work at all. In fa
280.
by Rusky 6y ago
Really feels like you're just digging yourself deeper into a hole here: Burntsushi began with "here, parallelization is beating out memory locality and optimization in its impact," but explicitly declined to generalize this
281.
by Rusky 6y ago
I don't disagree: > ("Just" in quotes because of course more of this is great- my point is merely that it's not the same functionality coming to C++.)
282.
by Rusky 6y ago
What makes you think I'm "advocating" anything? My goal is for people to understand the state of things. C and C++ have had static analyzers to catch "some version" of these problems for a long time now, so presumab
283.
by Rusky 6y ago
??? Rust freely declares itself to be inspired by Cyclone et al, but its capabilities are quite different from Cyclone's region analysis (and Carp actually came after Rust). The C++ static analysis, on the other hand, is quite limited
284.
by Rusky 6y ago
Sure? I didn't say anything about other submissions. I honestly don't know which ones you have in mind anyway, so anything I could say would just be a guess. :)
285.
by Rusky 6y ago
Perhaps the flagger simply put this post in the "truly terrible" category- it retreads old and tired arguments without ever introducing any new depth or nuance.
286.
by Rusky 6y ago
Rust's compiler/library interface is still much simpler than C++'s. An `async fn` call gives you an anonymous-typed object (much like a lambda) which implements the `Future` trait, which has a single method `poll`. `Generator
287.
by Rusky 6y ago
That's already done. The point is that it takes time, and there are always more of them, so at any point in time there are likely to be a handful of them still in-process of moving upstream.
288.
by Rusky 6y ago
I read it as a reference to the problem of maintainer burnout in the face of unbounded input from users and collaborators. This is something the Rust project has been dealing with and thinking about for a while.
289.
by Rusky 6y ago
In Rust's target domain(s), those details often turn out to be quite relevant. Hiding them basically amounts to targeting a different domain. This is very different from being irrelevant and noisy.
290.
by Rusky 6y ago
If a significant part of those types was just something like `std::collections::` or similar then I'm not sure I see the problem. Suggestions should probably trim redundant prefixes like that, but recognizing standard library namespace
291.
by Rusky 6y ago
I am not sure where you got the idea that Rust error message suggestions lead to blindly copying 60+ character type specifications. They tend to be much more localized and understandable in my experience.
292.
by Rusky 6y ago
When combined, Ctrl-K focuses the address bar with a `? ` prepended, which turns it into a search bar. (In the most recent version it replaces the `?` with the name of the default search engine, similar to Chrome.)
293.
Finding Bugs Compiler Knows but Doesn't Tell You: Undefined Behavior in LLVM(blackhat.com)
2 points by Rusky 6y ago|0 comments
294.
by Rusky 6y ago
It means the other engines are less "open"?
295.
by Rusky 6y ago
I've seen the argument (not sure if this factored into rustdoc's design or if it's just someone's opinion) that structured per-parameter docs tend toward useless boilerplate, e.g. "foo: a foo object," while a h
296.
by Rusky 6y ago
Both are true, in my experience. Lots of good documentation for some crates, while others (usually with fewer maintainers or less intention of reuse) just have the autogenerated index.
297.
by Rusky 6y ago
Cranelift is designed to do very little optimziation, in exchange for being very simple and fast compared to LLVM. Its use cases include debug builds of Rust code, JIT-ing WebAssembly (which is pre-optimized), etc. So I would expect it to h
298.
by Rusky 6y ago
Editors can get away with things compilers can't- they are inherently interactive. If your editor gets it wrong, you can just fix it. If your compiler gets it wrong, you might get an error message, or weird behavior. This is, for examp
299.
by Rusky 6y ago
It's not related. The "page tearing" problem is caused by the way imgui handles events. You describe the UI by making a bunch of function calls, each of which immediately renders a piece of the UI and returns any relevant e
300.
by Rusky 6y ago
Going back to my original answer, the difference lies in what the two languages ask of the linker under normal circumstances. Normal, non-FFI-using C++ can hit ODR violations in response to things like typos or subtle mis-uses of `inline` a

More ›