Indeed, I had no idea there are multiple languages referred to as “APL”.

I feel like most people defending C++ resort to “people shouldn’t use those features that way”. 😅

As far as I can tell, pointer arithmetic was not originally part of PASCAL; it’s just included as an extension in many implementations, but not all. Delphi, the most common modern dialect, only has optional pointer arithmetic, and only in certain regions of the code, kind of like unsafe in Rust. There are also optional bounds checks in many (possibly most) dialects. And in any case, there are other ways in which C is unsafe.

True, but AFAIK they all sucked really bad.

That’s pure assumption and, as far as I can tell, not actually true. PASCAL was a strong contender. No language was competitive with handwritten assembly for several decades after C’s invention, and there’s no fundamental reason why PASCAL couldn’t benefit from intense compiler optimizations just as C has.

Here are some papers from before C “won”, a more recent article about how PASCAL “lost”, and a forum thread about what using PASCAL was actually like. None of them indicate a strong performance advantage for C.

• https://link.springer.com/content/pdf/10.1007/3-540-09745-7_3.pdf
• https://dl.acm.org/doi/pdf/10.1145/356869.356872
• https://www.deusinmachina.net/p/pascal-the-language-that-almost-took
• https://news.ycombinator.com/item?id=10202666

C++11 also introduced new problems, such as the strange interaction between brace-initialization and initializer-lists (though that was partially fixed several years later), and the fairly arcane rules around move semantics with minimal compiler support (for example, it would be great if the standard required compilers to emit an error if a moved-from object were accessed).

I know Lisp is minimal, I’m just saying that I expect there are Lisp fans who won’t acknowledge (or would excuse) any shortcomings in the language, just as there are C++ fans who do the same for C++.

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.

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.

Ehhh, I mean this more strongly. I’ve never met people more in denial about language design problems than C++ adherents. (Though admittedly I haven’t spent much time talking to Lisp fans about language design.)

I see where you’re coming from, but no matter how many null pointer exceptions there are in Java code, you’re almost always protected from actually wrecking your system in an unrecoverable way; usually the program will just crash, and even provide a relatively helpful error message. The JVM is effectively a safety net, albeit an imperfect one. Whereas in C++, the closest thing you have to a safety net, i.e. something to guarantee that invalid memory usage crashes your program rather than corrupting its own or another process’s memory, is segfaults, which are merely a nicety provided by common hardware, not required by the language or provided by the compiler. Even then, with modern compiler implementations, undefined behavior can cause an effectively unlimited amount of “bad stuff” even on hardware that supports segfaults.

Additionally, most languages with managed runtimes that existed when Java was introduced didn’t actually have a static type system. In particular, Perl was very popular, and its type system is…uh…well, let’s just say it gives JavaScript some serious competition.

That said, despite this grain of truth in the statement, I think the perception that Java is comparatively robust is primarily due to Java’s intense marketing (particularly in its early years), which strongly pushed the idea that Java is an “enterprise” language, whatever that means.

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

I mean, if you’re talking about CVEs permitting attackers to get control of the hardware of lots of systems, then yes, I agree

There were memory-safe languages long before C was invented, though; C was widely considered “dangerous” even at the time.

WASM has no native ability to access most web APIs, including the DOM. JavaScript is literally unavoidable on the front end.

Genuine question: if you’re writing a new CLI utility, why not Rust? This is arguably where Rust has most excelled, most famously with ripgrep.

Oh, trust me, Qt is still primarily C++. It’s effectively a massive set of C++ libraries.

I mean to be fair, that’s a pretty useful tool.

Oof, slow compile times to target, of all things, the JVM? Implicit methods? Some(null)? Function call syntax where the difference between a tuple argument and a sequence of non-tuple arguments can be determined by whether or not there’s a space before the parentheses?

There are definitely some major issues with Scala.

I was a professional C++ developer for several years, and came to the conclusion that any professional C++ developers who don’t acknowledge its flaws have a form of Stockholm Syndrome.

Well, except “robust”, unless you have very strict code standards, review processes, and static analysis.

(And arguably it’s never elegant, though that’s almost purely a matter of taste.)

How does the const { None } example type-inference work? The size of the option type can’t be known without knowing the type of the Somevariant.

Edit: aha, it doesn’t work as-is. It needs to infer the type of elements of foo from usage. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=05a95c592626b6935ae812527aa6bbc6

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.