> I find it really interesting that the author's example assumes that the read() and send() calls are the ones you need to worry about w/r/t exceptions.
I didn't read it that way. In my view, the article is explaining a mental model where async code & panics are similar/related in a possible abstract mental model. He's using that snippet of code which from an async perspective, one could reasonably expect that the file or network IO is worth async waiting on but parsing is not.
But I don't think the author assumes parsing couldn't raise an exception since he states at the beginning: "If the parse function or the send function were to throw an exception, whatever data had just been read (and maybe parsed) would be lost.".
RISC-V is an open ISA (Instruction Set Architechture). An ISA is the "language" that the silicon speaks and which eventually all the programs are "compiled" into. Being an open ISA means anyone can implement a chip based on it for free. To this day, most ISAs are either locked-down or available under a license + royalty scheme. That means, you have to either buy a chip off the shelf from a vendor (either physically or a design you include in yours) for a cost or you have to design one yourself.
Again, being open means anyone can design one, and several free (as in beers) designs have popped up already. Anyone that needs a CPU in their system can pick one of these designs and use it "for free". Moreover, a company can design one such chips, and then outsource to another company the support for it (or the other way around). Or, even swap support companies if needed. The fact that the RISC-V is open (and claimed to be patent free) means there is very little barried to entry. Which means the market offers space to more companies working together and competing at the same time.
For lots of designs, the CPU is a commodity. You need it, but the specs are not that important in the sense that you do not need the performance equivalent of the latest Intel chip. For those markets, haven a proven design with lots of software support and that is gratis, is way more appealing. Another commenter pointer rightly so to the "hidden" CPUs that are everywhere inside devices and gadgets. That's the market that I believe RISC-V is going to conquer quickly because the "cost" of moving to another architecture is low compared to other segments where it is very expensive. Think of a PC or smartphone which carry years and years of software developed all over the world and built against a specific ISA. Those markets are unlikely to move soon, if ever. However, the "hidden" CPU ones is easy, the washing machine software is built inside the wasching machine company which can probably built their software against a different ISA in a couple of days, if needed.
Another important aspect is the software tools. It is cosly both in time and in money to develop a high quality set of tools to support an specific ISA, i.e. compilers, support libraries and optimized libraries for your ISA, etc. Therefore, not all architectures receive the same "love". Some "niche" markets do, with lots of effort in the closed source space, which again means vendor lock-in. RISC-V, being open, is getting lots of attention from all open source tools, and it's expected its support will be on par with other mainstream architectures like x86_64 or ARM ones.
One final note is that of developers and knowledge. The fact that is free and anyone can experiment with it, means lots of universities are turning their focus on it for reasearch and education. As the new wave of engineers come out of the university with expertise in RISC-V, it's going to be easier to hire them and their friction-less path is going to be towards RISC-V.
I understand that the drop function is simply taking ownership of the passed value so Rust knows that once "drop" finishes, the _x can be 'dropped'.
But I though that the T had to be bound to have "Drop" trait (i.e. T: Drop) so that Rust knows it's possible to insert the call to 'drop' like _x.drop()?
The names are a bit confusing here, and I might petition to change them.
The `drop` here is just a simple library function and isn't technically related to the `Drop` trait, which is implemented with magical compiler pixie dust and allows you to define a destructor via a `.drop` method. Anything that goes out of scope has this `.drop` method called automagically.
You're correct in that if you were calling `x.drop()` explicitly, you would need to have a `Drop` bound on `T`.
If dropping was really implemented that way, every type would need to implement the Drop trait. Because otherwise there would be no way to free any memory at all.
Instead, Rust knows how to free any object. Implementing Drop is optional, and you only need to do it if you want some custom behavior at destruction.
