Rusky

18 ms·

181.
by Rusky 4y ago
The post you're complaining about starts with "because everyone likes to use that LendingIterator example I would offer a bit non-trivial example." It sounds like they are already doing that.
182.
by Rusky 4y ago
Incremental compilation is already even more fine-grained than by file- it is based on rustc's internal query system. There is room to improve parallelization, though. Cargo will parallelize invocations of rustc (by crate) and rustc wi
183.
by Rusky 4y ago
I ran the Rust and Zig implementations through a profiler and (at least on my machine, using Zig nightly 0.10.0-dev.4583+875e98a57) the vast majority of the time difference is from the number of calls to the GPU paint_tile_line function- th
184.
by Rusky 4y ago
> Casting *mut to &mut in a safe function is unsound, and UB if the result is used alternatingly with an earlier &mut to the save object This is a very different statement than your first comment, and still wrong. Casting *mut
185.
by Rusky 4y ago
This is not an accurate characterization of the Rust language developers. Neither of these features were designed as "syntactic salt!" They are compromises, made on a time budget to achieve goals which were higher priority for the
186.
by Rusky 4y ago
That's a gross misunderstanding of `unsafe`'s place in Rust, and also of the use cases for `union` vs `enum`.
187.
by Rusky 4y ago
I mean, have you looked at them? C++'s standard library optional type is a tagged union implemented from scratch, with a dizzying array of template metaprogramming to meet the standard's requirements- see e.g. Microsoft's her
188.
by Rusky 4y ago
C++'s option and result types are much larger, uglier, and harder to use correctly than Rust's. The shift from throwing to returning a Result is not really an increase in complexity- closer to a reshuffling of syntax. But that&#x2
189.
by Rusky 4y ago
Yes, that is what I replied to... my point was that neither approach is a pure improvement over the other.
190.
by Rusky 4y ago
EXCEPTION_ACCESS_VIOLATION itself is well-defined and memory safe, but the program constructs that cause it are generally not. A use-after-free or null pointer dereference may cause an access violation in one run but corrupt memory and keep
191.
by Rusky 4y ago
But this just shifts the problem. Now it's not apparent looking at any snippet of Odin code which objects should have cleanup logic but don't, without looking up each type and reading its documentation.
192.
by Rusky 4y ago
It's had those extra connotations from the start- the whole reason to tie allocation to initialization is so that you can also tie deallocation to destruction, making it automatic and thus less error-prone. "RAII" is mostly j
193.
by Rusky 4y ago
> I don't expect to have a good mental model of an optimising compiler in "gotta go fast"-mode, but a mental model of what the memory layout looks like is pretty darn relevant when designing or working with ABIs and binary
194.
by Rusky 4y ago
> The main issue is with memory semantics however, stuff like tagged 64bit pointers are UB land pretty much immediately. MiniRust solves this by providing an explicit memory interface trait. But this is no different from C! The way C pro
195.
by Rusky 4y ago
This is pretty vague reasoning. Rust draws inspiration from each of those languages for something but that doesn't mean they affect its operational semantics, which are quite similar to C's. The fact that you point to datafrog i
196.
by Rusky 4y ago
Well, yeah, if you're reaching for that level of robustness you want every tool you can get. If you can get rid of a whole category of bugs with one tool, that only makes the other tools more effective for the rest! (There are also cas
197.
by Rusky 4y ago
A sibling comment suggests this has more to do with where you work than how modern your C++ is, which rings true to me. Different kinds of programs need different kinds of memory management patterns, and some are more error-prone than other
198.
by Rusky 4y ago
> a) it's not actually memory safe once you start doing heavy shit b) modern C++ is quite memory safe This just doesn't capture the problem that memory safety solves. A crashed program is not the worst-case scenario that it&#x2
199.
by Rusky 4y ago
The problem is that you have to do that by hand, and thus it will be possible to get out of sync with the actual requirements of the generated code, leading to C++-like template error messages that have to include the entire stack for you t
200.
by Rusky 4y ago
> offering inference means either different implementations could have different inference rules, or else, those rules must be set out in full in the specification As a tangent, there is a third option (or a twist on the second), called
201.
by Rusky 4y ago
Editions aren't that clear-cut- crates targeting old editions can still use most new language features, and all new library features. For example, the NLL borrow checker was originally enabled in the 2018 edition, but it's now ava
202.
by Rusky 4y ago
Only if you use RefCell instead of, say, Cell or Atomic* or RwLock or Mutex.
203.
by Rusky 4y ago
There's a bit of a sentiment that the `*mut T`/`*const T` distinction is more unhelpful noise than an actually useful feature. They can be freely cast between each other - `*mut T` to an immutable object is totally legal - and thu
204.
by Rusky 4y ago
Yes, that's the idea. Though, it is still worth thinking about how someone might accidentally leak a table-based capability via API misuse. For example, if table entries are reused over time you might get a sort of use-after-free situa
205.
by Rusky 4y ago
Then you've spent this entire thread arguing over clearly-explained terms of art, what a colossal waste of effort. I'm sorry to inform you: this is not how Fuchsia uses the word "capability." Using your version of the
206.
by Rusky 4y ago
Yes- the thing you didn't mention is the distinction I'm making between Dropbox URLs/UUIDs/etc and fds/Fuchsia capabilities, which is that the former are bit patterns and the latter are pieces of state in a trusted
207.
by Rusky 4y ago
How so? The line you quoted from Wikipedia calls them unforgeable. If you can forge it (by printing it out and reading it back in from somewhere else, or by guessing a bit pattern) then surely it's not a capability?
208.
by Rusky 4y ago
I'm specifically talking about Fuchsia and other kernel-based capabilities here. You fundamentally cannot print out that kind of capability in any way that matters- the only thing that determines whether a process has it is the table i
209.
by Rusky 4y ago
I think we're just talking past each other- by "leak" I was talking about something like accidentally sharing an fd number, not actually communicating the capability itself. This is how Dropbox's approach is a "fuzz
210.
by Rusky 4y ago
It doesn't matter if the value is leaked, because it's meaningless to another process- like a file descriptor, it's just an entry in a table in the kernel, so it can only be used by the process it was granted to. (One process

More ›