creata

I don't think you're wrong overall, and it jives with tripleee's reply, but I don't think wanting end-user software to be less buggy than it currently is is asking for "flawless" software.

Serious question from a consumer of software: if software can be improved so effortlessly now, why isn't it getting better?

Like, why is it all still so buggy? Why does no website seem to consider 96 PPI displays in its design? Why don't we have ostensibly useful features like undo trees everywhere? Why is everything still a RAM hog? Why does the proportion of websites that pay no heed to accessibility seem to be going up rather than down?

I'm told we're living in the future, but it sure doesn't feel like it.

Thanks. (More detail: Git added signed commits in Git 1.7.9, which was released in 2012.)

> It's purely a consistency check. The security parts are elsewhere

Sorry if the video answers this, but how does commit signing work if it doesn't rely on the hash algorithm being resistant to at least second-preimage attacks?

I've seen ordinary people forget things they've done every day for years. It's not something that never happens.

What uncomfortable truths?

I'm probably being naive here, but with theorem proving, if you have a problem then you can check whether a given solution is correct, letting people make things like AlphaProof, no? I would think that the open-endedness of software development in general would complicate that.

If you take the linked benchmark and use the latest compiler version, the std::variant version is faster. The annoying thing about std::variant (and with some other features of modern C++) is that it generates a bunch of code that the compiler has to optimize away.

And the code might be faster, too, like in that 2005 series of articles by Raymond Chen and Rico Mariani (in which one of them wrote a program in C++ and the other wrote the same program in C#).

https://devblogs.microsoft.com/oldnewthing/20060731-15/?p=30...

https://learn.microsoft.com/en-us/archive/blogs/ricom/perfor...

They're a bit old and missing some details, but I like Agner Fog's manuals.

https://www.agner.org/optimize/

Most applications (including most applications that care about numerical performance) should not use -ffast-math.

> If AI becomes at least an order of magnitude more capable than humans at software development

Doesn't it only need to become an order of magnitude more capable than humans at theorem proving, not general software development?

> This is not true. It has been done. I’ve seen it done for an entire OS too

That might be what pron's talking about. seL4 is only 10-20K lines of code as far as I remember. Maybe you have another OS in mind, though.

> C++23 Rust-like move semantics can be used

What C++23 feature allows that?

It's in the first link in the post.

> but even the way we talk about technology today. You need to use X, do Y or you're "not going to make it" / "escape the permanent underclass". It's bleak.

That's just how people market things these days, preying on desperation and fear of missing out. It's not how normal humans talk, I hope.

Rust has its downsides, too.

The big one for me is that Rust packages tend to pull in dozens or hundreds of transitive dependencies - C/C++ code tends to be monolithic, so it has fewer maintainers who could become compromised.

> Zig is the first language that makes arenas almost user-friendly and hopefully sufficiently composable to withstand programming evolution

Are you referring to that every function that allocates explicitly requests an allocator by convention, or to something else?

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.