> From all state actions I’ve seen for a decade straight in the crypto space, this largely seems to be an education issue that makes the state’s ability to prosecute a brief privilege
Or, you know, they could come up to you in a San Francisco public library while your computer is unlocked and logged into your account, slap handcuffs on you, and image the contents of the laptop's RAM, establishing proof beyond a reasonable doubt that you had access to the Monero account in question. Just like they did with Ross Ulbricht.
If there's anything you should learn from the history of state actions in this space, it's that the USG is very good at overturning naive assumptions about the real-world anonymity of these technologies.
> Apple seems to have lost its academic roots, and suffers for it now. Or I should say, its customers suffer while it grosses almost half a trillion dollars per year. At least with vibe coding we can just whip up a Preview app in an afternoon, so maybe none of this matters anymore.
Eh, I'm with Apple on this one: we can just use Ghostscript. Apple's move effectively forces the few applications that need to use PostScript on macOS to migrate from a proprietary PostScript implementation to an OSS one, which strikes me as ultimately a good thing.
You can run arbitrary computations on iOS devices if they're written in JavaScript, WebAssembly, or Swift (via Playgrounds). All of these are Turing complete, and all three compile into machine code. What you don't have without an Apple developer account is direct machine code access.
Also note that apps like Pythonista allow you to write programs that call arbitrary Objective-C APIs without permission from Apple. This means that you have a Turing-complete language running unsigned code that can do anything a signed app can do. Your programs do, however, execute slowly.
Sure, but the relevant comparison isn't between languages: it's between a state-of-the-art JIT implementation of one language and a likewise-state-of-the-art AOT implementation of the same language. Unfortunately there aren't many examples of this; most languages have a preferred implementation strategy that receives much more effort than the other one.
If Microsoft had adopted this attitude, then by now Excel's market share would probably be 0% and Google Sheets' would be 100%. Microsoft doesn't add features because they like bloated software; they add features because the market demands them, and the market demanded support for more than 65,535 rows.
> I’d be much more excited about that promise [memory safety in Rust] if the compiler provided that safety, rather than asking the programmer to do an extraordinary amount of extra work to conform to syntactically enforced safety rules. Put the complexity in the compiler, dudes.
That exists; it's called garbage collection.
If you don't want the performance characteristics of garbage collection, something has to give. Either you sacrifice memory safety or you accept a more restrictive paradigm than GC'd languages give you. For some reason, programming language enthusiasts think that if you think really hard, every issue has some solution out there without any drawbacks at all just waiting to be found. But in fact, creating a system that has zero runtime overhead and unlimited aliasing with a mutable heap is as impossible as finding two even numbers whose sum is odd.
> I wonder if any of those who claim that the RISC-V ISA is simple can remember without searching the documentation how to implement the checks for integer overflow after each arithmetic operation.
I mean, I can't give you the Hacker's Delight magic numbers for expressing integer division by a constant via multiplication on AArch64 or x86-64 off the top of my head either, but that's what we have compilers for. The fact that you sometimes have to look up how to do simple things is just part of programming.
It's really strange to me that Microsoft has never added an ArgvToCommandLineW(). This would solve most of the problems with Windows command line parsing.
Whether a hypothetical alternate world in which Rust didn't have a package manager or didn't make sharing code easy would be better or worse than the world we live in isn't an interesting question, because in that world nobody would use Rust to begin with. Developers have expected to be able to share code with package managers ever since Perl 5 and CPAN took off. Like it or not, supply chain attacks are things we have to confront and take steps to solve. Telling developers to avoid dependencies just isn't realistic.
> And this also means statutory maximum sentences come into effect, and I personally don't know how that interacts when you've got multiple charges.
The judge can order consecutive sentences for multiple charges, making the effective statutory maximum in such cases very long indeed. Sholam Weiss [1] was an extreme example of this, racking up 845 years for a $450M fraud in the 90s.
> Most C++ apps are mostly memory safe and that's just fine. It's ridiculous to suggest that this secondary artifact concern is raised to primacy for all projects.
It's demonstrably not "just fine", as the steady stream of security issues that hurt real people will attest to. It's also important to remember that C++ is an extreme outlier here: the majority of programs written in 2023 are in memory-safe languages. Memory safety is not some weird new thing; it's the norm everywhere but in C and C++, usage of which declines every year.
> Most projects do not require what Rust provides at the cost it provides it at.
If this is true, it's because most projects should use a GC'd, memory safe language, not because most projects should use memory unsafe languages. There is little to no place for memory unsafe languages such as C++ for new projects in 2023.
> Also I think that Rust is a 'V1' version of a borrow checker and I can't wait for newer iterations which I think will be better.
This is the literal definition of vaporware, without a specific plan for how "newer iterations" will do it better. People have been searching for silver bullets for years in this space and nobody has really found a way to improve on the balance Rust has found without introducing garbage collection of some kind. I personally don't believe a "better borrow checker" can exist without GC (which is not such a bad thing, by the way--in my experience, C++ and Rust developers tend to be unfairly dismissive of garbage collection).
> And yes, we still hate all the jokers coming in from California who are gladly dropping millions of bucks to buy up houses that just a few years ago were only worth a few hundred thousand.
> Thanks for visiting, but Austin is full. Yankee go home, please.
This NIMBY mentality is why Austin is rapidly catching up to California in housing prices. The advantage is not going to last long at this rate.
(And before you start, I'm like 4th generation native Texan.)
> Step 2: Build complex logic to untangle your nonsensical use of async/await and force things to run synchronously in the backend without the user knowing. See? A 5% CPU optimization right there!
Addressing your snark, I assume this optimization is targeted at places where you have a single "await" expression in the source that might call different functions at runtime, only some of which need to await.
Or, you know, they could come up to you in a San Francisco public library while your computer is unlocked and logged into your account, slap handcuffs on you, and image the contents of the laptop's RAM, establishing proof beyond a reasonable doubt that you had access to the Monero account in question. Just like they did with Ross Ulbricht.
If there's anything you should learn from the history of state actions in this space, it's that the USG is very good at overturning naive assumptions about the real-world anonymity of these technologies.