Rusky

17 ms·

211.
by Rusky 4y ago
Adding those features doesn't mean you have to start using them for everything. This is different from how they work in the JVM or CLR- their role in WebAssembly is to enable interop with the host (which already has them regardless), a
212.
by Rusky 4y ago
No, I'm talking about matching JavaScript's memory layout and memory management, indirection and sharing and all. The children field is itself a reference to a collection. Reading the field creates a new reference to the same coll
213.
by Rusky 4y ago
That's totally beside the point here: you can do a mechanical (thus "trivial") translation from JavaScript-like code to Rc+Cell, without ever hitting that overhead. That is, JavaScript-like code simply doesn't do large a
214.
by Rusky 4y ago
The "trivial" equivalent to JavaScript is not RefCell, but plain old Cell, applied at the level of individual fields you want to write to. No panics and no (relative) overhead there. RefCell exists more as a bridge back to the wor
215.
by Rusky 4y ago
There's just not a language feature to prevent you from letting an object go out of scope without "using" it. There is `Drop`, which automatically runs when an object goes out of scope, but you can skip that by leaking the ob
216.
by Rusky 4y ago
You are fundamentally misunderstanding the relationship between Rust's unique and shared mutabilities and the usual mutability in, say, C. The Rust equivalent of C mutability is Cell. Conversely, the C equivalent of Rust's unique
217.
by Rusky 5y ago
> Do you people want your programs to crash due to the compiler doing surprising things? I obviously can't speak for everyone who defends this sort of compiler behavior, but my preferred solution is for the compiler to continue pe
218.
by Rusky 5y ago
The post is a rectangle that spans the width of the column, which contains the picture, and any text commenting on the picture, and the author's name/avatar, etc. It's got a divider above and below to indicate the boundary, a
219.
by Rusky 5y ago
I'm familiar with this issue. But it's a self-imposed problem, not a fundamental limitation relative to C++: the "same people" decided (at different points in time, to be fair) to make the `Future` trait use `&mut Se
220.
by Rusky 5y ago
That only seems tangentially related to me, but it is interesting, haha. Specifically that sounds like it would cause use-after-frees- if you actually `delete this` and then `new (this) Bla`, you're writing to memory that's alread
221.
by Rusky 5y ago
That's backwards. If you can mutate through a shared reference, then there is no need to alias `&mut T`s in the first place! It is C++ that is missing the ability to express unique references like `&mut T`.
222.
by Rusky 5y ago
No, that is not what this "region borrow checking" solves! Both Rust and your "pure functions" are perfectly capable of enforcing this on new code, that is not the point. Neither of them can address the line you quoted
223.
by Rusky 5y ago
There's a lot of overlap between the authors and implementors, and this proposal has extensive comparisons with the -Wlifetime one!
224.
by Rusky 5y ago
No- the idea is that if you make an annotation mistake, you will get an error, because the program will not match its annotations. Lifetimes are not like an `unreachable` UB operation. Instead they are just a description of cross-function i
225.
by Rusky 5y ago
That's not the issue here- there are plenty of schemes that could be used to enforce the rule, including just copying Rust's if you wanted. The issue is that a bunch of existing code actively holds and uses multiple mutable refe
226.
by Rusky 5y ago
C++ does not currently have such methods- all `this` parameters are always by (some kind of) reference. (This doesn't stop you from moving out of `*this`, but C++ moves require the source object to remain valid, and I'm not sure I
227.
by Rusky 5y ago
I've seen a similar pattern implemented in Rust already, presenting a safe interface around relatively little unsafe code. For example, the Bevy game engine's entity system works like a small in-memory database, and also replaces
228.
Lifetime Annotations for C++(discourse.llvm.org)
33 points by Rusky 5y ago|0 comments
229.
by Rusky 5y ago
Some kinds of drivers (e.g. graphics) run at least partially in userspace.
230.
by Rusky 5y ago
I dunno, this feels like a "no fun allowed" sort of rule. The target audience clearly has some background in this area to tell the difference, at which point this is just a fun joke-y title.
231.
by Rusky 5y ago
I suspect the complaint is specifically about the fork and signal APIs as they are in unixen- there's been plenty written about their problems and potential alternatives, e.g. https://www.microsoft.com/en-us/resear
232.
by Rusky 5y ago
> there is no way to stop someone coding in assembler from making a kernel system call. Take a look at OpenBSD, then- if you make a syscall from any language at all, but it's not from within libc, the kernel will simply kill the pro
233.
by Rusky 5y ago
Absolutely bait, and I'm falling for it. The author knows that you can make syscalls from assembly, directly in terms of the ABI those syscalls use, and trying to frame this as some kind of misunderstanding is absurd. You are willfully
234.
by Rusky 5y ago
So this is obvious bait, but the author's argument is the same regardless of which language you want to use. (Like I said above, it even applies to C itself.) Rust happens to be one she has actually worked on, but its hodge podge of fe
235.
by Rusky 5y ago
I don't see the bad faith or ill intent here (except maybe from you...). Nobody is pretending not to want to use Rust or any other language, that's explicitly spelled out in the article. The reality the article laments is a bit mo
236.
by Rusky 5y ago
Just because it's hard doesn't mean it's already been done in the best possible way. Finding and documenting flaws (or "venting") is a great step towards improving. Seriously though what on earth is your point here?
237.
by Rusky 5y ago
Again, this really doesn't seem related to the article. Nobody is saying those ABIs are making breaking changes, but that they are poorly documented and full of edge cases that make it difficult to reliably produce one of those syste
238.
by Rusky 5y ago
This is less about stability and more about clarity. The most unchanging and unbroken ABI in the world can still be a huge mess of undocumented special cases only really accessible via the combination of the platform's C compiler and i
239.
by Rusky 5y ago
> Well, sorry, but on the very low level computers are actually quite complicated. The author is clearly and abundantly aware of this, and it isn't her complaint. Did you read the article?
240.
by Rusky 5y ago
The complaint seems to be less that C as a whole has a lot of ABI implementations, and more that those individual implementations themselves are also not very well-defined, even on the biggest platforms. That is, in principle the strength o

More ›