RPIT (Return Position impl Trait) is Rust's spelling of existential types. That is, the compiler knows what we return (it has certain properties) but we didn't name it (we won't tell you what exactly it is), this can be for two reasons:
1. We didn't want to give the thing we're returning a name, it does have one, but we want that to be an implementation detail. In comparison the Rust stdlib's iterator functions all return specific named Iterators, e.g. the split method on strings returns a type actually named Split, with a remainder() function so you can stop and just get "everything else" from that function. That's an exhausting maintenance burden, if your library has some internal data structures whose values aren't really important or are unstable this allows you to duck out of all the extra documentation work, just say "It's an Iterator" with RPIT.
2. We literally cannot name this type, there's no agreed spelling for it. For example if you return a lambda its type does not have a name (in Rust or in C++) but this is a perfectly reasonable thing to want to do, just impossible without RPIT.
Blanket trait implementations ("auto impl trait for type that implements other trait") are an important convenience for conversions. If somebody wrote a From implementation then you get the analogous Into, TryFrom and even TryInto all provided because of this feature. You could write them, but it'd be tedious and error prone, so the machine does it for you.
Returning impl trait is useful when you can't name the type you're trying to return (e.g. a closure), types which are annoyingly long (e.g. a long iterator chain), and avoids the heap overhead of returning a `Box<dyn Trait>`.
Async/await is just fundamental to making efficient programs, I'm not sure what to mention here. Reading a file from disk, waiting for network I/O, etc are all catastrophically slow in CPU time and having a mechanism to keep a thread doing useful other work is important.
Actively writing code for the others you mentioned generally isn't required in the average program (e.g. you don't need to create your own proc macros, but it can help cut down boilerplate). To be fair though, I'm not sure how someone would know that if they weren't already used to the features. I imagine it must be what I feel like when I see probably average modern C++ and go "wtf is going on here"
Why would you worry about it if you can afford to replace it?
If you say you worry about the cost, shouldn't you worry even more about the higher cost of the insurance? Sure, for one item the variance is higher if you are uninsured, but if you have several such items, variance goes down, and you are saving all the more money.
Because even though I can afford to buy/repair a new phone if I break mine; it still _feels_ terrible to have to spend 500+ bucks because I was a dumbass.
I literally toss my phone to my couch or my bed from across the room dozens of times a week without worrying about misjudging the throw (which happens more than I’d like to admit), toss is on the ground at the gym, have no problems taking long baths with it, washing it under the sink if it gets dirty, and do dozens of things I would not do if I had to pay a full price if I ended up actually breaking it.
Having AC+, lets me treat the device with the level of carelessness that is worth the price to me.
Math-wise with how durable recent flagship devices are, you are probably correct that I’d be better off financially to just accept that I will break a phone every couple of years and just eat the cost.
But psychologically, I’m happier paying ~120bucks a year, than $500 in repair fees once in a while.
Yes, the argument is that the entity providing the insurance is surely earning more income that they are paying out since in addition to payouts, they also have overhead costs and must be profitable. Said another way, their customers are paying more than they receive, on average. That's a mathematical and economical certainty.
You are right that it might still feel better to you to pay regularly instead. That's subjective.
Knowing that you will likely end up paying less in the long term if you don't pay the insurance might help getting over that feeling, but that's a personal choice in the end.
It's bordering on insurance fraud and I usually trade-in my devices back to Apple so I don't bother with it; but there's probably at least one case where both you and Apple come out ahead financially.
AC+ includes what they call "Express Replacement Service", where you will send you an entirely new device as part of your claim, and they'll reuse your old one for parts.
If you _just happen_ to accidentally fall with your phone in hand right after the new ones come out, the delta in price between "a scuffed up, used 1-year old phone" and "brand new refurbished device from Apple" is higher than the price of the insurance and incidental damage fees.
Building a tech and falsely advertising it to be something else that what it is (e.g. self driving instead of driving assistance) can typically done by different people. Lacking specific evidence, it's reckless to accuse this person.
right. i'm mostly ignorant of the subject and rushing to judgement based on bias. but he did lead the computer vision team for years at tesla that created autopilot. didn't resign in protest and to my knowledge hasn't apologized, but again i'm ignorant and not seeking new data.
> It was a challenge to write routines that would keep the computer tolerably in tune, since the Mark II could only approximate the true pitch of many notes: for instance the true pitch of G3 is 196 Hertz but the closest frequency that the Mark II could generate was well off the note at 198.41 Hertz.
There are several notes that sounds significantly out of tune, a bit similar to a beginner violinist. Which is kind of poetic in a way. The first computer to play music (in 1951!) had not mastered it yet.
It’s truly fascinating that it was out of tune because of the similarities of the Mark II timing with sound itself .. but that also computing rapidly, rapidly started operating in a much higher frequency band and is capable these days of bending audio realities in other astonishing ways ..
I'm not a lawyer but I would assume its copyright. Kind of like API in software. In software somehow this does not apply most of the time. But it seems in hardware this is very real. But I would appreciate a lawyer jumping in.
I know for example that Berkley when thinking pre-RISC-V that they had a deal with Intel about using x86-64 for research. But they were not able to share the designs.
I don't know why there aren't independent X86-64 manufacturers. Patents on the extensions maybe? But as I understand copyright, APIs can't be copyrighted so it's not that.
I doubt there is any legal barrier, because there are a few existing projects with x86 cores on an FPGA, as well as some SoCs. Here's a 486: https://opencores.org/projects/ao486
On Firefox/Linux, after allowing mic access, I get a "Failed to access microphone" above the button, and in the javascript console:
[ws] Microphone error: DOMException: AudioContext.createMediaStreamSource: Connecting AudioNodes from AudioContexts with different sample-rate is currently not supported.
This law feels like a battle in The Coming War on General Computation, as Cory Doctorow put it:
> I can see that there will be programs that run on general purpose computers and peripherals that will even freak me out. So I can believe that people who advocate for limiting general purpose computers will find receptive audience for their positions. But just as we saw with the copyright wars, banning certain instructions, or protocols, or messages, will be wholly ineffective as a means of prevention and remedy; and as we saw in the copyright wars, all attempts at controlling PCs will converge on rootkits; all attempts at controlling the Internet will converge on surveillance and censorship, which is why all this stuff matters.
> all attempts at controlling the Internet will converge on surveillance and censorship, which is why all this stuff matters
it really boils down to this sadly, and it should be pretty obvious shouldn't it?
i'm finding it befuddling that even technical audiences seem to resist connecting those dots, but strong motivated reasoning is at play: these are audiences that will often feel it will be them who will be in control, and they're also emotionally nudged by the idea of child safety
CSV can handle commas in fields just fine (quotes are required in that case). The root problem here is not the format, it's a bug in the CSV exporter used.
reply