I have been watching people write UI frameworks in Rust for over a decade, you meanie.
The results tend to involve more dynamic allocation than you'd see in a garbage-collected language, or tons of reference counting (e.g., in Leptos) that acts as a less efficient GC. I've read many of raphlinus's posts, and while they're always interesting, the total experience in the Xilem examples just seems like much more effort than using FFI (even C FFI) to glue to something more workable.
Your comparison to assembly is very bizarre - languages of the sort I mentioned are usually at least as safe as Rust, and the "scripting language for top-level logic + compiled language for the bits that need to be fast" combination is ancient. In fact, your vague allusions to "a stable base, without infinite danger everywhere" shows much less understanding of what's at stake, in my view.
I'm sorry my question wasn't enlightened enough for you.
And this is a news aggregator. Not the official discussion forums or anything. People can ask small insignificant questions here, or so I thought.
I'm so tired. You write one measly paragraph that could simply be ignored and someone calls you a "perpetuate drain". Even the chatbots have more humanity than you've got.
What's the rationale for using Rust to write a UI? Using a scripting language (or at least a garbage-collected language) is much less restrictive, and it's not like the "what goes where" UI code is especially performance-sensitive.
> The only practical defense is for these frontier models
Another practical defence for many of these devices would be to just disconnect them... I feel like an old man yelling at a cloud, but too much is connected to the Internet these days.
I think that what matters here (and what I think is the natural interpretation of "not every real number is computable") is what the theory thinks is true. That is, we're working with internal notions of everything.
> For computers, you could use a complex number since it's effectively a cache of sin(a) and cos(a), but you often want general affine transformations and not just rotations, so you use a matrix instead.
That makes sense in some contexts but in, say, 2D physics simulations, you don't want general homogeneous matrices or affine transformations to represent the position/orientation of a rigid body, because you want to be able to easily update it over time without breaking the orthogonality constraint.
I guess you could say that your tuple (c, s) is a matrix [ c -s ; s c ] instead of a complex number c + si, or that it's some abstract element of SO(2), or indeed that it's "a cache of sin(a) and cos(a)", but it's simplest to just say it's a unit complex number.
> The idea is we can't actually prove a non-computable real number exists without purposefully having axioms that allow for deriving non-computable things.
> If you want to rotate things there are usually better ways.
Can you elaborate? If you want a representation of 2D rotations for pen-and-paper or computer calculations, unit complex numbers are to my knowledge the most common and convenient one.
I hate when people casually move "between" Q and Z as if a rational number with unit denominator suddenly becomes an integer, and it's all because of this terrible "a/b" notation. It's more like (a, b). You can't ever discard that second component, it's always there. ;)
Why would we expect most real numbers to be computable? It's an idealized continuum. It makes perfect sense that there are way too many points in it for us to be able to compute them all.
In my opinion there's nothing wrong with it per se, but (a) it's still worth mentioning, because most people have the impression that Waymo cars are completely unassisted, and (b) it makes me wonder how feasible Waymo's operations would be if it weren't for global income inequality.
The results tend to involve more dynamic allocation than you'd see in a garbage-collected language, or tons of reference counting (e.g., in Leptos) that acts as a less efficient GC. I've read many of raphlinus's posts, and while they're always interesting, the total experience in the Xilem examples just seems like much more effort than using FFI (even C FFI) to glue to something more workable.
Your comparison to assembly is very bizarre - languages of the sort I mentioned are usually at least as safe as Rust, and the "scripting language for top-level logic + compiled language for the bits that need to be fast" combination is ancient. In fact, your vague allusions to "a stable base, without infinite danger everywhere" shows much less understanding of what's at stake, in my view.
I'm sorry my question wasn't enlightened enough for you.
And this is a news aggregator. Not the official discussion forums or anything. People can ask small insignificant questions here, or so I thought.
I'm so tired. You write one measly paragraph that could simply be ignored and someone calls you a "perpetuate drain". Even the chatbots have more humanity than you've got.