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

I’m honestly not convinced JavaScript is good even for the front-end, because it’s intentionally designed to swallow, ignore, and otherwise minimize errors; which is not helpful at all for development of any software. My point is that the only reason JavaScript is dominant in front-end development is that, prior to WASM, it was literally the only option; if that hadn’t been the case, I doubt it would have become nearly so widely used.

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++.

Sounds like we’re actually in agreement about most of this.

I’m okay with languages limiting their “expressive” power in order to provide stronger correctness guarantees or just limit how “weird” code looks; but this is largely because I’ve worked on many projects where someone had written a heap of difficult-to-understand code, and I doubt such limitations would be appealing if I were working strictly on my own.

I also don’t really see the appeal of Java-style inheritance, but to be honest I didn’t use Scala for long enough to know whether or not I agree that Scala does inheritance “right”.

It does make sense that Rust provides mutability in some cases where Scala doesn’t. Rust’s superpower, enabled by the borrow checker, is effectively “safe mutability.” I hope other, simpler languages build on this invention.

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.)

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/

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.

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.