10 ms·

I can't agree more with this. I am a long time c++ dev, been to c++ committee meetings. The language is too complicated and inconsistent, and that is now I beli

I can't agree more with this. I am a long time c++ dev, been to c++ committee meetings. The language is too complicated and inconsistent, and that is now I believe unfixable. I believe no one understands it. New features keep arriving, but you still have to learn everything that came before, for older codebases. For example, {} style initalisers were added to simplify and "unify" things. Except to make a vector of length 3 you still need to use the old style (3) notation. So now there is just one more thing to learn. It is much easier to add "one more thing" to a language than it is to later take it out.

aaaaaaaaaab 8y ago
Let’s revisit this when Rust has... - the number of users - the amount of mission-critical legacy code that has to compile - the number of compiler vendors - age ... comparable to C++’s.
- paulddraper 8y ago
  > ... comparable to C++’s. When? 2018? 1990?
  - pjmlp 8y ago
    In the 1990's we already had a couple of OS vendors shipping C++ compilers on their OS SDKs (Apple, IBM, Microsoft, Be, Symbian). So far that is only true of Redox.
    - noir_lord 8y ago
      To be fair though 1990's C++ written in the recommended way is almost a completely different language to 2018 C++. The change isn't as marked as say perl5 and perl6 but it is still huge. I've no dog in either fight though, I moved to managed languages a long time ago (Object Pascal was the last compiled language I used in anger).
      - pjmlp 8y ago
        True, but many of the "modern C++" stuff like RAII, type safe strings, arrays, collections were already possible in C++ compilers for MS-DOS for example, it was a matter of actually using them. Not sure which managed languages you mean, those that I use also provide the option to compile to native code just like Object Pascal, if I wish to do so.
      - deleted 8y ago
        [deleted]
    - steveklabnik 8y ago
      And Fuchsia.
      - pjmlp 8y ago
        Fuchsia is still largely written in C++, with a couple of modules like the TCP/IP stack, written in Go, and Dart for the UI layer. To what extent is Rust being adopted by the Fuchsia team?
        steveklabnik 8y ago
        There’s a few hundred thousand lines of Rust in Fuchsia. (Garnet’s repo claims 12% Rust as of today.) They’ve been hiring Rust programmers aggressively to add more. They’ve been helping drive the design and implementation of async/await, since they’re big users. Rust is one of the four or five languages that they maintain a sort-of-libc for and use it as an example for writing applications for the OS. (It’s a microkernel, so it’s not really a libc so much as it is their IPC layer, which is how you make the equivalent of syscalls in other languages. “FIDL”)
        pjmlp 8y ago
        I see, so is that an indication that Zircon might eventually migrate to Rust?
        steveklabnik 8y ago
        I don’t think there’s any plans to move Zircon. It’s also less pressing, IMHO, since it is a microkernel. Maybe someday, but if I were in charge, it wouldn’t be super high in my list.
      - lostmsu 8y ago
        There's an official Rust support in SDK? There's an official SDK?
        steveklabnik 8y ago
- taneq 8y ago
  I'm not sure that's an important comparison. They're not saying that there's no good reason for the current state of C++, or that they can't understand why it's like that. They're just saying that it'd be nice if Rust didn't disintegrate into the same morass of new syntax, primitives, idioms and pitfalls that C++ has become.
- reificator 8y ago
  Let's also come back to it when Rust is older than C++. It's a new language targeted toward people who want stability and performance, what do you expect to see by now?
  - steveklabnik 8y ago
    Rust will never be older than C++ since they both get one year older every year ;)
    - deleted 8y ago
      [deleted]
    - StavrosK 8y ago
      Oh age is just an int, and it'll overflow at some point.
    - _ek94 8y ago
      Interpreting GP's comment using the Principle of Charity[1], I assume GP meant "older than C++ is now". [1]: https://en.wikipedia.org/wiki/Principle_of_charity https://en.wikipedia.org/wiki/Principle_of_charity
      - reificator 8y ago
        Or making a joke, which is supposedly verboten here.
- firethief 8y ago
  So, when it's too late?
- skywhopper 8y ago
  No, the point is to get ahead of C++'s situation so as not to repeat its mistakes. You can't do that if you wait until it's too late.
