dwattttt

19 ms·

421.
by dwattttt 1y ago
So... Don't give the trait methods that don't apply to every member of the trait. Only implement write methods on the concrete Write implementation.
422.
by dwattttt 1y ago
I may be misunderstanding, but > Make the file system itself a trait, with implementations for read-only and read/write Those are separate concrete implementations between read-only and read-write; a write operation can be implement
423.
by dwattttt 1y ago
Implication sounds right. With no further analysis, running each line in order is correct (for whatever "order" is defined by a language, let's assume imperative). A compiler could recognise that e.g. L_2 doesn't depend
424.
by dwattttt 1y ago
It's in the news
425.
by dwattttt 1y ago
Gold is atomically heavier than iron, fusing gold costs energy. The language in the article is ambiguous, but I believe the energy quoted is a cost.
426.
by dwattttt 1y ago
> minimum processor & TPM requirements in Windows 11 have been shown to be entirely arbitrary. I am curious who thinks they managed to show this. My understanding was that the minimum processor requirement was born out of hardware fe
427.
by dwattttt 1y ago
I'm yet to see someone be confident in this way on anything more than a trivial program, and be right. Just way too many footguns. My personal memorable one was bit shifting 32bit values by varying amounts, and our test vectors all fai
428.
by dwattttt 1y ago
I think the most immediate problem would be ELF segments that aren't 16kb aligned. Code will abut data, you can't add a gap without breaking offsets inside the ELF, and you'll induce the segfault during every write to a globa
429.
by dwattttt 1y ago
> Remarkably, the lone survivor wasn't Rust or Go, as many of us had predicted. It was Erlang. Rust is _more_ likely to crash than C, or I assume go. Well, more likely to panic, assert, stop, and unless you're distinguishing
430.
by dwattttt 1y ago
Spurious wakeups enters the chat.
431.
by dwattttt 1y ago
It depends on how much of a program actually triggers the failure case, so you can't answer in the abstract. In the worst case, ~every memory access causes the kernel to need to fix it, causing every memory access to be several orders
432.
by dwattttt 1y ago
Every time you call a JS function, it's blocking; if it internally busy-looped, you'll die just as much as if you do the loop yourself. Being able to block on an async function call is just as much of a risk; if it returns quick,
433.
by dwattttt 1y ago
Page size impacts page permissions; it's not a matter of wasting 12k, it's that with 4kb pages you're allowed to have a consecutive 8kb region with different permissions. 16kb pages can't do that without segfaulting ever
434.
by dwattttt 1y ago
JavaScript is (notionally) "single threaded", you can block with just a busy loop; that's not a language change. It's bad design to block, which I expect is what you mean, but that's not a language problem. If you d
435.
by dwattttt 1y ago
I've been pondering this, it feels like a brain teaser. Is it possible to create an "async" runtime out of only blocking operations? It feels like it turns purely on what "blocking operations" are (does setting a lo
436.
by dwattttt 1y ago
The queue starts with a cue, because it's not your turn until it's your cue.
437.
by dwattttt 1y ago
Yes, it's quite curious. Having used both block_on and spawn_blocking, and not being worried about what "colour" my function is, I am also quite confused about the fuss. On a practical note, since Rust doesn't standardis
438.
by dwattttt 1y ago
> the only solution is to make everything of one kind That's not really the case. All you really need is a way to run async code from a sync function; "keep doing this async thing until it's done" is the primitive you
439.
by dwattttt 1y ago
No, it's entirely possible. And that's why we don't think about "has an allocator" as a colouring problem. Likewise if JavaScript had an easy way to get a handle to its Runtime, and a function "block on promise
440.
by dwattttt 1y ago
> Then we have to start talking about function colouring in a whole bunch of new contexts like with Zigs explicit passing of allocator. That's pretty much where we are though. If you have a function that isn't passed an allocat
441.
by dwattttt 1y ago
> you can extrapolate that to an infinite set of colors in every single language and every single standard library, and the discussion on colors becomes meaningless. It's more that discussion about most of them becomes meaningless,
442.
by dwattttt 1y ago
Function colouring created a lot of angst when it first came about, particularly because of the difficulties of calling a function of one colour from another. Whether that was possible, what it actually meant, wasn't really well define
443.
by dwattttt 1y ago
> Isn't "coloring" just another form of static typing? In a very direct way. Another example in languages that don't like you ignoring errors, changing a function from infallible to fallible is a breaking change, a la
444.
by dwattttt 1y ago
> I’m not sure any langage with a sync/async split has an “async” runtime built entirely out of sync operations. You get into hairy problems of definition, but you can definitely create an "async" runtime out of "sync
445.
by dwattttt 1y ago
> Or if it is sync api then it is useless for async application. The rest is true, but this part isn't really an issue. If you're in an async function you can call sync functions still. And if you're worried it'll blo
446.
by dwattttt 1y ago
It seems trivial that it's better than option 1; in both cases a mentally ill person is flying the plane, and in one of them a health professional is involved in managing the condition. For option 2 I'll confess to not being suffi
447.
by dwattttt 1y ago
You could probably get away with the typecast if you satisfy the "common struct prefix" requirement, that's nowhere near necessary. While the article does hide the internal char*, that's not strictly necessary to get the
448.
by dwattttt 1y ago
email_t doesn't have to be opaque; if it's just a visible wrapper around char* then you can still do everything with it as a char* (that is, everything you do with strings). The benefit is to avoid treating char*s as email_t, not
449.
by dwattttt 1y ago
Where's option 3: a pilot gets treatment for his mental illness and is signed off as safe to fly a plane? For all that it's a fallible process, that seems better than options 1 & 2.
450.
by dwattttt 1y ago
I'm not familiar with Zig, but won't the classic "blocking" APIs still be around? I'd rather a synchronous debug print either way.

More ›