I'm addressing the bit that I quoted, saying that an interpreted language "must" have valid semantics for all code. I'm not specifically addressing whether or not JavaScript is right in this particular case of min().

...but also, what are you talking about? Python throws a type error if you call min() with no argument.

None of the features discussed are aesthetic only.

I understand what you're saying, but I want to do whatever I can to promote the shift in attitudes that's already happening across the industry.

And being late or never delivering out of fear of shipping buggy code is even worse.

From a business perspective, yes, usually true. But shipping buggy software can also harm your company's reputation. I doubt that this has been researched enough yet to be quantifiable, but it's easy to think of companies who were well known for shipping bugs (Microsoft, CD Projekt Red) and eventually suffered in one way or another for it. In both of those cases, you're probably right; Windows was good enough in the 90s to dominate the desktop market, and Cyberpunk 2077 was enough of a technical marvel (for those who had the hardware to experience it) that it probably bolstered the studio's reputation more than harmed it. But could Microsoft have weathered the transition to mobile OSes better if it hadn't left so many consumers yearning for more reliable software? And is Microsoft not partly to blame for the general public just expecting computers to be generally flaky and unreliable?

Imagine if OSes in the 90s crashed as rarely as desktop OSes today. Imagine if desktop OSes today crashed as rarely as mobile OSes today. Imagine if mobile OSes crashed rarely enough that the average consumer never experienced it. Wouldn't that be a better state of things overall?

I'm no expert, but isn't running in a VM strictly better than running on raw metal from a security perspective? It's generally more locked down, and breaking out of the virtualization layer requires a separate security breach from gaining access to the running container.

Wat

Sorry, I'm not sure what your point is. I realize that you can almost completely avoid JavaScript, but the point I'm making is merely that there is a real technical limitation that limits the choices developers can make for front-end code, and although WASM is making great strides in breaking down that barrier (something I've been thrilled to see happen, but which is going much more slowly than I had hoped), the limitation is still there. Conversely, such a barrier has never existed on the backend, except in the sense that C limits what all other languages can do.

This is a really good post about why C is so difficult to seriously consider replacing, or even to avoid by using a different language for certain projects: https://faultlore.com/blah/c-isnt-a-language/

In both cases, Go and Python, the operator will assign a variable a value and also use it as an expression.

That is absolutely not true. foo := <expr> is a statement in Go, full stop. Just try something trivial like assigning to the output of :=: https://go.dev/play/p/nPINGc7LO8B

It's true that if and for let you use := but don't let you use var, but you still can't use the result of the assignment directly. So for instance you need if foo := <expr>; foo { ... } rather than just if foo := <expr> { ... }.

I was curious about the Python connection because multiple comments mentioned it, but I've worked on multiple Python projects over the past dozen-ish years and never seen that operator.

Turns out it was introduced in 3.8, released in 2019, so it was much too late to inspire Go, and most of the projects I've worked on were written to target an earlier Python version. It also has a substantially different meaning than in Go.

I don't know if there's an "official" rationale for the Go syntax, but := is a fairly common (but not ubiquitous) math notation meaning "define the thing on the left to be equal to the expression on the right", i.e. to distinguish it from the other use of =, i.e. "the expression on the left must be equal to the expression on the right." Go's usage matches this mathematical meaning of introducing a new variable definition pretty well.

I read it a few hours ago. Was it substantially longer before?

If you have a Linux or Mac handy, you can trying it out! It's...kinda wild. If you know some Vim commands that start with :, there's a good chance they'll work in ed, except you don't type : itself (effectively you're always in "command mode").

There's also a novelty Twitter account, @ed1conf, that tweets about ed.

Some coworkers told me a story about a previous job candidate who said his preferred editor was ed. They thought it would be really interesting to see someone actually use it. But during the actual interview, when he opened ed, he didn't recognize or understand it; he was actually accustomed to a graphical editor that he thought was called ed because he apparently did all his work on a system where someone had symlinked or aliased ed to a modern tool.

You are making an extreme assumption, and it also sounds like you've misread what I wrote. The "attempts" I'm talking about are studies (formal and informal) to measure the root causes of bugs, not the C or C++ projects themselves.

I cited one specific measurement, Daniel Stenberg's analysis of the Curl codebase. Here's a separate post about the testing and static analysis used for Curl.

Here's a post with a list of other studies. The projects analyzed are:

• Android (both the full codebase and the Bluetooth & media components)
• iOS & MacOS
• Chrome
• Microsoft (this is probably the most commonly cited one)
• Firefox
• Ubuntu Linux

Do you really think that Google, Apple, Microsoft, Mozilla, and the Ubuntu project "don't even consider onboarding basic static analysis tools" in their C and C++ projects?

If you're curious about the specifics of how errors slip through anyway, here's a talk from CppCon 2017 about how Facebook, despite copious investment into static analysis, still had "curiously recurring" C++ errors. It's long, but I think it's worthwhile; the most interesting part to me, though, starts around 29:40, where he asks an audience of C++ users whether some specific code compiles, and only about 10% of them get the right answer, one of whom is an editor of the C++ standard.