vacuity

40 ms·

541.
by vacuity 2y ago
The maintainers/developers do explicitly deprioritize performance, but I agree that it feels wrong for a "suitable for general purpose graphics" engine with the implication of being "modern" to deprioritize it that
542.
by vacuity 2y ago
Because the current implementations for ballots don't feel up to snuff, and I at least don't trust profit-driven companies to make "simple computerized systems" that are auditable and whatnot. Get a good solution in plac
543.
by vacuity 2y ago
I think the scope of lazy constructs should usually be far less than that of strict constructs, so it's only in the cases where the librarified lazy abstractions don't fit that you need a rewrite. Lazy to strict isn't hard, b
544.
by vacuity 2y ago
On the other hand, when you don't want laziness you really won't like if it's present anyways.
545.
by vacuity 2y ago
Increasing engagement doesn't have to just be through agreeable content; consider Twitter ragebait or Instagram [body dysmorphia bait?]. In general, it means your attention is hooked. If people only get content they are likely to be hi
546.
by vacuity 2y ago
I do like the spirit of "developer driven development". The developers (and testers and other vital roles) are the endpoints for discovering and solving problems. There should be clear routes and aims of communication so that a pr
547.
by vacuity 2y ago
Some fears in this genre are well overblown, I agree. I also like the idea of kids learning for themselves, but it depends on whether they can learn before it becomes unmanageable. There is probably middle ground between no phone and phone
548.
by vacuity 2y ago
They might mean in the sense of data races, which can happen in other languages with pointers. In unsafe code, Rust exchanges that (kinda) for upholding Rust's reference rules, which is its own flavor of UB. Although if you have long-l
549.
by vacuity 2y ago
To add on, unsafe Rust's main strength is the tools and the culture of encapsulating it well. It's probably the case that "well designed code that uses unsafe" is much safer overall, as you would expect for a memory-safe
550.
by vacuity 2y ago
> but instead to the deceptively difficult problem domain. It's definitely a big part of it, but I think sometimes it is a Rust thing. Of course, motivated by the essential complexity, but accidental complexity is still complexity.
551.
by vacuity 2y ago
If you start to write an angry email, pause, and genuinely think of valid logical arguments (knowing that the previous anger may still be biasing the reasoning), that isn't deceptive. If you're masking the anger and not trying to
552.
by vacuity 2y ago
Seems like we should repurpose internships to be less competitive and more of a way to onboard everyone into the job market broadly.
553.
by vacuity 2y ago
Selecting abilities to value is quite complicated to do well. Even in a software engineering role, one person may be great at documentation, while a few can teach others, and someone else might excel at debugging. But it would be impractica
554.
by vacuity 2y ago
I think the promise-based model is the ideal model. After reading [1], I'm convinced that it's very close to realizing the underlying state machine ([2]) of the program, and I find that valuable. I agree that fibers are easier to
555.
by vacuity 2y ago
I think we pretty much agree, but it's not a scientific result to say that race is a social construct and that racists leverage science incorrectly. Someone isn't acting in the role of a scientist by making those refutations. I wa
556.
by vacuity 2y ago
I think this is one of those things where the root cause is a social problem rather than a technical one, and trying to use technical solutions is somewhat helpful at best and masking huge issues at worst. If people can't write profess
557.
by vacuity 2y ago
> Specifically over a decade ago I was press ganged into a thought control hooligan army. I think it would be helpful for myself and others to understand your perspective better if you can elaborate on something highly empirical like thi
558.
by vacuity 2y ago
I think we should accept that there is room for science and then there is room for philosophy. For instance, I find it doubtful that the answer to the question "is racism okay?" involves the reasoning "empirically, there [are
559.
by vacuity 2y ago
I appreciate the insight in this comment! I see your problem, and I offer an answer (I daren't call it a solution): there is no surefire way to make an interface/abstraction withstand the test of time. It just doesn't happen,
560.
by vacuity 2y ago
I think Austral and Vale's linear typing is a good start, although it would probably have to be opt-in in practice. This goes along with explicit, manual destructors and alleviates issues like async drop. Even with automatic destructor
561.
by vacuity 2y ago
I claim that async/await is far more basic (/fundamental/simple, not necessarily easy) than most acknowledge, but it should indeed be more composable with sync code. It is a means of interacting with asynchronous phenomena, w
562.
by vacuity 2y ago
I think we expect vastly different things from humans and LLMs, even putting raw computing speed aside. If an employee is noticed to be making a mistake, they get reprimanded and educated, and if they keep making mistakes, they get fired. H
563.
by vacuity 2y ago
To be crass, description is only useful for existing things and prescription hinders making innovative things. I think social forces make it natural that standards are treated both descriptively and prescriptively, and that too leads to ang
564.
by vacuity 2y ago
My point is that X is in the right direction more than Wayland is, in the spirit of its design, and major pain points of X are largely due to its specific design/implementation. Perhaps an outgrowth of having a lot of tiny policy-mecha
565.
by vacuity 2y ago
X11 is far more inclined towards the idea of clean separation of policy and mechanism, which I think is becoming more and more evidently correct across the board of programming. When you start talking about libraries and layers, a policy&#x
566.
by vacuity 2y ago
Note that an outsider is likely not going to have the full picture at a glance, so even if it seems like a "wow, this parent is irresponsible and bad" situation, give some leeway. There are plenty of bad eggs, but also just people
567.
by vacuity 2y ago
The lower level async-as-state-machine (or coroutine or whatever) should be more standard, but that's an argument for another day. For now, you're right and the opaque threading model is basically what Go does. On the other hand,
568.
by vacuity 2y ago
Perhaps (?) it wouldn't be an issue for correctness in most languages, but it would certainly add a performance and debuggability cost. It could be useful in some niche domains, probably.
569.
by vacuity 2y ago
Async usage is overblown in some cases, but not in others. The mistake of async Rust is not that it's unnecessary, just that it's being pushed for general purpose usage. Which is probably impractical for any async abstraction, or
570.
by vacuity 2y ago
Even outside of UI, use-from-one-thread-only is perfectly valid and acceptable. The issue at that point is with the tools (e.g. C), not the API. If the API provides thread-safe entry points, that's because it is taking on the responsib

More ›