6 ms·

I feel like other languages also have the issue of complexity and changing over time. I doubt I know all of C++ post C++14 for example (even though that is my d

I feel like other languages also have the issue of complexity and changing over time. I doubt I know all of C++ post C++14 for example (even though that is my day job). Keeping up with all the things they throw into the standard library of Python is also near impossible unless you write python every day. Rust has an unusually short release cycle, but each release tends to have fewer things in it. So that is probably about the same when it comes to new features per year in Python or C++. But sure, C moves slower (and is smaller to begin with). If that is what you want to compare against. But all the languages I work with on a daily basis (C++, Python and Rust) are sprawling. I don't have enough experience to speak about other languages in depth, but as I understand it Haskell for example has a lot of extensions. And the typescript/node ecosystem seems to move crazy fast and require a ton of different moving pieces to get anything done (especially when it comes to the build system with bundlers, minifiers and what not).

jacquesm 10mo ago
Languages should be small, not large. I find that every language I've ever used that tries to throw everything and the kitchensink at you eventually deteriorates into a mess that spills over into the projects based on that language in terms of long term instability. You should be able to take a 10 year old codebase, compile it and run it. Backwards compatibility is an absolute non-negotiable for programming languages and if you disagree with that you are building toys, not production grade systems.
- aw1621107 10mo ago
  > Backwards compatibility is an absolute non-negotiable for programming languages What programming language(s) satisfy this criteria, if any?
  - GhosT078 10mo ago
    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.
    - aw1621107 10mo ago
      I'd normally be inclined to agree that minor things are probably good enough, but "absolute non-negotiable" is a rather strong wording and i think small things technically violate a facial reading, at least. On the other hand, I did find what I think are the relevant docs [0] while looking more into things, so I got to learn something! [0]: https://docs.adacore.com/gnat_rm-docs/html/gnat_rm/gnat_rm/compatibility_and_porting_guide.html https://docs.adacore.com/gnat_rm-docs/html/gnat_rm/gnat_rm/c...
    - cogman10 10mo ago
      > except for some small things that are documented I can't think of any established language that doesn't fit that exact criteria. The last major language breakage I'm aware of was either the .Net 2 to 3 or Python 2 to 3 changes (not sure which came first). Otherwise, pretty much every language that makes a break will make it in a small fashion that's well documented.
  - gethly 10mo ago
    Go, PHP, Ruby, JavaScript ... I'd say majority, actually.
    - aw1621107 10mo ago
      It's probably borderline due to the opt-in mechanism, but Go did make a technically backwards-incompatible change to how its for loops work in 1.22 [0]. PHP has had breaking changes [1]. Ruby has had breaking changes [2] (at the very least under "Compatibility issues") Not entirely sure whether this counts, but ECMAScript has had breaking changes [3]. [0]: https://go.dev/blog/loopvar-preview https://go.dev/blog/loopvar-preview [1]: https://www.php.net/manual/en/migration80.incompatible.php https://www.php.net/manual/en/migration80.incompatible.php [2]: https://www.ruby-lang.org/en/news/2025/12/25/ruby-4-0-0-released/ https://www.ruby-lang.org/en/news/2025/12/25/ruby-4-0-0-rele... [3]: https://tc39.es/ecma262/2025/#sec-additions-and-changes-that-introduce-incompatibilities-with-prior-editions https://tc39.es/ecma262/2025/#sec-additions-and-changes-that...
      - gethly 10mo ago
        There is no such thing as perfection in the real world. Close enough is good enough.
        aw1621107 10mo ago
        I'd normally agree with you in practice, but since "close enough" seems likely to cover most mainstream languages in use today I figured "absolute non-negotiable" probably was intended to mean a stricter standard.
      - kbolino 10mo ago
        The interesting thing about Go's loopvar change is that nobody was able to demonstrate any real-world code that it broke (*1), while several examples were found of real-world code (often tests) that it fixed (*2). Nevertheless, they gated it behind go.mod specifying a go version >= 1.22, which I personally think is overly conservative. *1: A great many examples of synthetic code were contrived to argue against the change, but none of them ever corresponded to Go code anyone would actually write organically, and an extensive period of investigation turned up nothing *2: As in, the original behavior of the code was actually incorrect, but this wasn't discovered until after the loopvar change caused e.g. some tests to fail, prompting manual review of the relevant code; as a tangent, this raises the question of how often tests just conform to the code rather than the other way around
  - speed_spread 10mo ago
    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.
    - aw1621107 10mo ago
      Java has had some breaking changes (e.g., [0, 1]), though in practice I have to say my experience tends to agree and I've been fortunate enough to never run into issues. [0]: https://stackoverflow.com/q/1654923 https://stackoverflow.com/q/1654923 [1]: https://news.ycombinator.com/item?id=28542853 https://news.ycombinator.com/item?id=28542853
    - cogman10 10mo ago
      * Terms and conditions apply Java is very good here, but (and not totally it's fault) it did expose internal APIs to the userbase which have caused a decent amount of heartburn. If your old codebase has a route to `sun.misc.unsafe` then you'll have more of a headache making an upgrade. Anyone that's been around for a while and dealt with the 8->9 transition has been bit here. 11->17 wasn't without a few hiccups. 17->21 and 21->25 have been uneventful.
      - your_fin 10mo ago
        Can confirm; my team spent the past 9 months upgrading an application JDK 8 -> 17, and there were breaking changes even after we got it compiling + running
  - VorpalWay 10mo ago
    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.
    - aw1621107 10mo ago
      I'd normally agree that what you say is good enough in practice, but I question whether it meets GP's "absolute non-negotiable" standards. That specific wording is the reason I asked the question in the first place; it seemed to me that there was some standard that apparently wasn't being met and I was wondering where exactly the bar was.
    - loluuw 10mo ago
      [flagged]
- kreetx 10mo ago
  Haskell's user-facing language gets compiled down to Haskell "core" which is what the language actually can do. So any new language feature has a check in with sanity when that first transformation gets written.
- kibwen 10mo ago
  I'm not sure what this is arguing against here. Anyone who follows Rust knows that it's relatively modest when it comes to adding new features; most of the "features" that get added to Rust are either new stdlib APIs or just streamlining existing features so that they're less restrictive/easier to use. And Rust has a fantastic backwards compatibility story.
  - jacquesm 10mo ago
    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?
  - alfiedotwtf 10mo ago
    Tbh I think `rust-toolchain` solves most of these issues
- armchairhacker 10mo ago
  I suspect the problem is that every feature makes it possible for an entire class of algorithms to be implement much more efficiently and/or clearly with a small extension to the language. Many people encounter these algorithms after many other people have written large libraries and codebases. It’s much easier to slightly extend the language than start over or (if possible) implement the algorithm in an ugly way that uses existing features. But enough extensions (and glue to handle when they overlap) and even a language which was initially designed to be simple, is no longer. e.g., Go used to be much simpler. But in particular, lack of generics kept coming up as a pain point in many projects. Now Go has generics, but arguably isn’t simple anymore.
- kstrauser 10mo ago
  Egad, no. This is how you get C++, whose core tenet seems to be “someone used this once in 1994 so we can never change it”. Even adding a new keyword will break some code out there that used that as a variable name or something. Perfect backward compatibility means you can never improve anything, ever, lest it causes someone a nonzero amount of porting effort.
  - jacquesm 10mo ago
    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.
    - kstrauser 10mo ago
      I’ll accept that, too. But from the outside it seems like they do that by finding bizarre, previously invalid syntax and making that the way to spell the new feature. `foo[]#>££{23}` to say “use implicit parallelism on big endian machines with non-power-of-2 word sizes”? Let’s do it!
- Someone 10mo ago
  If you want or have to build a large program, something must be large, be it the language, its standard library, third party code, or code you write. I think it’s best if it is one of the first two, as that makes it easier to add third party code to your code, and will require less effort to bring newcomers up to speed w.r.t. the code. As an example, take strings. C doesn’t really have them as a basic type, so third party libraries all invent their own, requiring those using them to add glue code. That’s why standard libraries and, to a lesser extent, languages, tend to grow. Ideally that’s with backwards compatibility, but there’s a tension between moving fast and not making mistakes, so sometimes, errors are made, and APIs ‘have’ to be deprecated or removed.
  - jacquesm 10mo ago
    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.
- rayiner 10mo ago
  > Languages should be small, not large. Yes. At the very least, features should carry a lot of weight and be orthogonal to other features. When I was young I used to pride myself on knowing all the ins and outs of modern C++, but over time I realized that needing to be a “language lawyer” was a design shortcoming. All that being said I’ve never seen the functionality of Rust’s borrow checker reduced to a simpler set of orthogonal features and it’s not clear that’s even possible.
- alfiedotwtf 10mo ago
  George Orwell showed us that small languages constrain our thinking. A small language but with the ability to extend it (like Lisp) is probably the sweet spot, but lol look at what you have actually achieved - your own dialect that you have to reinvent for each project - also which other people have had to reinvent time after time. Let languages and thought be large, but only used what is needed.
  - jacquesm 10mo ago
    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.
    - alfiedotwtf 10mo ago
      > 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 You mean: > small languages constrain our thinking. :)
pjmlp 10mo ago
Even C, we are now at C23, and I bet most folks only know "my compiler C", and not even all the extensions it offers.
- esafak 10mo ago
  That's why it's important to get it right early in the language. The new stuff may as well not exist.

jacquesm 10mo ago

Languages should be small, not large. I find that every language I've ever used that tries to throw everything and the kitchensink at you eventually deteriorates into a mess that spills over into the projects based on that language in terms of long term instability. You should be able to take a 10 year old codebase, compile it and run it. Backwards compatibility is an absolute non-negotiable for programming languages and if you disagree with that you are building toys, not production grade systems.

aw1621107 10mo ago
> Backwards compatibility is an absolute non-negotiable for programming languages What programming language(s) satisfy this criteria, if any?
- GhosT078 10mo ago
  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.
  - aw1621107 10mo ago
    I'd normally be inclined to agree that minor things are probably good enough, but "absolute non-negotiable" is a rather strong wording and i think small things technically violate a facial reading, at least. On the other hand, I did find what I think are the relevant docs [0] while looking more into things, so I got to learn something! [0]: https://docs.adacore.com/gnat_rm-docs/html/gnat_rm/gnat_rm/compatibility_and_porting_guide.html https://docs.adacore.com/gnat_rm-docs/html/gnat_rm/gnat_rm/c...
  - cogman10 10mo ago
    > except for some small things that are documented I can't think of any established language that doesn't fit that exact criteria. The last major language breakage I'm aware of was either the .Net 2 to 3 or Python 2 to 3 changes (not sure which came first). Otherwise, pretty much every language that makes a break will make it in a small fashion that's well documented.
- gethly 10mo ago
  Go, PHP, Ruby, JavaScript ... I'd say majority, actually.
  - aw1621107 10mo ago
    It's probably borderline due to the opt-in mechanism, but Go did make a technically backwards-incompatible change to how its for loops work in 1.22 [0]. PHP has had breaking changes [1]. Ruby has had breaking changes [2] (at the very least under "Compatibility issues") Not entirely sure whether this counts, but ECMAScript has had breaking changes [3]. [0]: https://go.dev/blog/loopvar-preview https://go.dev/blog/loopvar-preview [1]: https://www.php.net/manual/en/migration80.incompatible.php https://www.php.net/manual/en/migration80.incompatible.php [2]: https://www.ruby-lang.org/en/news/2025/12/25/ruby-4-0-0-released/ https://www.ruby-lang.org/en/news/2025/12/25/ruby-4-0-0-rele... [3]: https://tc39.es/ecma262/2025/#sec-additions-and-changes-that-introduce-incompatibilities-with-prior-editions https://tc39.es/ecma262/2025/#sec-additions-and-changes-that...
    - gethly 10mo ago
      There is no such thing as perfection in the real world. Close enough is good enough.
      - aw1621107 10mo ago
        I'd normally agree with you in practice, but since "close enough" seems likely to cover most mainstream languages in use today I figured "absolute non-negotiable" probably was intended to mean a stricter standard.
    - kbolino 10mo ago
      The interesting thing about Go's loopvar change is that nobody was able to demonstrate any real-world code that it broke (*1), while several examples were found of real-world code (often tests) that it fixed (*2). Nevertheless, they gated it behind go.mod specifying a go version >= 1.22, which I personally think is overly conservative. *1: A great many examples of synthetic code were contrived to argue against the change, but none of them ever corresponded to Go code anyone would actually write organically, and an extensive period of investigation turned up nothing *2: As in, the original behavior of the code was actually incorrect, but this wasn't discovered until after the loopvar change caused e.g. some tests to fail, prompting manual review of the relevant code; as a tangent, this raises the question of how often tests just conform to the code rather than the other way around
- speed_spread 10mo ago
  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.
  - aw1621107 10mo ago
    Java has had some breaking changes (e.g., [0, 1]), though in practice I have to say my experience tends to agree and I've been fortunate enough to never run into issues. [0]: https://stackoverflow.com/q/1654923 https://stackoverflow.com/q/1654923 [1]: https://news.ycombinator.com/item?id=28542853 https://news.ycombinator.com/item?id=28542853
  - cogman10 10mo ago
    * Terms and conditions apply Java is very good here, but (and not totally it's fault) it did expose internal APIs to the userbase which have caused a decent amount of heartburn. If your old codebase has a route to `sun.misc.unsafe` then you'll have more of a headache making an upgrade. Anyone that's been around for a while and dealt with the 8->9 transition has been bit here. 11->17 wasn't without a few hiccups. 17->21 and 21->25 have been uneventful.
    - your_fin 10mo ago
      Can confirm; my team spent the past 9 months upgrading an application JDK 8 -> 17, and there were breaking changes even after we got it compiling + running
- VorpalWay 10mo ago
  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.
  - aw1621107 10mo ago
    I'd normally agree that what you say is good enough in practice, but I question whether it meets GP's "absolute non-negotiable" standards. That specific wording is the reason I asked the question in the first place; it seemed to me that there was some standard that apparently wasn't being met and I was wondering where exactly the bar was.
  - loluuw 10mo ago
    [flagged]
kreetx 10mo ago
Haskell's user-facing language gets compiled down to Haskell "core" which is what the language actually can do. So any new language feature has a check in with sanity when that first transformation gets written.
kibwen 10mo ago
I'm not sure what this is arguing against here. Anyone who follows Rust knows that it's relatively modest when it comes to adding new features; most of the "features" that get added to Rust are either new stdlib APIs or just streamlining existing features so that they're less restrictive/easier to use. And Rust has a fantastic backwards compatibility story.
- jacquesm 10mo ago
  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?
- alfiedotwtf 10mo ago
  Tbh I think `rust-toolchain` solves most of these issues
armchairhacker 10mo ago
I suspect the problem is that every feature makes it possible for an entire class of algorithms to be implement much more efficiently and/or clearly with a small extension to the language. Many people encounter these algorithms after many other people have written large libraries and codebases. It’s much easier to slightly extend the language than start over or (if possible) implement the algorithm in an ugly way that uses existing features. But enough extensions (and glue to handle when they overlap) and even a language which was initially designed to be simple, is no longer. e.g., Go used to be much simpler. But in particular, lack of generics kept coming up as a pain point in many projects. Now Go has generics, but arguably isn’t simple anymore.
kstrauser 10mo ago
Egad, no. This is how you get C++, whose core tenet seems to be “someone used this once in 1994 so we can never change it”. Even adding a new keyword will break some code out there that used that as a variable name or something. Perfect backward compatibility means you can never improve anything, ever, lest it causes someone a nonzero amount of porting effort.
- jacquesm 10mo ago
  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.
  - kstrauser 10mo ago
    I’ll accept that, too. But from the outside it seems like they do that by finding bizarre, previously invalid syntax and making that the way to spell the new feature. `foo[]#>££{23}` to say “use implicit parallelism on big endian machines with non-power-of-2 word sizes”? Let’s do it!
Someone 10mo ago
If you want or have to build a large program, something must be large, be it the language, its standard library, third party code, or code you write. I think it’s best if it is one of the first two, as that makes it easier to add third party code to your code, and will require less effort to bring newcomers up to speed w.r.t. the code. As an example, take strings. C doesn’t really have them as a basic type, so third party libraries all invent their own, requiring those using them to add glue code. That’s why standard libraries and, to a lesser extent, languages, tend to grow. Ideally that’s with backwards compatibility, but there’s a tension between moving fast and not making mistakes, so sometimes, errors are made, and APIs ‘have’ to be deprecated or removed.
- jacquesm 10mo ago
  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.
rayiner 10mo ago
> Languages should be small, not large. Yes. At the very least, features should carry a lot of weight and be orthogonal to other features. When I was young I used to pride myself on knowing all the ins and outs of modern C++, but over time I realized that needing to be a “language lawyer” was a design shortcoming. All that being said I’ve never seen the functionality of Rust’s borrow checker reduced to a simpler set of orthogonal features and it’s not clear that’s even possible.
alfiedotwtf 10mo ago
George Orwell showed us that small languages constrain our thinking. A small language but with the ability to extend it (like Lisp) is probably the sweet spot, but lol look at what you have actually achieved - your own dialect that you have to reinvent for each project - also which other people have had to reinvent time after time. Let languages and thought be large, but only used what is needed.
- jacquesm 10mo ago
  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.
  - alfiedotwtf 10mo ago
    > 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 You mean: > small languages constrain our thinking. :)

pjmlp 10mo ago

Even C, we are now at C23, and I bet most folks only know "my compiler C", and not even all the extensions it offers.

esafak 10mo ago
That's why it's important to get it right early in the language. The new stuff may as well not exist.