4 ms·

> There's a recurring theme where people think the C language's design is good for systems programming, even today. These people think that someone sat down, th

> There's a recurring theme where people think the C language's design is good for systems programming, even today. These people think that someone sat down, thought of every tradeoff, and made the best ones for system programming. Or, people think that a good practical language can only come from using it to solve real problems and iterating on the design. Sitting down and conjuring up the perfect language just does not work. Now, I am the first to agree that C has plenty of flaws. For one, the integer types are just a mess. I will be happy if something can replace it, but so far most attempts have ended up either too slow or too complicated.

davegauer 10y ago
What is your opinion of Rust? Does it fall under the category of "too complicated"? Or is it simply far too young to be proven yet?
- TorKlingberg 10y ago
  I'm curious about Rust but haven't tried it enough yet to form an opinion.
  - dman 10y ago
    Intend to spend this years Christmas holidays catching up on Rust.
- alfalfasprout 10y ago
  Rust is extremely interesting, but here's the thing: at this point it's going to be hard to dethrone a language like C++. Far too many excellent libraries exist for C++ and even recent but slightly more mature languages like Go will need at least a decade to catch up. Sure, you could write bindings but it's never going to be quite the same.
  - nickpsecurity 10y ago
    This is probably true. It also applies to Java, C#, PHP, COBOL, x86, and ARM. Although, it might be noted that various things on that list dethroned others in certain segments. Still doesn't matter. You don't have to dethrone anything. Just build an advantageous ecosystem with a good chance of short-term and long-term commercial support. Do that right, there will be uptake that can slowly build into something competitive. We've seen it happen numerous times with Mathworks (MATLAB), Borland (Delphi/Pascal), Eiffel (Eiffel), Microsoft (C#), Sun (Java), Google (Go), Mozilla (Rust), and Apple (Swift). Really useful and superior tech can also attract people into closer-knit, small, and high-quality communities as we see with Haskell. So, I tell people not to worry if vast majority will use your stuff. Just worry if a good chunk of them will find it useful enough to pick up and extend. Then you might make it. Note: A cheat I've already mentioned is making your language or whatever integrate with a popular one and its libraries. Clojure, in an anti-LISP world, is proof of how unusually effective that can be. The typical example is how most C alternatives can compile to C or use its libraries.
  - fulafel 10y ago
    If you look at big C++ apps like Firefox or AAA games, most of the third party libraries are used through C apis. Even commercial libraries written in C++ often have C based APIs because of historical binary compatibility problems in C++ linking. Is safely wrapping a C api in C++ significantly easier than wrapping it in Rust?
kabdib 10y ago
An example of convergent evolution - Apple was primarily a Pascal shop back in the early 80s, when they were developing the Lisa. But since bog-standard Pascal is useless for systems programming, Apple extended it with things they needed: Pointer arithmetic (not auto-scaling by base type, so you were constantly multiplying by sizeof), oh yeah, sizeof, and a bunch of other stuff I've forgotten. Pascal's miserable I/O system was left on the floor. NEW was largely replaced by a heap manager that worked for small systems. And so on. So what Apple wound up with was "C, with nested procedures". The two languages were nearly identical in semantics. I could spend a day hacking on something, and if you asked me in the evening which language I'd been using I would have had to think about it. The types of bugs that people wrote didn't seem to vary depending on the language they chose. My informal survey is that other companies extended their versions of Pascal, making similar choices. These companies (Apollo? a few others) have sunk without a trace. Languages that look a lot like C are what you get from systems level people doing near-bare-metal programming. You're not going to fix the language, you need to convince the people doing the work that you have something better. And for the most part, something better doesn't exist. You can write low-level systems in higher-level languages; Microsoft's Midori was an OS from the metal-up in C#, with a lot of interesting deep thinking about abstractions and security. SmallTalk / SELF / FORTH are interesting until you need to scale. LISP Machines didn't take the world by storm in the 80s, and we didn't get very interesting fallout from all the LISP-based OS work that was being done. ADA . . . I know one guy who loves ADA, but he can't tell me what he works on. Successful languages seem to be the result of commercially successful systems, not the other way around.
- microcolonel 10y ago
  This is exactly what I think of when I read this kind of unilateral negativity about C. I love writing programs in C. I don't need to learn any new semantics ever. Even the integer types, as parent was complaining about, have been largely cleaned up(I use (u)int(32,64)_t and (s)size_t and everything just works. The problem space is well understood, the tools are widely-deployed and reliable, the performance is excellent. I just don't see how people can be so negative about something which has been so immensely useful without getting in the way.
