Unfortunately not out of the box but the demo runs really well on M4 chips. It can be enabled as such (I'm on Sequoia):
1. Safari > Settings > Advanced > Show features for web developers
2. Develop > Feature Flags > Search for WebGPU
Safari Tech Preview may have it enabled by default.
> Consequently, this also means you cannot define two error variants from the same source type. Considering you are performing some I/O operations, you won't know whether an error is generated in the write path or the read path. This is also an important reason we don't use thiserror: the context is blurred in type.
This is true only if you add #[from] attribute to a variant. Implementing std::convert::From is completely optional. Personally I don't prefer it too as it ambiguates the context. I only use it for "trivially" wrapped errors like eyre::Report.
SNAFU follows much the same idea: we have an attribute you can add [0] when you want to allow directly implementing `From`. Like thiserror, you can also mark an error as transparent [1] when even the error existing doesn't provide useful information.
>The Kroll Portal will remain accessible after the Bar Date to amend or file a claim. Absent order from the U.S. Bankruptcy Court for the District of Delaware, any claims filed after the bar date may be disputed.
So it might still be worth filling out the form - who knows.
Big kudos to Rust compiler devs about their sophisticated type system and its kind (and highly intelligent) help messages. A little concern is that AFAIK its complexity in type systems and other static analysis things require deep domain knowledge, so in a far, far future there may be a lack of "core" engineers comparing to a demand much increased at that point. This kind of change looks like already requiring deep understanding of both Rust's type system and internal compiler structure to implement.
IMHO the mentioned examples of complexity like multiple type variables and lifetimes with bounds are for who "really" wants compile-time contracts. These are mostly opt-in so higher level use cases(like writing backend business logics) should not care about that, just wrapping everything with Boxes and Arcs.
Of course Rust is not perfect; there is some 'leakages' of low level aspects to high level like async caveats(recursion, pinning, etc.). I'm not sure how these can be avoided. Maybe just trial-and-errors for all..?
I do remember the compiler constantly suggesting lifetimes to me as a newcomer to the language, so it didn't really feel that opt-in. Quite a lot of the suggestions also started to look like someone poured alphabet soup all over the code.
That's because the code triggering compilation error is using reference. If you use Rc or Arc (which pays runtime cost) there should be no lifetime at all.
Albeit I admit there somewhat exists a community sentiment like "if you use Rust, you should maximize its zero cost abstraction feature so lifetime is good and generics good", and my (minor) opinion is that, it's not always true to all users of Rust.
And the clumsy Arc<Mutex<Something<TheOtherThing>>> makes users feel bad about using runtime cost paid types. Maybe we should introduce easy Rust dialect which transpiles into Rc/Clone everywhere but I doubt it's trivial to transpile.
> And the clumsy Arc<Mutex<Something<TheOtherThing>>> makes users feel bad about using runtime cost paid types
Yeah, this would look worse than any of the "complicated syntax" examples in the blog post.
A language should be designed so that the typical case is the easiest to read and write. Syntax for the most common abstractions. Rust forces you to be explicit if you want to do an Arc<Mutex<Box>>>, but lets you inherit lifetimes almost seamlessly. That means it's not idiomatic to do the first, and it is to do the second.
Languages with a lot of historical baggage don't follow this pattern: if you want to write idiomatic modern C++ it's going to be uglier and more verbose than you see in K&R. But in Rust's case it's clear what the designers encourage you to do.
Simple != idiomatic. It's perfectly idiomatic to `Arc<Mutex<Box>>` in Rust, and it is more complex because it deals with more concerns than a simple reference, namely being thread-safe. Sometimes you need that, sometimes not, but you have to be explicit about it.
That's mostly because borrows are a curiosity of Rust that newcommers are quickly introduced to while they are mostly just a perfomance gimmick.
If you come to rust from high level language you can just do everything with Rc and cloning.
It's still hard because Rust, in opposition to every pipular language, is a value oriented language. But at least you won't have much contact with alphabet soup.
Do we have a better method of verifying compilation output than just re-executing the compiler with same source, than comparing the output? TEE attestation could be a thing(albeit it could be a "trusted" third party which occasionally be broken).
Albeit 1.6PB/day may be somewhat exaggerated, comparing Binance to Ethereum needs much more consideration including:
- Ethereum's transaction throughput is normally 12~20tx/sec so there cannot be a "high-frequency trades" on Ethereum smart contracts with naive contract interaction(it will cost enormous fees). There are scaling concept like "layer-2" or "layer-3", but they still cannot beat highly optimized centralized server applications. Decentralized exchanges have different schemes to centralized ones to reduce txs to discover the price(keyword: AMM, "automated market maker")
- The transactions per sec metrics are just recording "confirmed" txs by the blockchain, and many "retail-squeezing" trading txs (called MEV, maximal value extraction) are competing behind the blockchain and only one tx is chosen by the blockchain, which will rebate most profits to the blockchain validator(which is analogous to the HFTs on the centralized exchanges).
- The blog post's argument would count all logs of intermediate hops, like L7/L4 proxy and matching engine and so on, and Ethereum's full node storage is only a single component which is almost like a non-parallelized matching engine. Maybe we should also count logs of public RPC nodes of Ethereum? (Also many txs are not gossiped to the public mempool so these are hard to count)
Interesting project and kind of tangential topic, will JIT compilers still be widely adopted given they are considered a critical attack vector when it misbehaves? I wonder if there is an effort to formally verify its safety or do a complete redesign to ensure it.
JIT compilers provide so much performance boost to code that I don't see how they could be realistically dropped. It'd be like not using speculative execution on cpus because of spectre and similar attacks.
Great work! I really enjoyed the interactivity. Actually I already was aware of the concept of zero-knowledge proof from the wonderful article by ZCash(which is a privacy-oriented cryptocurrency) core developer Matthew Green, worth to check it out: https://blog.cryptographyengineering.com/2014/11/27/zero-kno...
My two cents of the ZKP illustration is that directly using hashes are more likely to convince "computer-friendly" people to introduce the commitment scheme.