- paulsutter 8y ago
  According to that we should all be using COBOL Did you hear they’re finally making it object oriented? The name will be ADD ONE TO COBOL
  - pjmlp 8y ago
    Cobol is already OOP for several years now.
    - adwn 8y ago
      > Cobol is already OOP for several years now. I think that was supposed to be a joke, mocking Cobol's verboseness (compare "C++", which adds 1 to C and which extends C with OOP).
blattimwind 8y ago
I've been dabbling in some Rust lately and as a long time mostly-C++-and-Python-and-some-Java dev I've found it relatively easy to get started with it. Sure, a lot of things are different (e.g. struct+impl vs. classes), many clearly better, some that may/may not be better just different, but overall it seems to me like Rust is relatively easy to pick up coming from C++. And C++ is usually way uglier and far more complicated. I'm currently reviewing a bunch of code using bleeding edge language features and it is extremely difficult to understand what the code is supposed to do and what it might be doing. The age of multi-vendored languages like C or C++ for systems programming might be coming to an end. I'd wager this is actually a good thing.
- pjmlp 8y ago
  History has proven that system programming language winners come with an OS/platform to cimment their advantage over others. So I don't agree that the age of "The age of multi-vendored languages like C or C++ for systems programming might be coming to an end.", unless you mean we will managed to get rid of all OSes written in them, specially UNIX flavours or GPGPU libraries. It would be nice, but it won't happen until the next big hardware revolution like Quantic computers being developed in Q# for example.
- the_duke 8y ago
  I was drawn to Rust because, behind the apparent complexity of the borrow checker, the language is/was actually very simple and easy to understand. I have been using Rust extensively for over 2 years. In those two years, the language complexity has increased substantially. It's already at a stage where I'm worried about losing track. Also, there is quite a large amount of changes in the pipeline that were already accepted but are either not finished or not implemented yet. All of those can/will have a significant impact on idiomatic code and API design and will increase the complexity burden: * specialization * generic associated types (a simple form of higher kinded types) * async/await + generators * existential types * const generics ... So I do believe Rust needs to slow down considerably and get much stricter with accepting new features. Both to not overwhelm the existing userbase and to not make the language another C++ in terms of complexity.
zanny 8y ago
I don't feel like C was ever meant to be the permanent foundation on which all other computing was built. It was a language for its time. It took assemblies of the 70s made them much more palatable with an imperative syntax. C++ was also not meant to be a permanent foundation. It took shortcomings in C for scale and hacked on top functionality Bjarne wanted. The complexity difference between a computer 46 years ago, almost half a century, when C was first developed and now is incomprehensible. It is reflected in how these languages, fundamentally, are willing to just say "since the computer only runs in 30 cycles a second and we are just doing increment operations if you break the rules it undefined" and the idea of having behavior native to the grammar that would impose kilobytes of size complexity or megacycles of computation would have been absurd. At the time, of course. Modern C++ doesn't hesitate to generate multiple vtables for a complex class while juggling reference counting smart pointers with streamlined initialization grammars that can take up thousands of words of memory. But because the primitives that must remain stable for backwards compatiblity were built on the most constrained architectures the whole house of cards is thus constrained. I think Rust has already made a lot of "just get it out there, don't think about the ramifications" decisions in its language design, especially around its grammar. On one hand there is still logic to what glyphs do what and how control flow is laid out - particularly concerning minimizing the number of retraced parses the source needs to go through - but it doesn't change the syntax of lifetimes ('), the use of double colon namespacing (::), or the turbofish but being an unintitive disgusting hack. In my experience the RFC process though has helped temper that. All those blemishes are predominantly from the origin of the language up through ~2014. Once the ecosystem developed and decisions required months or years of hanging around on the issue tracker to see stabilization Rust mostly stopped grafting on arcane behavior and started reusing its syntax in intuitive ways (like impl trait). I don't think any of the current crop of outstanding wants really makes the language more complex. A lot of it is just increasing the compliers complexity to handle more generic code, be it in terms of kindedness or by type delegation or inference. Those kinds of complexities aren't generally something for users to explicitly learn in rote memorization to use the language - if Rust introduced overloading and default arguments all those who don't know it exists won't have the language made any harder to use, but those that want it can take advantage of it. As long as Rust is never tempted into the "a substantial portion of this behavior is undefined if not done explicitly as intended" hole that C and C++ were predestined to fall upon I don't think features make the language harder. The core syntax is there, shouldn't change, and is being made easier and more intuitive, not harder and more complex (NLLs save the day, and the number of explicit lifetimes needed have been culled dramatically in the last two years of development). In just a few glyphs of C++: void* = 0 - there are already all manner of edge case, undefined behavior, syntactic complexity beyound comprehension. Nobody working on Rust today wants arcane, impossible to process grammar or undefined behavior complexity. The language already mostly lacks it. Nobody in their right mind will add it. Thats never a feature, its the bug Rust fixes that is inherent to the C lineage in ways nothing but a rewrite can fix. It took a decade of pain for Python to change its string type from bytes to unicode - there is absolutely no way to salvage C or any of its descendants. By design. From its fundamentals. All the complexity on top has just been repeated attempts to temper the fundamental incongruities.
izacus 8y ago
No offense, but that's been the tune we've been constantly hearing for years now. Always the "next big thing" killing off C++ or Java or something with its superiority. And yet, somehow, when choosing a very efficient language that has 1st party support, we always end up with pretty much one widely supported answer: the horror that is C++. Why do you think that Rust will be a different story this time?
- paulddraper 8y ago
  Nothing will "kill off" C++. Nothing -- not even C++ -- "killed off" C. But it's share of total usage can and will decrease. Java certainly took a massive chunk of the "programming market" that would have otherwise been C++. And then later JavaScript. Of course, software usage in general has been going up and up, so in absolute terms C++ has been increasing as well.
  - pjmlp 8y ago
    C++ has a hard fight against C on embedded platforms where we still have devs using C89 + Assembly, and on classical UNIX flavours. It certainly looks much different in other platforms and modern OSes.
