100%. I would actually go further and say every value should be dropped immediately after its last use, including temporaries in the middle of statements, whether or not it implements Drop. Reuse the same rules that NLL uses. Breaking change yes, so do it next edition. It would lower memory usage in general and solve so many little pain points, not least of which is holding strings across await points.
I hope the tide does turn and then keeps going. I think the language restrictions around Deref(Mut) and Index(Mut) originally borne of purism are just not all that helpful in practice. I can make a network request in my Deref impl, but I can't return a smart pointer?
From google's point of view, it's not second guessing you. It just associates words it decides are similar. You'd probably accept results for "dead generals", "killed generals", or "killed commanders". To google, dead = killed, generals = commanders, Russian = Ukranian, and moon = mars. It will expand the meanings of words until it has a page full of results and ads to show you.
I could really use a better workflow to refine grep matches. Has anyone made a tool that combines grep (regex search) with fzf (multiple positive/negative patterns)? What I really want is something like:
The problem is this loses filenames and context lines in the output. I want to apply several positive and negative regexes, and only at the very end annotate with filenames and context. Anyone have a good workflow for this?
Your comment gave me an idea for a lint that might help prevent those mistakes. Right now rustc flags `unsafe {}` with an "unused_unsafe" warning. However it doesn't warn for `unsafe fn foo() {}`. Maybe it should.
I'm not sure I follow this. If Rust wanted the feature in that blog post, they could restrict it to only accessing data that is Sync. They wouldn't have to throw out the concept of Sync entirely, in fact cases like this are the reason it exists. Rust just chooses to leave this kind of feature up to libraries instead of building it into the language.
And even without unsafe, you still couldn't assume all data is Sync. Counter-examples include references to data in thread-local storage, and most data used with ffi.
> A question is whether that company would save money by using "AI" text generation, when they were paying real humans so little, for arguably higher quality.
You can power a GPU for a few cents of electricity per day, so I think the answer is a resounding yes.
I thought stalebot was supposed to back down if people were commenting. But this time it added a "wontfix" tag right away, ignored the humans and closed the issue anyway. The scourge is getting worse.
Thankfully git is everywhere these days, and git on windows comes with most of the coreutils. I hope IT isn't telling you you're not allowed to use source control. Microsoft owns GitHub after all
SGI was a key part of some of the most iconic early games (even Nintendo used them!) There isn't much of an emulation scene, probably because of how specialized they were, the weird architecture, and the diversity of workstations. And lots of the old machines were just tossed after they became obsolete. It's a huge shame from a preservation point of view.
I mean... it has to eventually. If my country has a population of 50 million and I build 800 million homes, will investors keep buying them all at above market rates (read: more than I spent building them)? Then I can build 100 million more and keep collecting infinite money?
At the end of the day most people care about wall clock time. It's a real physical value that's easy to understand and easy to compare between systems. Plus, if two functions execute say, 1 billion instructions each, but one spends extra time stalled waiting on IO or data fetches from RAM, you definitely want to account for that in normal benchmarking.
Instruction counting is more of a specialized tool but I like to use it whenever I can because it has low variance and makes comparing changes a lot easier. Compare how bumpy these graphs are for instruction count (first link) and wall clock time (second link):
Counting instructions is very accurate and roughly approximates power usage. The CPU's self-reported power usage is comparatively pretty noisy. Unit tests will probably be done running before you can get meaningful data. I have to wonder if a test runner is the best point of integration for this. It might make more sense to expose it as a bench harness, like criterion.
EDIT: another benefit of a criterion-like approach is that you wouldn't require nightly
That's an interesting perspective. When it comes to medicine, I usually have no idea whether there might be a "simple fix" for some problem. If I ask my doctor about something small, I expect he would just say "yeah, you're getting old" and then bill me $300. So I don't bother. Maybe end users think similarly.
A single node with a 20kb/s link is all it takes to keep the network in sync in both directions. In a country with 100 million people, surely one or two of them have a satellite dish. You cannot partition an entire population from the sky.
Up until now the rust compiler has been finely tuned for LLVM. I would expect the GCC backend to perform worse initially, then improve over time depending on how much use it gets.
For a decade+, people complained that go lacks generics. Would you say those were all people with no experience fixated on an imaginary problem that doesn't matter, or were the complaints valid?
I assume if the jenkins-step failed, you'd click a link to the dagger UI to see which dagger-step failed. Alternatively, never open jenkins at all and instead keep a tab open with the dagger UI.
I would say the opposite. IE was popular long ago because they were fastest to implement new features. IE is the reason XMLHttpRequest has such a silly name. IE supported CSS grid 5 years before anyone else[1]. The problem is they tried to force features on everyone instead of collaborating. That started decades ago with the <marquee> tag trying to stand out against netscape, and never really stopped until IE11 got feature frozen. Now IE is left with a "grid" that's different from everyone else's "grid", because everyone else waited for consensus.
Google is playing the exact same game now with things like manifest v3 and federated cohorts, etc. They're winning the game so far. They may keep winning forever, or they may not. We can only wait and see.