I had C++, python and ruby in mind, but yes, GP also mentioned Rust in the list of 'sprawling' languages, and they are probably right about that: Rust started as a 'better C replacement' but now it is trying to dominate every space for every programming language (and - in my opinion - not being very successful because niche languages exist for a reason, it is much easier to specialize than to generalize).

I wasn't particularly commenting on Rust's backward compatibility story so if you're not sure what I was arguing about then why did you feel the need to defend Rust from accusations that weren't made in the first place?

Tbh I think `rust-toolchain` solves most of these issues

No, you get C++ because you're Bjarne Stroustrup and trying to get people to sign on to the C++ bandwagon (A better C! Where have I heard that before?) and so you add every feature they ask for in the hope that that will drive adoption. And you call it object oriented (even if it really isn't) because that's the buzz-word du-jour. Just like Async today.

It's a balance thing. You can't make a language without any features, but you can be too small ('Brainfuck') and you can definitely be too large ('C++'). There is a happy medium in there somewhere and the lack of a string type was perceived as a major shortcoming of C, but then again, if you realize that they didn't even have structs in the predecessor to C (even though plenty of languages at the time did have similar constructs) they got enough of it right that it ended up taking off.

C and personal computing hit their stride at roughly the same time, your choices were (if you didn't feel like spending a fortune) Assembly, C, Pascal and BASIC for most systems that mere mortals could afford. BASIC was terribly slow, Pascal and C a good match and assembler only for those with absolutely iron discipline. Which one of the two won out (C or Pascal) was a toss up, Pascal had it's own quirks and it was mostly a matter of which of the two won out in terms of critical mass. Some people still swear by Pascal (and usually that makes them Delphi programmers, which will be around until the end because the code for the heat-death of the universe was writting in it).

For me it was Mark Williams C that clinched it, excellent documentation, good UNIX (and later Posix) compatibility and whatever I wrote on the ST could usually be easily ported to the PC. And once that critical mass took over there was really no looking back, it was C or bust. But mistakes were made, and we're paying the price for that in many ways. Ironically, C enabled the internet to come into existence and the internet then exposed mercilessly all of the inherent flaws in C.

Rust does. You have editions to do breaking changes at the surface level. But that is per crate (library) and you can mix and match crates with different editions freely.

Thry do reserve the right to do breaking changes for security fixes, soundness fixes and inference changes (i.e. you may need to add an explicit type that was previously inferred but is now ambiguous). These are quite rare and usually quite small.

Ada does. It has been through 5 editions so far and backwards compatibility is always maintained except for some small things that are documented and usually easy to update.

Go, PHP, Ruby, JavaScript ... I'd say majority, actually.

Java rules here. You can take any Java 1.0 (1995) codebase and compile it as-is on a recent JDK. Moreover, you can also use any ancient compiled Java library and link it to modern Java app. Java source and bytecode backward compatibility is fantastic.

I can take anything I wrote in C since ~1982 or so and throw it at a modern C compiler and it will probably work, I may have to set some flags but that's about it. I won't have to hunt up a compiler from that era, so the codebase remains unchanged, which increases the chances that I'm not going to introduce new bugs (though the old ones will likely remain).

If I try the same with a python project that I wrote less than five years ago I'm very, very lucky if I don't end up with a broken system by the time all of the conflicts are resolved. For a while we had Anaconda which solved all of the pain points but it too seems to suffer from dependency hell now.

George Orwell was a writer of English books, not a programmer and whatever he showed us he definitely did not show us that small programming languages constrain our thinking. That's just a very strange link to make, programming languages are not easily compared with the languages that humans use.

What you could say is that a programming languages' 'expressivity' is a major factor in how efficient it is in taking ideas and having them expressed in a particular language. If you take that to an extreme (APL) you end up with executable line-noise. If you take it to the other extreme you end up some of the worst of Java (widget factory factories). There are a lot of good choices to be found in the middle.

the explicit part is that zig forces you to import allocator of your choosing whereas odin has allocator passed as part of hidden context and you can change/access it only if you want to. hence explicit behavior vs implicit behavior.

i use neither of those languages, so don't ask me for technical details :D

> Typically no... which is another way of saying occasionally yes.

You might be able to avoid generating panic handling landing pads if you know that a function does not call panic (transitively). Inlining and LTO often help, but there is no guarantee that it will be possible to elide, it depends on the whims of the optimiser.

Knowing that panicking doesn't happen can also enable other optimisations that wouldn't have been correct if a panic were to happen.

All of that is usually very minor, but in a hot loop it could matter, and it will help with code size and density.

(Note that this is assuming SysV ABI as used by everyone except Windows, I have no clue how SEH exceptions on Windows work.)

> Indeed. You can mark a crate e.g. #![deny(clippy::panic)] and isolate that way, but it's not quite the rock solid guarantees Rust typically spoils us with.

Also, there are many things in Rust which can panic apart from actual calls to panic or unwrap: indexing out of bounds, integer overflow (in debug), various std functions if misused, ...

Right, but that reference is all the function has. It can’t destroy another scope’s reference to the foo, and the Python GC won’t destroy the foo as long as a reference to it exists.

The function could mutate foo to be empty, if foo is mutable, but it can’t make it not exist.