- gameswithgo 8y ago
  Most of us aren't concerned with whether anything would kill off C++. That certainly won't happen any time soon, given the inertia. But some of us would like to be able to use a language that lets you do low level, high performing goodness, without having to use C++. So it is nice that there are some more viable options now.
cageface 8y ago
Maybe it makes sense to read the success of Golang as a smart piece of social engineering. Start with a simple and accessible language and gradually ratchet up the complexity to deal with more real-world problems. You may eventually wind up with a worse language but at least you'll have users. Rust tried to solve a lot of hard problems out of the gate and that has slowed its growth IMO. It's sort of another worse-is-better dichotomy.
- shmerl 8y ago
  That social engineering strategy only helps in the short term (short on the language scale, which can still be many years). If you get a convoluted language in result, in the long term it will increasingly irritate programmers, who will anyway start looking for objectively better alternatives. So Rust took the right approach IMHO.
  - cageface 8y ago
    What tends to happen is that you bring out a simplified, cleaned-up version of the popular language of the day. People then flock to that new language and start making feature requests. Over time that language becomes as complex and inelegant as the language it replaced and you can start the whole cycle all over again. The move from C++ -> Java -> Go is a perfect example of this cycle.
    - e3b0c 8y ago
      C is a language designed to enable more efficient communication between the computer and the programmer in mind. C++ is a language designed to enable more communication between the compiler and the programmer. Go is a language designed to enable more efficient communication between programmers.
      - pjmlp 8y ago
        C was a language designed by two developers without background in language design that got lucky, because Bell Labs wasn't allowed to sell UNIX thus it ended up licensing it for a symbolic price to universities. C was hardly efficient in the 80s micro-computers, and outside Bell Labs people were doing compiler optimization research in languages like PL.8 and similar. Had Bell Labs been allowed to sell UNIX and history would certainly looked much different.
