I don’t think Rust needs this; Rust has done great for the last decade with the coherence rules it has. I am glad to not have to worry about this, and to not have to worry about any of the downstream problems (like linker errors) that coherence structurally eliminates.
It’s odd that the article identifies Apple’s hardware as a limitation for AI. I don’t think this is the case. If anything it’s the opposite, and makes Apple’s lack of execution more mysterious.
I was running Stable Diffusion on my iPhone two years ago. You can get quite good open weights models running on-device today. What’s going on over there?
The example you are discussing starts with the following user query:
<example>
<user>how should recent semiconductor export restrictions affect our investment strategy in tech companies? make a report</user>
<response>
Finding out where the user works is in response to an under specified query (what is “our”?) and checking for internal analysis is a prerequisite to analyzing “our investment strategy”. It’s not like they’re telling Claude to randomly look through users’ documents, come on.
After 8 years of programming ~exclusively in Rust it’s easy for me to take this for granted by forgetting that linker errors even exist — until I am rudely reminded by occasional issues with C/C++ code that ends up in the dep tree.
This property is downstream of the orphan rules, and given the benefit I wouldn’t give them up.
This article lists international money transfers as a non-useful application of blockchains. USDT on Tron alone is now settling 1.25T$ (1/3 of Visa’s annual settlement volume).
I am broadly anti-Worldcoin but it is reasonably competently executed at a technical level. It would be good to understand what they actually did before declaring it to be impossible.
- Intel CPUs can use AESNI to do AES at 0.64 cpb
- AMD Zen cores have two AESNI cores and can achieve 0.31 cpb
- Vectorized AES instructions (supposed to ship in Ice Lake five years ago, but maybe a casualty of Intel's AVX512 mishaps) were expected to bring it down to 0.16 cpb
In some sense this isn't a "fair" comparison in that it's fast because there's hardware acceleration, but that doesn't really matter, the hardware is there so it might as well be used.
A lot of discussion about async Rust assumes that the reason one would want to use async/Futures is for performance and scalability reasons.
Personally, though, I would strongly prefer to use async rather than explicit threading even for cases where performance wasn’t the highest priority. The conceptual model is just better. Futures allow you to cleanly express composition of sub-tasks in a way that explicit threading doesn’t:
Yes, that’s exactly the issue. You trade that friction for not having the friction of type errors in queries at runtime. Whether that tradeoff is a good one depends on your situation and preferences.
(You can also check in the results of the database queries, so you only need the db in the build stack when you touch db-related code).
One use case for generating group elements with verifiably unknown discrete logs is for a commitment scheme, like a Pedersen commitment.
In a Pedersen commitment, you have two generators, let’s call them G_value and G_blinding. To commit to a value v, you choose a random blinding factor v_blinding and form the commitment C_v as
C_v = v * G_value + v_blinding * G_blinding
Later, you can publish (v, v_blinding) to open the commitment.
Pedersen commitments are really useful because they’re homomorphic: adding commitments produces a commitment to the sum of the values. So you can use them to do a limited form of computation on hidden data.
Where does the verifiable generation come in? Since G_value and G_blinding are both in the same prime-order group, there exists _some_ value r so that G_value = r * G_blinding. If someone knew this relation r, they could forge commitments, for instance
and claim that C_v is a commitment to the value v+1 instead, because knowledge of the relation r lets them “slide value” between the “basis vectors”.
So Pedersen commitments are only _computationally_ binding: finding r requires solving the discrete logarithm problem, which we assume is hard, as long as the generators G_value and G_blinding were generated through some verifiable procedure.
On the other hand, though, they’re perfectly hiding, since knowing r lets you find a valid blinding factor for _any_ value, so even an infinitely computationally powerful adversary can’t determine which value was used after the fact.