† Obviously, for physical reasons given our current understanding of cosmology, no _implementation_ of a language can ever really be Turing-complete, but some language definitions are theoretically compatible with Turing-completeness, and others aren't.

IMO it is a hack to use dynamic dispatch (a runtime behaviour with honestly quite limited use cases, like plugin functionality) to get existential types (a type system feature). If you are okay with parametric polymorphism/generics (universal types) you should also be okay with RPIT (existential types), which is the same semantic feature with a different syntax, e.g. you can get the same effect by CPS-encoding except that the syntax makes it untenable.

Because dynamic dispatch is a runtime behaviour it inherits a bunch of limitations that aren't inherent to existential types, a.k.a. Rust's ‘`dyn` safety’ requirements. For example, you can't have (abstract) associated types or functions associated with the type that don't take a magic ‘receiver’ pointer that can be used to look up the vtable.

In this particular case maybe Rust isn't the right choice because (idiomatic) Rust is designed for the case where you care about your memory management, and for your blog you probably don't. But that's a comment on the suitability of Rust for blogs, not a comment on the suitability of Rust for vibe coding.

> The borrow checker catches real bugs. The type system is rigorous. The compiler says no, and when it says no, it’s right. The problem is that the compiler says no too much.

> When an AI writes Rust, the borrow checker fights the generated code. I — the human — spend my taste budget on lifetime annotations instead of architecture. Instead of saying “why do we keep both around?” — five words that collapse complexity — I’m saying “add a .clone() here” or “wrap this in Arc>.” I’m using Layer 5, the most expensive layer, on problems the language invented.