pantalaimon 8y ago
I feel like C is having a renaissance because of that. C is very conservative in adding new features, which makes it easy to get an understanding of the language - nothing is hidden, when necessary you can derive everything you need to know about a piece of code from first principles. C compared to C++ feels like high school math compared to university math with all it's scary notations.
- kerkeslager 8y ago
  It's not just the notations, either. I'm not a particularly strong C programmer (I don't write it professionally, I write Python) but I've read documentation for the entire C standard library[1], for example. [1] https://en.wikipedia.org/wiki/C_standard_library https://en.wikipedia.org/wiki/C_standard_library
- Ar-Curunir 8y ago
  I don't think this is true: what C leaves out in terms of language features , programmers have to reinvent or keep in their heads perpetually while writing code, leading to tons of gotchas.
  - Too 8y ago
    Yep, to reuse the math analogy. C is like solving 3d geometric problems by manually aggregating endless lines of cos, sin and sqrt, instead of using vector mathematics where you can do the same with just a single line of matrix multiplication or a simple dot-product.
  - lifthrasiir 8y ago
    In the other words, C standard library is not really small. It consists of a small mechanized portion and a much larger portion embedded in wetware, i.e. human mind. The second portion is very hard to update or fix, so the first portion keeps growing to cover all faults of the second.
    - pjmlp 8y ago
      And POSIX plays the role of an additional runtime library.

aaaaaaaaaab 8y ago

Let’s revisit this when Rust has... - the number of users - the amount of mission-critical legacy code that has to compile - the number of compiler vendors - age ... comparable to C++’s.

paulddraper 8y ago
> ... comparable to C++’s. When? 2018? 1990?
- pjmlp 8y ago
  In the 1990's we already had a couple of OS vendors shipping C++ compilers on their OS SDKs (Apple, IBM, Microsoft, Be, Symbian). So far that is only true of Redox.
  - noir_lord 8y ago
    To be fair though 1990's C++ written in the recommended way is almost a completely different language to 2018 C++. The change isn't as marked as say perl5 and perl6 but it is still huge. I've no dog in either fight though, I moved to managed languages a long time ago (Object Pascal was the last compiled language I used in anger).
    - pjmlp 8y ago
      True, but many of the "modern C++" stuff like RAII, type safe strings, arrays, collections were already possible in C++ compilers for MS-DOS for example, it was a matter of actually using them. Not sure which managed languages you mean, those that I use also provide the option to compile to native code just like Object Pascal, if I wish to do so.
    - deleted 8y ago
      [deleted]
  - steveklabnik 8y ago
    And Fuchsia.
    - pjmlp 8y ago
      Fuchsia is still largely written in C++, with a couple of modules like the TCP/IP stack, written in Go, and Dart for the UI layer. To what extent is Rust being adopted by the Fuchsia team?
      - steveklabnik 8y ago
        There’s a few hundred thousand lines of Rust in Fuchsia. (Garnet’s repo claims 12% Rust as of today.) They’ve been hiring Rust programmers aggressively to add more. They’ve been helping drive the design and implementation of async/await, since they’re big users. Rust is one of the four or five languages that they maintain a sort-of-libc for and use it as an example for writing applications for the OS. (It’s a microkernel, so it’s not really a libc so much as it is their IPC layer, which is how you make the equivalent of syscalls in other languages. “FIDL”)
        pjmlp 8y ago
        I see, so is that an indication that Zircon might eventually migrate to Rust?
        steveklabnik 8y ago
        I don’t think there’s any plans to move Zircon. It’s also less pressing, IMHO, since it is a microkernel. Maybe someday, but if I were in charge, it wouldn’t be super high in my list.
    - lostmsu 8y ago
      There's an official Rust support in SDK? There's an official SDK?
      - steveklabnik 8y ago
taneq 8y ago
I'm not sure that's an important comparison. They're not saying that there's no good reason for the current state of C++, or that they can't understand why it's like that. They're just saying that it'd be nice if Rust didn't disintegrate into the same morass of new syntax, primitives, idioms and pitfalls that C++ has become.
reificator 8y ago
Let's also come back to it when Rust is older than C++. It's a new language targeted toward people who want stability and performance, what do you expect to see by now?
- steveklabnik 8y ago
  Rust will never be older than C++ since they both get one year older every year ;)
  - deleted 8y ago
    [deleted]
  - StavrosK 8y ago
    Oh age is just an int, and it'll overflow at some point.
  - _ek94 8y ago
    Interpreting GP's comment using the Principle of Charity[1], I assume GP meant "older than C++ is now". [1]: https://en.wikipedia.org/wiki/Principle_of_charity https://en.wikipedia.org/wiki/Principle_of_charity
    - reificator 8y ago
      Or making a joke, which is supposedly verboten here.
firethief 8y ago
So, when it's too late?
skywhopper 8y ago
No, the point is to get ahead of C++'s situation so as not to repeat its mistakes. You can't do that if you wait until it's too late.
paulsutter 8y ago
According to that we should all be using COBOL Did you hear they’re finally making it object oriented? The name will be ADD ONE TO COBOL
- pjmlp 8y ago
  Cobol is already OOP for several years now.
  - adwn 8y ago
    > Cobol is already OOP for several years now. I think that was supposed to be a joke, mocking Cobol's verboseness (compare "C++", which adds 1 to C and which extends C with OOP).

blattimwind 8y ago

