Ironically Rust (hence the name) was originally billed as the language that did nothing novel at all, but just productized a bunch of concepts that were already well understood in the PL field :)
I think that a programming language — much less a programming language _ecosystem_ — is such a large space of decisions that statistically you're inevitably going to let a few of them slip. And even (as in Rust's case, initially) if you don't aim to do anything new, the combination of the interactions between features and the ways people want to use your language culturally can land you places you never anticipated when doing the initial language design. I don't think anybody in the early years of Rust could have anticipated how async would look today, for example, and IIRC Graydon Hoare still doesn't like where it ended up.
Then, there's the old software adage that the right decision for one level of adoption doesn't necessarily translate to another level. Because it's so hard to predict the impact of early decisions, early versions of programming languages are basically prototypes: your aim is to get out enough of the core differentiators of the language that people can start playing with it and _imagining_ what it will be like to work with the final thing. Part of that involves making the barrier to entry as small as possible (e.g. bundling a full build system into the precompiled compiler executable) but it also implies that you don't want to spend more time than necessary on things that work the same as other languages. If you can see the ‘obvious omission’ in the language then that means you can already imagine how it will work when that thing is implemented! As an implementor you can always flesh it out as you approach 1.0, or, if the right thing to do is so obvious and you have an enthusiastic open-source community, you can just wait for the community to build it for you.
Go's generics case is a bit different, I think. I don't claim to be an expert here (I haven't followed Go development much) but as far as I understand it the omission of generics from Go was a deliberate ideological choice: they hoped to get by with the absolute minimum of generic functionality, and the experiment was how little they could get away with and still have it adopted. (Unfortunately, I think the experiments Go was trying to run were stymied by Google and Kubernetes throwing their weight behind it, which led to a pattern of adoption that had little to do with the language design itself: we may never know what would have become of it if it had been left to stand on its own.)
I think that arguably an (active) object à la Kay is itself a process — it doesn't have shared memory with the rest of the program (regardless of how that's achieved).
> Most rewrites answer to the engineer - what they want to learn, what offends their taste, what looks good in an interview - and not to the company paying the salary.
One big caveat to this is that a large (and increasing) part of the value of the senior engineering hire is their taste. ‘Taste’ as honed by the software industry approximates business needs that the business doesn't even know it has. Sometimes engineers struggle to articulate ‘why’ a particular change is beneficial because they're just pattern-matching: they've seen the existing pattern break in a dozen different ways in a dozen different codebases, so now when they see the same thing again it ‘offends their taste’ — it looks indefinably wrong even though it doesn't seem to be causing any direct harm right now.
(Of course, sometimes it turns out just to be that they don't understand what's going on, especially but not exclusively for more junior engineers. Pobody's nerfect.)
I think it definitely sits at a reasonable point in the tradeoff space here, but it's not the only reasonable point. And it's the nature of tradeoffs that some cases will slip through the cracks.
I think that's more of a workaround than a fix. Relying on unstructured concurrency does mean you no longer have to understand the scheduling of your program's fibres (… until you do), but it introduces a bunch of new footguns around things like correct cancellation, error propagation, and predicting resource lifetimes.
That's an excellent question I don't have an answer for in general :)
IMHO the goal is usually for the compiler not to make these decisions but to provide the tools for the APIs people build to make them. That's kind of passing the buck, though.
I guess in this case the core problem is that the API for these I/O calls has no representation in the type system for what's happening to the buffer. Proxying it as ‘the programmer must think about this code path’ is a reasonable best-effort but, evidently, sometimes inadequate.
`Poll` is marked `#[must_use]` so if you were assigning to something other than `_` you'd get a warning that you're ignoring the `Pending` path. The Clippy lint is only for `_` which Rust considers a use by default.
> I don’t use AI when I write, for the very reason that writing itself is the act of organizing and clarifying my own thought. Letting the bot write for me would be like paying someone else to exercise for me and hoping that gets me in shape.
I don't know why the author chooses to distinguish writing prose and writing code here. [Software is made of decisions](https://siderea.dreamwidth.org/1219758.html) and at least I usually like to flesh out those decisions through the act of writing code, which forces a level of precision that makes it hard (though not impossible) to handwave away important decisions.
Mathematics, and its empirical cousin science, are not about picking out individual things that are true in the universe. There is an infinite set of statements of things that are true about the universe, almost all of which are, necessarily, too complex (in a Kolmogorov sense) to be captured by a human mind, and each of which is so specific as to be largely useless. Once you have a statement, though, they're usually trivial to prove by observation.
Mathematics and science are both about building structure on large classes of facts about the (logical or physical, respectively) universe that allow us to generalize our knowledge and make predictions about facts we cannot yet observe. This also lets us make claims about things that are, individually, too complex for the human mind to grasp, by abstracting away the complex details into a simpler structure and then making the claim about anything that satisfies that structure.
To put it another way, mathematics is about finding beauty — specifically those things that exhibit structure that humans can grasp. Modern mathematics, for the most part, makes no claims about what lies outside that space: if it turns out that the universe consists only of things that humans can describe through mathematics that would be neat, but in the much more likely case that it doesn't mathematics continues as it is today.
It's an interesting and maybe even useful trivium if (according to some set of axioms, such as those implemented by your favourite proof assistant) a fact is true, but it's not (human) mathematics, and if there's no useful way for humans to generalize from it there's no point in including it in a library of mathematics. It wouldn't be that surprising (but would be very interesting!) if there were an entire parallel class (or, more likely, family of classes, one for each AI architecture) of AI mathematics comprising structures that AIs can usefully generalize from. Such a thing has no reason to bear any resemblance to human mathematics, which is based on mapping structures to innate human linguistic and spatial intuitions, and may not yield any insights to human mathematicians.
Green threads predate modern async/await by quite a long way. Since async/await was developed, recent languages tend to prefer the ‘principle of least surprise’ by making the yield points explicit, since they interact in important ways with the code around them, with the notable exception of Go (which is very weird considering how explicit they decided to make their error handling).
Regular reminder: the ‘lines of code’ metric is a liability not an asset. The best engineer is not the one who can produce the most lines of code in a day but the one who can ship the feature with the fewest lines (and prepare the system to receive the next feature with few lines, too).
> Language doesn’t matter anymore: Python, Go, Rust, Node. But system design hasn’t changed.
I keep seeing this claim, and it's incoherent. Programming languages are the languages we use to express system design, and just like Sapir–Whorf in natural languages they admit, emphasize, or force consideration of different concerns in the design process. If we did get to the point where those languages ‘don't matter any more’ it would just be because modern tooling allows us to express ourselves at a higher level than these languages were designed for — but then whatever higher-level language you're using to express yourself matters instead (and matters more than ever: the higher-level you go the more inaccuracies compound).
Programming languages are designed for humans, not for computers.
Sorry, misread you — but you can substitute ‘monopsony’ into my comment and I think it still holds.
This is a ‘no true Scotsman’ so I don't think I can really respond to it directly. But I'll point out that my claim is not that some contracts bargaining for safety of life and limb are a form of duress but that all inherently are (to some extent). Especially when the other party's BATNA is ‘no guarantee of safety’.
No human can _100%_ consent to anything (… probably: free will is tricky). Coercion is a continuum, not a binary.
I don't really think that companies (or other parties in trades) bear moral responsibility for this inherently — a company that accepted every job applicant to try to meet their inelastic demands wouldn't last long, so the company itself is also under some duress even if it might like to. Trying to assign blame for complex distributed problems isn't really that simple. Your example in particular is a trolley problem, and I (personally) don't believe that pulling the lever makes you more culpable than deliberately choosing not to pull the lever.
But regardless of your chosen ethics, my point is pragmatic — while it's not correct to say that people take jobs only because they are under duress, it's also not correct to base arguments on them acting on their own free will based on their personal preferences. UBI experiments show significant changes in employee behaviour when inelastic demands are guaranteed to be met and negotiations pertain only to elastic quantities.
I think that a programming language — much less a programming language _ecosystem_ — is such a large space of decisions that statistically you're inevitably going to let a few of them slip. And even (as in Rust's case, initially) if you don't aim to do anything new, the combination of the interactions between features and the ways people want to use your language culturally can land you places you never anticipated when doing the initial language design. I don't think anybody in the early years of Rust could have anticipated how async would look today, for example, and IIRC Graydon Hoare still doesn't like where it ended up.
Then, there's the old software adage that the right decision for one level of adoption doesn't necessarily translate to another level. Because it's so hard to predict the impact of early decisions, early versions of programming languages are basically prototypes: your aim is to get out enough of the core differentiators of the language that people can start playing with it and _imagining_ what it will be like to work with the final thing. Part of that involves making the barrier to entry as small as possible (e.g. bundling a full build system into the precompiled compiler executable) but it also implies that you don't want to spend more time than necessary on things that work the same as other languages. If you can see the ‘obvious omission’ in the language then that means you can already imagine how it will work when that thing is implemented! As an implementor you can always flesh it out as you approach 1.0, or, if the right thing to do is so obvious and you have an enthusiastic open-source community, you can just wait for the community to build it for you.
Go's generics case is a bit different, I think. I don't claim to be an expert here (I haven't followed Go development much) but as far as I understand it the omission of generics from Go was a deliberate ideological choice: they hoped to get by with the absolute minimum of generic functionality, and the experiment was how little they could get away with and still have it adopted. (Unfortunately, I think the experiments Go was trying to run were stymied by Google and Kubernetes throwing their weight behind it, which led to a pattern of adoption that had little to do with the language design itself: we may never know what would have become of it if it had been left to stand on its own.)