These paragraphs are inconsistent. Either lifetimes catch real bugs — i.e. they reflect the ‘real’ (runtime) world, and when the compiler rejects some generated code it's because that code is buggy — or the language merely invented the problems they exist to solve and you're wasting your time thinking about them. (In my experience it's about 80:20 respectively, but for the level of code LLMs generate probably higher.)

> Go has goroutines. You write `go func()` and it works. Rust has colored functions.

Go also has coloured functions, but the only functions that are allowed to not be async are FFI. Go marks all functions as async just as JavaScript marks all return types as `any` — with the exception that sometimes Go is wrong and you have to remember where.

> One crate uses async-std. Now you have two runtimes.

Only if you start an async-std runtime. (There are compatibility options, too.) There are certainly occasional pitfalls when writing cross-runtime code in Rust, but relatively few these days, and not really the ones the article worries about.

> Come back to a Rust project after three months. Run `cargo update`. Half your transitive dependencies don’t compile because a trait bound changed in a crate you’ve never heard of.

If you lock your dependencies (which is in fact the case by default, and what you're explicitly opting out of by running `cargo update`) this doesn't happen. If you change the version of a Go dependency, it may also change API. Rust just has a tool to automate this workflow. If you choose not to use it you'll get the Go experience.

There are valid reasons (IMHO) to reject Rust for vibe coding (all else being equal). They're not these though.

>> you can emulate a Turing-complete computer in a Turing-complete language

> If you've created semantics that allow for incomplete reads/writes, you allow incomplete reads/writes.

That's true, but isn't entirely relevant to the discussion for a few reasons. First, Turing-completeness does not require the existence of race conditions; it is perfectly possible to have a Turing-complete language (for example, standard Turing machines!) that doesn't have the ability to define data races. Second, my entire point here is that you don't have to ‘create semantics that allow for incomplete reads/writes’. That semantics is a subset of the standard actor semantics. In fact, I am claiming more broadly that all reads/writes are either complete or incomplete (to borrow your terminology) depending on your semantic perspective. The reads/writes of standard hardware shared memory are also ‘complete’ from the perspective of reading/writing individual words; the problem is just that almost all applications need a notion of ‘completeness’ that is higher-level than that, which gives rise to the (relativistic!) notion of ‘data race’.

To phrase my point here a bit differently, the distinction between a data race and a logical race is purely the scope of the expected consistency. In the standard multi-threaded case as well, if you read a single word from the memory it will definitely be consistent — you'll get the result of either one write or another, never half of the word from one write and half from the other. But values in real programs are usually bigger than a single word, and once you read two words from the memory it becomes possible (ignoring for the sake of argument the facilities modern memory provides for reading larger memory ranges atomically; feel free to replace ‘word’ with your atomic unit of choice) to get one word from one write and one word from another. As words these are consistent — they're both valid words and they both come from an intentional write — but put together they may not form a coherent value of the higher-level type you meant to read. This is how you get ‘corrupted’ data: the notion of corruption comes not from the memory semantics but from the semantics of the type that the memory is being used to represent. This applies exactly the same to Mem: each word is, as you say, consistent, but if you try to read a value by doing two reads, the resulting value may be ‘corrupt’ (formed by the interleaving of two writes) depending on what other threads are doing with Mem at the time.

Mem as I set it out above is an example of multi-threaded, mutable data. Another process can't alter the data you've received, indeed, just as in a shared-memory system another thread can't alter the data after you copy it out of shared memory into your registers or an unshared memory space. But if you're storing the data in shared memory (a.k.a. requesting it from Mem every time) then you are racing with other actors who have access to Mem.

The difference is that you're not limited to just ‘read address’ and ‘write address’ operations: the shared actor gets to define higher-level operations that are atomic over larger sections of code.

If you are shortening your communication you are doing it by reducing the information content. In some cultures it's acceptable to spend longer buying bread than in others, so you might take the time to exchange more information with the baker. But that is a (to them, if not to you) valuable interaction that they have chosen to have, filled with information whose exchange is (to them) just as important as the price of bread.

[1]: https://www.science.org/doi/10.1126/sciadv.aaw2594

If you interpret the language of a different culture (separated by space or time — try reading the ‘flowery’ language of Victorian or Elizabethan literature) too literally, it reads as ‘indirect’. But that doesn't mean that the native speakers from that culture consider it so. You're simply missing the cultural context that makes their phrasing as ‘direct’ to them as ‘I want to buy this bread’ is to you.

Emotional maturity (from most standpoints) does not mean being completely emotionally unaffected by other people's communication. Insofar as it is emotional immaturity that gives rise to a particular emotional response it might be ethically that person's duty to work on it, if that's how your personal ethics works. But from a pragmatic perspective if you want to get something done that involves that person as a colleague or collaborator it's probably not going to be productive to continually bash your head on their psychological quirks until they go to therapy. You'll have much more luck adapting your own communication to be more aligned with their needs, regardless of how reasonable you personally think those needs are.

If you can't or don't want to put in the effort to do that your other option is to make sure you surround yourself with people who can already communicate effectively and relatively comfortably in the communication style you consider natural. You can cut off relationships, move jobs, or fire people to purge everyone else from the circle of people you have to interact with. But you'll be missing out on all the positive contributions of those people, who probably bring viewpoints alien to you, and you run the risk of sycophancy. Plus you'll have a harder time finding people to date/collaborate with/employ/… if you restrict your pool that way.

In practice I think people tend to end up somewhere in the middle of that spectrum. They'll decide a maximum investment of energy they're willing or capable of putting into accommodating other people's needs, and make sure that work × time doesn't exceed that threshold.

There's a reason software has tutorials as well as reference documentation. Sometimes telling someone something directly isn't as effective at getting them to understand it as explaining it more slowly or obliquely. Sharing your learning journey to arrive at the understanding is (one possibility for) presenting a working path to understanding.

It's also the case that, especially when someone's knowledge diverges a lot from your own, it may not be obvious to them what information is relevant to you — and it may even be surprising to you. As an extreme example, there was a bug where OpenOffice wouldn't print on Tuesdays [1]. This happens a lot with non-technical users, but can also happen with other technical people who don't have the same level of understanding of a particular subsystem (in both directions — if you understand it better they may not know what information is key to understanding its behaviour, and if they understand it better they may not realize what information they're taking for granted that you don't know — e.g. the famous joke about ‘monads are just monoids in the category of endofunctors, what's the problem?’). As I've spent more time in technical discussions I've got better at homing in on the information I need — but I can't materialize information that wasn't given to me in the first place. So I'd rather people shotgun information at me than narrow it down to just the one point that they think is relevant.

[1]: https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161...

Nobody argues that any of these approaches is a silver bullet for all concurrency problems. Indeed most of the problems of concurrency have direct equivalents in the world of single-threaded programming that are typically hard and only partially solved: deadlocks and livelocks are just infinite loops that occur across a thread boundary, protocol violations are just type errors that occur across a thread boundary, et cetera. But being able to rule out some of these problems in the happy case, even if you have to deal with them occasionally when writing more fiddly code, is still a big win.

If you have an actor Mem that is shared between two other actors A and B then Mem functions exactly as shared memory does between colocated threads in a multithreaded system: after all, RAM on a computer is implemented by sending messages down a bus! The difference is just that in the hardware case the messages you can pass to/from the actor (i.e. the atomicity boundaries) are fixed by the hardware, e.g. to reads/writes on particular fixed-sized ranges of memory, while with a shared actor Mem is free to present its own set of software-defined operations, with awareness of the program's semantics. Memory fences are a limited way to bring that programmability to hardware memory, but the programmer still has the onerous and error-prone task of mapping domain operations to fences.

To make this more practicable you might be able to drastically narrow the context of the information, e.g. to the current task. So you could have an app that watches everything you do and tells you if you're (possibly) about to break a law. The extreme version of this looks like wearing a body camera at all times and having a little ‘voice of the state’ in your ear that tells you what your legal options are on every circumstance. Maybe a little dystopian, especially if it starts reporting you if you don't follow its guidance.