I've been dabbling in some Rust lately and as a long time mostly-C++-and-Python-and-some-Java dev I've found it relatively easy to get started with it. Sure, a lot of things are different (e.g. struct+impl vs. classes), many clearly better, some that may/may not be better just different, but overall it seems to me like Rust is relatively easy to pick up coming from C++. And C++ is usually way uglier and far more complicated. I'm currently reviewing a bunch of code using bleeding edge language features and it is extremely difficult to understand what the code is supposed to do and what it might be doing. The age of multi-vendored languages like C or C++ for systems programming might be coming to an end. I'd wager this is actually a good thing.

pjmlp 8y ago
History has proven that system programming language winners come with an OS/platform to cimment their advantage over others. So I don't agree that the age of "The age of multi-vendored languages like C or C++ for systems programming might be coming to an end.", unless you mean we will managed to get rid of all OSes written in them, specially UNIX flavours or GPGPU libraries. It would be nice, but it won't happen until the next big hardware revolution like Quantic computers being developed in Q# for example.
the_duke 8y ago
I was drawn to Rust because, behind the apparent complexity of the borrow checker, the language is/was actually very simple and easy to understand. I have been using Rust extensively for over 2 years. In those two years, the language complexity has increased substantially. It's already at a stage where I'm worried about losing track. Also, there is quite a large amount of changes in the pipeline that were already accepted but are either not finished or not implemented yet. All of those can/will have a significant impact on idiomatic code and API design and will increase the complexity burden: * specialization * generic associated types (a simple form of higher kinded types) * async/await + generators * existential types * const generics ... So I do believe Rust needs to slow down considerably and get much stricter with accepting new features. Both to not overwhelm the existing userbase and to not make the language another C++ in terms of complexity.

zanny 8y ago

I don't feel like C was ever meant to be the permanent foundation on which all other computing was built. It was a language for its time. It took assemblies of the 70s made them much more palatable with an imperative syntax. C++ was also not meant to be a permanent foundation. It took shortcomings in C for scale and hacked on top functionality Bjarne wanted. The complexity difference between a computer 46 years ago, almost half a century, when C was first developed and now is incomprehensible. It is reflected in how these languages, fundamentally, are willing to just say "since the computer only runs in 30 cycles a second and we are just doing increment operations if you break the rules it undefined" and the idea of having behavior native to the grammar that would impose kilobytes of size complexity or megacycles of computation would have been absurd. At the time, of course. Modern C++ doesn't hesitate to generate multiple vtables for a complex class while juggling reference counting smart pointers with streamlined initialization grammars that can take up thousands of words of memory. But because the primitives that must remain stable for backwards compatiblity were built on the most constrained architectures the whole house of cards is thus constrained. I think Rust has already made a lot of "just get it out there, don't think about the ramifications" decisions in its language design, especially around its grammar. On one hand there is still logic to what glyphs do what and how control flow is laid out - particularly concerning minimizing the number of retraced parses the source needs to go through - but it doesn't change the syntax of lifetimes ('), the use of double colon namespacing (::), or the turbofish but being an unintitive disgusting hack. In my experience the RFC process though has helped temper that. All those blemishes are predominantly from the origin of the language up through ~2014. Once the ecosystem developed and decisions required months or years of hanging around on the issue tracker to see stabilization Rust mostly stopped grafting on arcane behavior and started reusing its syntax in intuitive ways (like impl trait). I don't think any of the current crop of outstanding wants really makes the language more complex. A lot of it is just increasing the compliers complexity to handle more generic code, be it in terms of kindedness or by type delegation or inference. Those kinds of complexities aren't generally something for users to explicitly learn in rote memorization to use the language - if Rust introduced overloading and default arguments all those who don't know it exists won't have the language made any harder to use, but those that want it can take advantage of it. As long as Rust is never tempted into the "a substantial portion of this behavior is undefined if not done explicitly as intended" hole that C and C++ were predestined to fall upon I don't think features make the language harder. The core syntax is there, shouldn't change, and is being made easier and more intuitive, not harder and more complex (NLLs save the day, and the number of explicit lifetimes needed have been culled dramatically in the last two years of development). In just a few glyphs of C++: void* = 0 - there are already all manner of edge case, undefined behavior, syntactic complexity beyound comprehension. Nobody working on Rust today wants arcane, impossible to process grammar or undefined behavior complexity. The language already mostly lacks it. Nobody in their right mind will add it. Thats never a feature, its the bug Rust fixes that is inherent to the C lineage in ways nothing but a rewrite can fix. It took a decade of pain for Python to change its string type from bytes to unicode - there is absolutely no way to salvage C or any of its descendants. By design. From its fundamentals. All the complexity on top has just been repeated attempts to temper the fundamental incongruities.

