pcwalton

Pretty sure the menu bar was Carbon in Snow Leopard, which was the same release that discontinued Classic. Lots of Cocoa widgets called into HIToolbox under the hood. QuickTime wasn't fundamentally changed. And iTunes of course was Carbon code for a very, very long time.

It's not really practical to do this outside of simple cases. For example, a modern userspace GPU driver must allocate lots of memory in hundreds if not thousands of places to implement a standard API and there's no way around that.

Userland system DLLs need to allocate memory too.

Dioxus is much easier to understand though, and Leptos and Yew are just HTML. One of the core issues is that (a) a scene format for editors, (b) a SwiftUI-like DSL for UI, and (c) a DSL for spawning game objects are just different problems. A single syntax that tries to cover all three ends up being a compromise that satisfies few.

Some great stuff in this release. I contributed some rendering code, most notably reducing the renderer to O(number of changed entities) on the CPU, that went unmentioned in the release notes.

I do have to say, however, that BSN syntax isn't good and is getting worse. There are too many sigils, and -- to separate list elements (!) is an indication that it's been designed into a corner. The fact that it's not LR(1) should have been an indication that it was misdesigned. The scene format should be redesigned to be editor-first, with ease of VCS merging as a paramount consideration.

> 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.

I believe HotSpot is usually faster than GCJ.

Your note taking app doesn't need AI, but it also doesn't need OLE, which represented an equally hot buzzword ("software componentry") of the 90s that Microsoft was trying to shoehorn into everything.

Every generation has its hype cycle; it's nothing new.

My recollection is that Brian Anderson, who came from the C# world, was an early advocate of the easily-googlable error codes that Microsoft compilers use a lot, and pushed to get them in. That was a good call. (In general Brian had a lot of behind-the-scenes positive influence on Rust: my favorite brson-ism is "if the code doesn't have a test it doesn't exist".)