That’s just not terribly meaningful, though. Was JavaScript the “best tool” for client-side logic from the death of Flash until the advent of TypeScript? No, it was the only tool.

Even in the original comic, that would have been appropriate, I think.

At one point the user linked to a rust-lang forum thread from 2016-2019 as evidence that Jai has “some of the tools to make the code language agnostic” or something like that. The thread started with a discussion of array-of-struct vs struct-of-array data layouts, which of course has nothing to do with making code “language agnostic.” The user also mentioned the coding influencer lunduke multiple times. So I think they are simply misinformed on a lot of points, and I doubt they’re in the closed beta for Jai.

(I read some of the comments simply because I had the same question you did. And, as it happens, the last post in the forum thread I mentioned was written by me, which was a funny surprise.)

Agile Meridian / Post Manager

Thanks for sharing this! I really think that when people see LLM failures and say that such failures demonstrate how fundamentally different LLMs are from human cognition, they tend to overlook how humans actually do exhibit remarkably similar failures modes. Obviously dementia isn’t really analogous to generating text while lacking the ability to “see” a rendering based on that text. But it’s still pretty interesting that whatever feedback loops did get corrupted in these patients led to such a variety of failure modes.

As an example of what I’m talking about, I appreciated and generally agreed with this recent Octomind post, but I disagree with the list of problems that “wouldn’t trip up a human dev”; these are all things I’ve seen real humans do, or could imagine a human doing.

Well now you’ve seen it elsewhere, too.

String escaping sucks in bash and other posix-style shells too, though.

But that’s not actually true in general; there is a default branch concept in forges, and an integration and/or release branch in most recommended workflows. That’s the trunk.

Believe me, whitespace-correct scripting is absolutely an issue.

You’re right that it’s annoying when filenames diverge right at a character that must be escaped.

For interactive use, tab-completion essentially makes this a non-issue, because shells add escaping in the appropriate places.

For scripting, where spaces are harder to deal with, unfortunately there’s just not much you can do; your two options are basically to learn all of your particular shell’s patterns for dealing with whitespace in filenames, or only write scripts in something other than a POSIX shell.

That’s fair; Python, Swift, and most Lisps all use or have previously used reference-counting. But the quoted sentence isn’t wrong, since it said no “garbage collection pauses” rather than “garbage collection.”

“Garbage collection” is ambiguous, actually; reference counting is traditionally considered a kind of “garbage collection”. The type you’re thinking of is called “tracing garbage collection,” but the term “garbage collection” is often used to specifically mean “tracing garbage collection.”

To be fair, the drop/dealloc “pause” is very different from what people usually mean when they say “garbage collection pause”, i.e. stop-the-world (…or at least a slice of the world).

This is hilarious. I’m not sure how often anyone would actually need to verbalize arbitrary binary data, but I do see an advantage over base64 since the English letter names are so often phonetically similar.

… until you have an off day, or you get bored of coding, run off to join the circus as a professional knife-juggler and your codebase is inherited by someone of more conventional aptitude.

Sometimes you even have to deal with having mere mortals on your team!

Same

You didn’t say “programmers should be aware that rust doesn’t automatically mean safe”. You said:

People just think that applying arbitrary rules somehow makes software magically more secure…

You then went on to mention unsafe, conflating “security” and “safety”; Rust’s guarantees are around safety, not security, so it sounds like you really mean “more safe” here. But Rust does make software more safe than C++: it prohibits memory safety issues that are permitted by C++.

You then acknowledged:

I understand that rust forces things to be more secure

…which seems to be the opposite of your original statement that Rust doesn’t make software “more secure”. But in the same comment:

It’s not not like there’s some guarantee that rust is automatically safe…

…well, no, there IS a guarantee that Rust is “automatically” (memory) safe, and to violate that safety, your program must either explicitly opt out of that “automatic” guarantee (using unsafe) or exploit (intentionally or not) a compiler bug.

…and C++ is automatically unsafe.

This is also true! “Safety” is a property of proofs: it means that a specific undesirable thing cannot happen. The C++ compiler doesn’t provide safety properties[1]. The opposite of “safety” is “liveness”, meaning that some desirable thing does happen, and C++ does arguably provide certain liveness properties, in particular RAII, which guarantees that destructors will be called when leaving a call-stack frame.

[1] This is probably over-broad, but I can’t think of any safety properties C++ the language does provide. You can enforce your own safety properties in library code, and the standard library provides some; for instance, mutexes have safety guarantees.

I guess what you mean is that Rust doesn’t advertise the compiler as being bug-free?

The massive difference here is that C++ has no soundness guarantees even when the compiler is working as intended, whereas Rust actually does in fact give soundness guarantees in the absence of compiler bugs.

Rust doesn’t have a formal specification other than “whatever the fuck our team hallucinated in this compiler version”

That’s simply not true. The Reference, while not an ISO-style formal spec, does actually specify most of the intended language behavior, and incrementally approaches completion over time. But even if you insist on an ISO-style formal spec, there’s Ferrocene: https://ferrous-systems.com/blog/the-ferrocene-language-specification-is-here/

it fucks your day because you’re not careful

The cve-rs vulnerability is actually not really something you’d ever write by accident. Also note that the bug report has multiple versions because, even though a “full” solution is pending some deeper compiler changes, the first two three versions of the exploit are now caught by the compiler. So, like I said, the compiler bugs do get fixed over time.

Yeah, and that falls under the first category, bugs in the compiler: https://github.com/rust-lang/rust/issues/25860

(All exploits in that repo are possible due to that bug.)