izacus 8y ago

No offense, but that's been the tune we've been constantly hearing for years now. Always the "next big thing" killing off C++ or Java or something with its superiority. And yet, somehow, when choosing a very efficient language that has 1st party support, we always end up with pretty much one widely supported answer: the horror that is C++. Why do you think that Rust will be a different story this time?

paulddraper 8y ago
Nothing will "kill off" C++. Nothing -- not even C++ -- "killed off" C. But it's share of total usage can and will decrease. Java certainly took a massive chunk of the "programming market" that would have otherwise been C++. And then later JavaScript. Of course, software usage in general has been going up and up, so in absolute terms C++ has been increasing as well.
- pjmlp 8y ago
  C++ has a hard fight against C on embedded platforms where we still have devs using C89 + Assembly, and on classical UNIX flavours. It certainly looks much different in other platforms and modern OSes.
gameswithgo 8y ago
Most of us aren't concerned with whether anything would kill off C++. That certainly won't happen any time soon, given the inertia. But some of us would like to be able to use a language that lets you do low level, high performing goodness, without having to use C++. So it is nice that there are some more viable options now.

cageface 8y ago

Maybe it makes sense to read the success of Golang as a smart piece of social engineering. Start with a simple and accessible language and gradually ratchet up the complexity to deal with more real-world problems. You may eventually wind up with a worse language but at least you'll have users. Rust tried to solve a lot of hard problems out of the gate and that has slowed its growth IMO. It's sort of another worse-is-better dichotomy.

shmerl 8y ago
That social engineering strategy only helps in the short term (short on the language scale, which can still be many years). If you get a convoluted language in result, in the long term it will increasingly irritate programmers, who will anyway start looking for objectively better alternatives. So Rust took the right approach IMHO.
- cageface 8y ago
  What tends to happen is that you bring out a simplified, cleaned-up version of the popular language of the day. People then flock to that new language and start making feature requests. Over time that language becomes as complex and inelegant as the language it replaced and you can start the whole cycle all over again. The move from C++ -> Java -> Go is a perfect example of this cycle.
  - e3b0c 8y ago
    C is a language designed to enable more efficient communication between the computer and the programmer in mind. C++ is a language designed to enable more communication between the compiler and the programmer. Go is a language designed to enable more efficient communication between programmers.
    - pjmlp 8y ago
      C was a language designed by two developers without background in language design that got lucky, because Bell Labs wasn't allowed to sell UNIX thus it ended up licensing it for a symbolic price to universities. C was hardly efficient in the 80s micro-computers, and outside Bell Labs people were doing compiler optimization research in languages like PL.8 and similar. Had Bell Labs been allowed to sell UNIX and history would certainly looked much different.

pantalaimon 8y ago

I feel like C is having a renaissance because of that. C is very conservative in adding new features, which makes it easy to get an understanding of the language - nothing is hidden, when necessary you can derive everything you need to know about a piece of code from first principles. C compared to C++ feels like high school math compared to university math with all it's scary notations.

kerkeslager 8y ago
It's not just the notations, either. I'm not a particularly strong C programmer (I don't write it professionally, I write Python) but I've read documentation for the entire C standard library[1], for example. [1] https://en.wikipedia.org/wiki/C_standard_library https://en.wikipedia.org/wiki/C_standard_library
Ar-Curunir 8y ago
I don't think this is true: what C leaves out in terms of language features , programmers have to reinvent or keep in their heads perpetually while writing code, leading to tons of gotchas.
- Too 8y ago
  Yep, to reuse the math analogy. C is like solving 3d geometric problems by manually aggregating endless lines of cos, sin and sqrt, instead of using vector mathematics where you can do the same with just a single line of matrix multiplication or a simple dot-product.
- lifthrasiir 8y ago
  In the other words, C standard library is not really small. It consists of a small mechanized portion and a much larger portion embedded in wetware, i.e. human mind. The second portion is very hard to update or fix, so the first portion keeps growing to cover all faults of the second.
  - pjmlp 8y ago
    And POSIX plays the role of an additional runtime library.