Intuitionistic logic is a refinement of classical logic, not a limitation: for every proposition you can prove in classical logic there is at least one equivalent proposition in intuitionistic logic. But when your use of LEM is tracked by the logic (in intuitionistic logic a proof by LEM can only prove ¬¬A, not A, which are not equivalent) it's a constant temptation to try to produce a constructive proof that lets you erase the sin marker.
In compsci that's actually sometimes relevant, because the programs you can extract from a ¬¬A are not the same programs you can extract from an A.
Depending on your lambda calculus! From a categorical perspective a lambda calculus is just a nice syntax for Cartesian closed categories (or similar, e.g. *-autonomous categories for linear lambda calculus) so you can use it to reason about anything you can fit into that mould. For example, Paul Taylor likes to do exactly this: https://www.paultaylor.eu/ASD/analysis#lamcra
If we're going to define a programming language as one that is Turing complete, it's important (in a kind of pedantic sense) to note that that includes HTML (with CSS), which can be used to encode a Rule 110 automaton, and excludes C, whose standard imposes an (implementation-defined) upper bound on accessible memory, meaning it can never, even in principle†, similarly a Turing machine, which has infinite storage. This is probably not what was intended :)
† 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.
I think it's also true that, regardless of the desirability of the feature at the time (which sibling comments discuss eloquently) people who've bought into a language are usually quite wary of also buying into extensions to that language. The very act of ratification by the committee gives this proposal a ‘feature’ that the DMC++ extension lacked in compatibility expectations over time and across implementations — it's not necessarily a comment on the technical quality or desirability of the work itself.
> It is the right tradeoff to write those structs for libraries that absolutely have to avoid dynamic dispatch. In other cases it is better to give a trait object.
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.
It takes less time to compile and that is a huge upside for me personally. I am also not ok with parametric polymorphism except for containers like hashmap
Vibe coding is painful mostly just because natural language is bad for programming in. Give it a couple of iterations and statistical programming will be at least as enjoyable as deterministic programming is today :)
The case given here for ‘why Go, not Python’ is just as applicable for ‘why Rust, not Go’.
> 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<Mutex<>>.” 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.
The colored functions point is fair, I was imprecise. My real argument is about the human cost of the compiler fighting AI-generated code, not about async semantics.
Right… but what I'm saying is that for the most part if the compiler pushes back on your LLM-generated code it's because that code is wrong. In the LLM world these are known as ‘guardrails’ and they're great because they a) provide some level of automated verification of the generated code and b) provide actionable feedback to the model to fix the code, where otherwise a human would have to notice the bug and enter the loop. The compiler pushing back on things early is a big positive for vibe coding.
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 Gladwellian direct/indirect dichotomy (or continuum) is a misapprehension of how language works. All communication is indirect in some sense because we don't have mind control powers over our fellow humans. Even saying ‘I want to buy this bread’ is indirect in a sense: you're not causing the baker to sell you the bread, nor even explicitly instructing them to, but just stating your personal internal desires. It is a cultural construct that being told someone's internal desire is supposed to function as a ‘direct’ instruction to satisfy it, and even in that there is a lot of room for ambiguity depending on context etc. For example, if I were speaking not to the baker but to my friend as we peruse the bakery together, ‘I want to buy this bread’ could have a variety of intended impacts on their actions. It could mean ‘let's come to an agreement about whether we should collectively buy this bread’. It could mean ‘pass me my wallet so I can pay for the bread’. It could mean ‘go and find me a shopkeep who can legally sell me the bread’. It could just mean ‘you are my friend and I'm telling you my internal monologue so that you can understand me better’.
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.
> The Gladwellian direct/indirect dichotomy (or continuum) is a misapprehension of how language works. All communication is indirect in some sense because we don't have mind control powers over our fellow humans. Even saying ‘I want to buy this bread’ is indirect in a sense
If you take 'direct' vs. 'indirect' literally, you are right. Everything is somehow indirect, because language tries to represent reality, but isn't identical to reality.
But you are missing the point. The real issue is information density. Indirect communication generally has lower information density: You give examples of various possible interpretations of one phrase, and the more possible interpretations there are, the lower the information density is. The longer the phrase is, the lower the information density. One can come up with a few counter-examples, where for example a very long and very indirect phrase might just have one very unique and direct interpretation, but those are rare. In general, direct communication conveys more information with less words.
Sure, if we want to shift topic from directness to density, but that's not a cultural difference either: all (spoken) languages famously transmit at about 39 bits per second [1]. Specific idioms, especially newer ones, might be a bit more or less information-dense, but there will always be others that make up for it. And if an idiom falls too far below the 39 B/s rate it'll get worn down over time to something shorter.
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.
> Are you implying other people's emotional immaturity is exclusively my problem to solve?
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.
I agree with the pragmatism. I think pragmatically yes, it is my responsibility. In a very real sense, I am able to respond, being aware of the emotions, even if perhaps the person I am speaking to is not.
I guess I have a hard time viewing this as anything but intentional emotional manipulation.
Adapting your communication doesn't have to imply deception or even insincerity, it just means understanding what's important to your target audience and making sure to address it. Sometimes that's something like financial impact or user focus; sometimes it's emotional reassurance or intellectual challenge.
In compsci that's actually sometimes relevant, because the programs you can extract from a ¬¬A are not the same programs you can extract from an A.
reply