The post doesn't say "imperative", it just differentiates between defining pipeline steps and defining the logic within a step.

...also, TCL? I haven't used it for ops, but my memory of tcl/tk is extremely negative.

...also also: a core part of a build, CI, or, CD pipeline is almost always invoking binaries to run a command. That's why shell scripts are so ubiquitous in pipeline-logic: invoking binaries is what they're for. And it's very difficult to do that a declarative way: Make comes close, but it's difficult to track any side-effects that aren't "update these files", and a huge amount of CI/CD is no longer just "update a file".

No, because the thing they are naming is "The Github Dictionary"; they're not applying scare-quotes to the word "dictionary" implying that what they've written is not really a "dictionary".

If you mean the box at the top, with "Larger Text", "Default", and "More Space", mouse-over shows a resolution spec. Is it actually just scaling "as if" the screen had the given resolution?

Even so, I can understand how a Mac user would be confused by this and expect the equivalent feature in a different OS to be called "resolution".

They did consider making environment-manipulation functions atomic; the problem is that there's simply no way to guarantee that everything that can manipulate your process's environment is actually beholden to whatever atomic interface Rust provides. I could be misremembering, but I think there was even some discussion with glibc maintainers about whether this could be made safe, and the answer was basically "haha no."

I don't really like the title either, but the article does demonstrate how unfortunate it is that we're effectively locked in to using the ABI at some level of nearly every piece of software.

That said, there definitely were languages with better type systems prior to the invention of C. Pascal is a frequently-cited example.

Go is a "small" language in the sense that it has an exceptionally small number of concepts (i.e. features and syntactic constructs); someone else in this thread made a comment to the effect that it takes almost no time to learn because there's nothing to learn if you've already learned a different language. This is of course an exaggeration, but only slightly: Go was very intentionally and explicitly designed to be as simple as possible to learn and to use. As an example, it famously had no support for generics until almost 10 years after its 1.0 release. I think that when talking about the size of a language, some people do include the standard library while others don't; Go has quite a large standard library, but you don't actually have to learn the whole library or even be aware of what's available in order to be productive.

I personally don't think it makes sense to include the standard library in the "size" of a language for the purpose of this thread, or Boats' original blog posts. The fundamental point is about the learning curve of the language and the amount of work it takes to produce working code, and a large standard library tends to be more convenient, not less. Common functionality that isn't in Rust's standard library tends to come from libraries that become almost ubiquitous, such as serde, regex, crossbeam, and itertools. From the user's perspective, this isn't much more or less complicated than having the same functionality available via the standard library. (Of course, a large standard library certainly makes languages more difficult to implement and/or specify; if I recall correctly, about half the size of the C++ standard is dedicated to the standard library.)

I don't really know how to fairly compare the "size" of Rust and C++, partly because Rust is so much younger, and several C++ "features" overlap with each other or are attempts to replace others (e.g. brace-initialization as a replacement for parentheses). But I don't think I've ever heard someone claim that C++ is "small" or "minimal" in this sense, so it's in no way a good point of comparison for determining whether Rust is "small".

Edit to add: for what it's worth, if I weren't quoting Boats' blog post (which is sort of the "canonical" post on this concept), I probably would have opted for "simpler (to learn & use)" rather than "smaller."

Not necessarily interpreted, but possibly. I think a more likely path is something like Go that's compiled but still has a garbage collector.

I'm trying to think of examples of this, and I actually don't know that this is true. Here are the examples I can think of:

• Arguably object-oriented .method() syntax is similar to "subject-verb" order, but we also have function(self, ...) which is the reverse of that.
• for foo in bar is used in a few languages (or sometimes foreach). But many languages use a totally non-English construct, such as for i = 0; i < limit; i++ or for (auto foo : bar).

What else is there?

I discovered a fun one the other day: there is literally no way to represent word-boundary anchors that's valid in both GNU sed and BSD sed. https://unix.stackexchange.com/a/393968/38050

You seem to be ignoring the benefits of compiler support as mentioned in the comment above.

And the only reasonably successful way we've found so far for doing so is...money.