vacuity

36 ms·

571.
by vacuity 2y ago
On the topic of improving OS threads, there are scheduler activations and similar mechanisms in some microkernels. Basically sending events for all hardware things and context switches, making user level threads as flexible as kernel thread
572.
by vacuity 2y ago
(I should caveat what I'm about to say that I'm primarily concerned about writing robust and highly performant programs, and while I believe it should be a focus broadly, it's a practical niche.) That's the thing, though
573.
by vacuity 2y ago
I posit that while more programmer friendly async abstractions (such as in Go) are good in the short-term, ideally async should be far less scary even in the lower levels. Programmers should shy away from async not because it is hard, but w
574.
by vacuity 2y ago
It isn't what is explicitly touted as standard, but it is what many developers have culturally established.
575.
by vacuity 2y ago
As is typical in Rust-land, lots of talk but implmentations (let alone remotely complete ones) are harder to come by. Partly a procedural and social issue, not just technical queries, which is disappointing. At least delegation (IIUC closer
576.
by vacuity 2y ago
There's indeed a predictably present cost for checking for failure all the time. Exceptions, depending on the implementation, often do come with runtime overhead too. If the determining factor is a slight performance gain of exceptions
577.
by vacuity 2y ago
Indeed. While it is painful for the people who know they have a simpler architecture, making errors and other cross-cutting effects explicit is necessary at some point. It's essential complexity that shouldn't be hidden; it should
578.
by vacuity 2y ago
> Memory leaks are not just possible in Rust...IME I see more leaks in Rust in the wild than in C, C#, Python, C++, ... Perhaps, but data here would be nice. Yes, Rust has Rc/Arc and whatnot. If we're talking anecdotes, I mostl
579.
by vacuity 2y ago
It may be that a typical well-written C program for an algorithm is more concise and/or elegant, but how exactly do we scale developers writing C programs well? For that matter, forget algorithms, what about C string handling? Yes, Rus
580.
by vacuity 2y ago
Unlike the other slew of "memory safe languages", Rust aims for a middle ground of sorts where "unsafe" is more visible and acknowledged but also guarded against. It's a rather third way of treating the inevitable e
581.
by vacuity 2y ago
On the note of OS mitigations, I've been thinking that a heavy-handed but possibly necessary (at least for highly untrusted programs) approach is to trample all over a process' cache and other relevant microarchitectural affordanc
582.
by vacuity 2y ago
I don't know that an AI winter is bad. Frankly, I don't think society is ready for "actual" AI. It'll probably be used to entrench corporations and increase exploitation if we don't fix our current problems.
583.
by vacuity 2y ago
Try your best to ignore the rewrite-it-in-Rust people. They're just plain wrong for that. But yes, for a niche like browser engines, Rust is pretty darn well suited.
584.
by vacuity 2y ago
It's funny; I wish Rust was better suited for bare metal than it is now. But no matter how much people perceive Rust as a bare metal language like C, it was quite literally made for a level or two above that, in browser engines. (Here&
585.
by vacuity 2y ago
Right? I don't think HN needs more obligatory "this is a big undertaking and likely to fail" comments. We can take those as implied. We should 1) engage more meaningfully with the project and 2) keep in mind that negativity h
586.
by vacuity 2y ago
Admittedly, I'm not an expert. I believe it's due to the extra control flow points (assume all functions can throw, not just specially marked ones) and not having just a local value, which procludes analyzing the operations done o
587.
by vacuity 2y ago
I think that there are a lot of things to be elated or miserable for in the modern world, but widespread social media disproportionately amplifies negativity.
588.
by vacuity 2y ago
However, exceptions require a larger runtime and can make optimizations harder to reason about.
589.
by vacuity 2y ago
While no one is entitled to other's time for free software, your comment is needlessly dismissive and discouraging. People can have legitimate complaints and try to rally others to change the status quo. No one is encroaching on your r
590.
by vacuity 2y ago
And there is certainly anti-Semitism mixed in with the protests, but I think Germany is still overdoing it. Silencing plenty of valid speech has a cost, too.
591.
by vacuity 2y ago
High cognitive complexity, incongruity with other language features, interface virality (the bemoaned "function coloring problem"). I think much of the downsides are more a result of slow moving language design than intractable fi
592.
by vacuity 2y ago
Rust's async/await design makes a lot of sense when you consider its primary goals (C interop, low level control, zero cost abstractions, etc.). Sure, perhaps most of us should be using a language with different constraints as opp
593.
by vacuity 2y ago
Yeah, Rust's async/await and lightweight threads are functionally very similar. Function coloring is a problem with async/awaitt, though (for now?).
594.
by vacuity 2y ago
That is true. Rust's async/await desugaring is still missing optimizations. I think that will be ironed out eventually. What mainly concerns me about async/await is that, even with Rust's best efforts, the baseline compl
595.
by vacuity 2y ago
I think we shouldn't expect any language to lead different programmers to the same experiences. Rust has the inital steep learning curve, and after that it's a matter of taste whether one is willing to forge on and turn it into a
596.
by vacuity 2y ago
I think the async Rust shortcomings are largely solvable, but I sympathize with everyone running into the numerous problems right now.
597.
by vacuity 2y ago
Some of those issues with Bevy might have more to do with its immaturity. It still needs at least a few years to be a solid choice for all sorts of games, in my opinion. I do think the hype should be toned down; people shouldn't feel p
598.
by vacuity 2y ago
Sounds like a forum that scrambles comments could be interesting.
599.
by vacuity 2y ago
Now I'm wondering how far people could go a hypothetical Rustscript* that transpiles to Rust (or hooks into rustc?), introduces extra features such as reflection, removes lifetimes, and changes the defaults around things like monomorph
600.
by vacuity 2y ago
I hope Rust does gain mature options for its GUI ecosystem, but the author of the article makes a very good point that in other languages, there would be mature options in use already. "Seems promising" is too little, too late.

More ›