nickpsecurity 10y ago
"Or, people think that a good practical language can only come from using it to solve real problems and iterating on the design. Sitting down and conjuring up the perfect language just does not work." I agree. It's why that's a false dilemma I'm not promoting. I illustrated a C alternative that iterated out a language and OS better than C/UNIX in a number of metrics. We'd provably have fewer problems like crashes or hacks had we been stuck with that language. Static analysis would've been easier as well given its successor had the first, standard library that was mathematically verified to avoid specific problems. https://news.ycombinator.com/item?id=12316092 https://news.ycombinator.com/item?id=12316092

davegauer 10y ago

What is your opinion of Rust? Does it fall under the category of "too complicated"? Or is it simply far too young to be proven yet?

TorKlingberg 10y ago
I'm curious about Rust but haven't tried it enough yet to form an opinion.
- dman 10y ago
  Intend to spend this years Christmas holidays catching up on Rust.
alfalfasprout 10y ago
Rust is extremely interesting, but here's the thing: at this point it's going to be hard to dethrone a language like C++. Far too many excellent libraries exist for C++ and even recent but slightly more mature languages like Go will need at least a decade to catch up. Sure, you could write bindings but it's never going to be quite the same.
- nickpsecurity 10y ago
  This is probably true. It also applies to Java, C#, PHP, COBOL, x86, and ARM. Although, it might be noted that various things on that list dethroned others in certain segments. Still doesn't matter. You don't have to dethrone anything. Just build an advantageous ecosystem with a good chance of short-term and long-term commercial support. Do that right, there will be uptake that can slowly build into something competitive. We've seen it happen numerous times with Mathworks (MATLAB), Borland (Delphi/Pascal), Eiffel (Eiffel), Microsoft (C#), Sun (Java), Google (Go), Mozilla (Rust), and Apple (Swift). Really useful and superior tech can also attract people into closer-knit, small, and high-quality communities as we see with Haskell. So, I tell people not to worry if vast majority will use your stuff. Just worry if a good chunk of them will find it useful enough to pick up and extend. Then you might make it. Note: A cheat I've already mentioned is making your language or whatever integrate with a popular one and its libraries. Clojure, in an anti-LISP world, is proof of how unusually effective that can be. The typical example is how most C alternatives can compile to C or use its libraries.
- fulafel 10y ago
  If you look at big C++ apps like Firefox or AAA games, most of the third party libraries are used through C apis. Even commercial libraries written in C++ often have C based APIs because of historical binary compatibility problems in C++ linking. Is safely wrapping a C api in C++ significantly easier than wrapping it in Rust?

kabdib 10y ago

An example of convergent evolution - Apple was primarily a Pascal shop back in the early 80s, when they were developing the Lisa. But since bog-standard Pascal is useless for systems programming, Apple extended it with things they needed: Pointer arithmetic (not auto-scaling by base type, so you were constantly multiplying by sizeof), oh yeah, sizeof, and a bunch of other stuff I've forgotten. Pascal's miserable I/O system was left on the floor. NEW was largely replaced by a heap manager that worked for small systems. And so on. So what Apple wound up with was "C, with nested procedures". The two languages were nearly identical in semantics. I could spend a day hacking on something, and if you asked me in the evening which language I'd been using I would have had to think about it. The types of bugs that people wrote didn't seem to vary depending on the language they chose. My informal survey is that other companies extended their versions of Pascal, making similar choices. These companies (Apollo? a few others) have sunk without a trace. Languages that look a lot like C are what you get from systems level people doing near-bare-metal programming. You're not going to fix the language, you need to convince the people doing the work that you have something better. And for the most part, something better doesn't exist. You can write low-level systems in higher-level languages; Microsoft's Midori was an OS from the metal-up in C#, with a lot of interesting deep thinking about abstractions and security. SmallTalk / SELF / FORTH are interesting until you need to scale. LISP Machines didn't take the world by storm in the 80s, and we didn't get very interesting fallout from all the LISP-based OS work that was being done. ADA . . . I know one guy who loves ADA, but he can't tell me what he works on. Successful languages seem to be the result of commercially successful systems, not the other way around.

microcolonel 10y ago
This is exactly what I think of when I read this kind of unilateral negativity about C. I love writing programs in C. I don't need to learn any new semantics ever. Even the integer types, as parent was complaining about, have been largely cleaned up(I use (u)int(32,64)_t and (s)size_t and everything just works. The problem space is well understood, the tools are widely-deployed and reliable, the performance is excellent. I just don't see how people can be so negative about something which has been so immensely useful without getting in the way.

nickpsecurity 10y ago

"Or, people think that a good practical language can only come from using it to solve real problems and iterating on the design. Sitting down and conjuring up the perfect language just does not work." I agree. It's why that's a false dilemma I'm not promoting. I illustrated a C alternative that iterated out a language and OS better than C/UNIX in a number of metrics. We'd provably have fewer problems like crashes or hacks had we been stuck with that language. Static analysis would've been easier as well given its successor had the first, standard library that was mathematically verified to avoid specific problems. https://news.ycombinator.com/item?id=12316092 https://news.ycombinator.com/item?id=12316092