creata

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.

That's... uh, an interesting approach to security.

If it runs inside the sandbox and the guest is compromised, can't the guest just lie?

The part that worries me here is the diff. Does it happen in the host or in the guest? What code gets run when you run `yoloai diff`?

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.

Two very minor suggestions for the demo:

1. I don't know what the "Docxtemplater" button does, but it eats my document without warning and that's annoying.

2. It would be nice if the page came with some example .docx files we could see it work on.

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.

Sorry, what do you mean?

The real numbers are uncountable. (If you're talking about constructivism, I guess it's more complicated. There's some discussion at https://mathoverflow.net/questions/30643/are-real-numbers-co... . But that is very niche.)

The set of things we can compute is, for any reasonable definition of computability, countable.

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.

Iirc Gauss suggested "lateral numbers". Not the worst idea, but it's too late now.

Clifford algebras are harder to philosophically motivate than complex numbers, so you've reduced a hard problem to a harder problem.

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.

greatly lags Racket performance

This is a different implementation of Guile, though. Has Hoot (on, say, V8) been benchmarked?

It's the static site generator of vibe coded projects.

I want to be able to make art and music and movies and games.

Then make them. What's stopping you?

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.

It seems inevitable that they'll soon be used as the starting points for developing almost all video game environments.

Almost all video game environments? No way. That statement really needs to be qualified with the genres of games you're considering.

Functions are just a different kind of value. Needing to know the type of the values you're using when you use them isn't "nonlocal reasoning".

And it's not like curried function application involves type-driven parsing or anything. (f x y) is just parsed and compiled as two function calls ((f x) y), regardless of the type of anything involved, just as (x * y * z) is parsed as ((x * y) * z) in mainstream languages. (Except for C, because C actually does have type-driven parsing for the asterisk.)

Another way to look at it: languages like Haskell only have functions with one argument, and function application is just written "f x" instead of "f(x)". Everything follows from there. Not a huge difference.

Huh? Currying doesn't require any nonlocal reasoning. It's just the convention of preferring functions of type a -> (b -> c) to functions of type (a, b) -> c. (Most programming languages use the latter.)

Even if a machine generates them.

That sounds wonderfully meritocratic, but in the real world, a machine generating it is a very strong signal that it's bullshit, and the people are flooding maintainers using the machines. Maintainers don't have infinite time.

The ideal program is clear enough to be self explanatory.

That depends on what you're doing and who you expect to be reading your code, doesn't it? Sometimes what the human needs and what the computer/runtime needs are too far apart.

Don't these two situations (watching vote counts; understanding a complicated statistical argument that the vote is tamper-free) require the same kind of trust?

1. In both cases, everyone is theoretically capable of checking it themselves; they're theoretically zero-trust. In the former scenario, I'm theoretically capable of attending the vote count, and in the latter scenario, I'm theoretically capable of learning the statistics needed to verify the argument.

2. In both cases, most people cannot (or will not) practically check it themselves, and is trusting that someone they trust is doing the checking for them.

I'm not saying they're the exact same situation, but they both ask for a large amount of trust from most of the voters.

There's plenty of evidence of voter suppression in the US.

https://en.wikipedia.org/wiki/Voter_suppression_in_the_Unite...

I don't know why so many people in this thread are asking this, but as has been said elsewhere in this thread:

* It does apply to most other internet systems.

* Things like banking fraud can be detected and remedied. Election fraud is much harder to detect and even harder to remedy.

* Voting requires anonymity. Most internet systems are not anonymous: you are identified by your IP address at the very least.

The specific comment by popalchemist you're referring to is actually fine (they're talking about voter suppression, which is a problem in the US), and isn't at all one of the claims that hintymad says people are making.

Australia, as far as I know, doesn't require voters to show identity documents, and they seem to take election integrity very seriously.

Maybe, but the election ink stuff feels a bit overboard.