25 ms·

Not only is curl based on C, but so are operating systems, IP stacks and network software, drivers, databases, Unix userland tools, web servers, mail servers, p

Not only is curl based on C, but so are operating systems, IP stacks and network software, drivers, databases, Unix userland tools, web servers, mail servers, parts of web browsers and other network clients, language runtimes and libs of higher-level languages, compilers and almost all other infrastructure software we use daily. I know there's a sentiment here on HN against C (as evidenced by bitter comments whenever a new project dares to choose C) but I wish there'd be a more constructive approach, acknowledging the issue isn't so much new software but the large collection of existing (mostly F/OSS) software not going to be rewritten in eg. Rust or some (lets face it) esoteric/niche FP language. Even for new projects, the choice of programming language isn't clear at all if you value integration and maintainability aspects.

erelde 10y ago
I am student and I like C, I've tested Rust/Go, I like the feeling of C. Maybe that sentiment will change later, but for now, I like C. It's simple and sharp and there's lots of doc/books.
- floatboth 10y ago
  Have you tried doing string manipulation in C? ;)
  - boduh 10y ago
    +1
  - erelde 10y ago
    You can see two of my current school assignement on Github. I try to avoid manipulating strings as much as possible. ;)
  - asveikau 10y ago
    Not OP, but I actually think string manipulation in C is really elegant. Many people who complain about it have too many allocations in their code and are trying to port the allocation-heavy non-C way of thinking to C. The C way I know focuses mainly on character at a time iteration with emphasis on not copying the source string. I'm reminded of a time a colleague needed something like string.split, and working in c++ he filled a std::vector<std::string> with the result. Using a more C way he'd really only have needed a couple of pointers on the stack.
    - imron 10y ago
      > The C way I know focuses mainly on character at a time iteration Ah, yes, the good 'ole C way that only works reliably in English.
      - dbaupp 10y ago
        It's a little naïve to think it works on English without the coöperation of the users. (Also, less glibly, things like emoji seem to be becoming more and more popular.)
        imron 10y ago
        Indeed. In fact as we speak I am fixing a bug related to string handling with emojis.
      - asveikau 10y ago
        Funny. You can parse utf-8 character at a time. Some characters advance the pointer by 4 at an iteration and some less.
        dbaupp 10y ago
        What do you mean by "character"? If you mean code point or "unicode scalar value", sure, but if you mean user-visible character (grapheme), it's much more complicated: even something "simple" like ö could be one or two code points.
        asveikau 10y ago
        I mean your iterator is char* and you advance it by adding. That's it. I do NOT mean that char itself corresponds to a glyph or codepoint, you are seriously preaching to the choir making that lecture to me.
        fauigerzigerk 10y ago
        >you advance it by adding And when do you stop? UTF-8 strings can have zero bytes in them so treating them as C strings is potentially error prone depending on the context.
- IshKebab 10y ago
  C seems relatively simple, but it's also incredibly easy to do the wrong thing usually without realising it. That's the problem. I suggest you read up about 'undefined behaviour'.
- stevedonovan 10y ago
  'sharp' would be a good word ;) There's lots to like about it but writing good safe C is harder than it looks.
pjmlp 10y ago
Historical accident, I started to work back in the days when UNIX was the only OS implemented in C. Everything else outside UNIX was using Assembly, Algol, PL/I, Modula or Pascal dialect. C owes its success to UNIX's adoption by the market, as operating system available almost free of charge to universities, with source code available.
- davexunit 10y ago
  C was originally a watered down version of BCPL because the computers they were targeting had very limited capabilities compared to other computers of the time. The first version of C didn't even have floating point numbers.
  - pjmlp 10y ago
    Meanwhile in 1961 we had ESPOL, followed by NEWP, nowadays living on the Unisys MCP ClearPath mainframes.
wyldfire 10y ago
> I know there's a sentiment here on HN against C I think there's two major against-C groups: those of us who have worked with C for decades and those who never worked with it. I'll try and speak for those of us who've used it for decades. The popular high-level languages that have arrived since ~1995 (Java, Python, JS, C# and friends) are excellent productivity increases. In general, they sacrifice memory and performance in favor of robustness and security. For enormous software problem domains, we just don't need C's complexity or error-proneness. Until Rust, there's been very close to zero serious competitors for C if I wanted to write a bootloader, OS, or ISR. Not even C++ could do those (without being extremely creative on how it's built/used). The ~post-2000 languages (golang, swift, D etc) can't do that (perhaps D's an exception but it wasn't an initial goal AFAICT). This is huge, IMO. We've groaned and grumbled about how hard it is to parse C/C++ code for decades. This is a big deal for tooling. Because of the language's design, even if you use something "simple" like libclang to parse your code, you still have to reproduce the entire build context just to sanely make an AST. All of those other new languages above probably address this problem but also add all kinds of other stuff which we can't have for specialized problem domains (realtime/low-latency requirements, OSs, etc). > collection of ... software not going to be rewritten in eg. Rust or some (lets face it) esoteric/niche FP language IMO it's not appropriate to lump Rust in with "nice FP language"s. And don't look now but lots of stuff is being rewritten in Rust. Fundamental this-is-the-OS-at-its-root stuff: coreutils [1], "libc" [2], kernels [3], browser engines [4]. [1] https://github.com/uutils/coreutils https://github.com/uutils/coreutils [2] https://github.com/japaric/steed https://github.com/japaric/steed [3] https://github.com/redox-os https://github.com/redox-os [4] https://github.com/servo/servo https://github.com/servo/servo
- tannhaeuser 10y ago
  > IMO it's not appropriate to lump Rust in with "nice FP language"s. Maybe I should have expressed it better, but I didn't intend to lump these together. >And don't look now but lots of stuff is being rewritten in Rust. I'm myself cautiously optimistic re Rust, but having been burnt by C++ in the past I'm not enthusiastic about fighting language idiosyncrasies (though modern C++ certainly deserves a second look). Then there's the issue (some might argue it's a plus) that Rust is at the same time a language, a lib, and the only compiler implementation (unlike C or C++ which give you choice).
fiedzia 10y ago
> the large collection of existing (mostly F/OSS) software not going to be rewritten in eg. Rust or some It is happening and will keep happening and it is really necessary at some point. Sure, I don't expect large project to be rewritten overnight, but every large project is being redone eventually. Especially when C becomes main source of problems. And you can introduce better languages gradually. > operating systems, drivers https://github.com/redox-os/redox https://github.com/redox-os/redox > IP stacks https://github.com/QuiltOS/QuiltNet https://github.com/QuiltOS/QuiltNet Many of those are often written in userspace, where you are free to use any language. Several of them will provide sufficient performance. > databases, Unix userland tools, web servers, mail servers, parts of web browsers and other network clients, language runtimes and libs of higher-level languages, compilers and almost all other infrastructure software we use daily. For all of those you'll find Rust implementations. Some are work in progress, some are already widely used.
vbezhenar 10y ago
A lot of mentioned software was started many years ago, when other languages were hardly viable options. And those programs are good enough now, so there's no much movement to replace them. It's not a good argument for C, IMO. It's like telling that Windows is awesome because so many users use it. But when people started from scratch (mobile world), it turned out, that Windows is not the best OS. Actually when I'm reading about new software, it's very rare to encounter C. Usually it's something else.

erelde 10y ago

I am student and I like C, I've tested Rust/Go, I like the feeling of C. Maybe that sentiment will change later, but for now, I like C. It's simple and sharp and there's lots of doc/books.

floatboth 10y ago
Have you tried doing string manipulation in C? ;)
- boduh 10y ago
  +1
- erelde 10y ago
  You can see two of my current school assignement on Github. I try to avoid manipulating strings as much as possible. ;)
- asveikau 10y ago
  Not OP, but I actually think string manipulation in C is really elegant. Many people who complain about it have too many allocations in their code and are trying to port the allocation-heavy non-C way of thinking to C. The C way I know focuses mainly on character at a time iteration with emphasis on not copying the source string. I'm reminded of a time a colleague needed something like string.split, and working in c++ he filled a std::vector<std::string> with the result. Using a more C way he'd really only have needed a couple of pointers on the stack.
  - imron 10y ago
    > The C way I know focuses mainly on character at a time iteration Ah, yes, the good 'ole C way that only works reliably in English.
    - dbaupp 10y ago
      It's a little naïve to think it works on English without the coöperation of the users. (Also, less glibly, things like emoji seem to be becoming more and more popular.)
      - imron 10y ago
        Indeed. In fact as we speak I am fixing a bug related to string handling with emojis.
    - asveikau 10y ago
      Funny. You can parse utf-8 character at a time. Some characters advance the pointer by 4 at an iteration and some less.
      - dbaupp 10y ago
        What do you mean by "character"? If you mean code point or "unicode scalar value", sure, but if you mean user-visible character (grapheme), it's much more complicated: even something "simple" like ö could be one or two code points.
        asveikau 10y ago
        I mean your iterator is char* and you advance it by adding. That's it. I do NOT mean that char itself corresponds to a glyph or codepoint, you are seriously preaching to the choir making that lecture to me.
        fauigerzigerk 10y ago
        >you advance it by adding And when do you stop? UTF-8 strings can have zero bytes in them so treating them as C strings is potentially error prone depending on the context.
IshKebab 10y ago
C seems relatively simple, but it's also incredibly easy to do the wrong thing usually without realising it. That's the problem. I suggest you read up about 'undefined behaviour'.
stevedonovan 10y ago
'sharp' would be a good word ;) There's lots to like about it but writing good safe C is harder than it looks.

pjmlp 10y ago

Historical accident, I started to work back in the days when UNIX was the only OS implemented in C. Everything else outside UNIX was using Assembly, Algol, PL/I, Modula or Pascal dialect. C owes its success to UNIX's adoption by the market, as operating system available almost free of charge to universities, with source code available.

davexunit 10y ago
C was originally a watered down version of BCPL because the computers they were targeting had very limited capabilities compared to other computers of the time. The first version of C didn't even have floating point numbers.
- pjmlp 10y ago
  Meanwhile in 1961 we had ESPOL, followed by NEWP, nowadays living on the Unisys MCP ClearPath mainframes.

wyldfire 10y ago

> I know there's a sentiment here on HN against C I think there's two major against-C groups: those of us who have worked with C for decades and those who never worked with it. I'll try and speak for those of us who've used it for decades. The popular high-level languages that have arrived since ~1995 (Java, Python, JS, C# and friends) are excellent productivity increases. In general, they sacrifice memory and performance in favor of robustness and security. For enormous software problem domains, we just don't need C's complexity or error-proneness. Until Rust, there's been very close to zero serious competitors for C if I wanted to write a bootloader, OS, or ISR. Not even C++ could do those (without being extremely creative on how it's built/used). The ~post-2000 languages (golang, swift, D etc) can't do that (perhaps D's an exception but it wasn't an initial goal AFAICT). This is huge, IMO. We've groaned and grumbled about how hard it is to parse C/C++ code for decades. This is a big deal for tooling. Because of the language's design, even if you use something "simple" like libclang to parse your code, you still have to reproduce the entire build context just to sanely make an AST. All of those other new languages above probably address this problem but also add all kinds of other stuff which we can't have for specialized problem domains (realtime/low-latency requirements, OSs, etc). > collection of ... software not going to be rewritten in eg. Rust or some (lets face it) esoteric/niche FP language IMO it's not appropriate to lump Rust in with "nice FP language"s. And don't look now but lots of stuff is being rewritten in Rust. Fundamental this-is-the-OS-at-its-root stuff: coreutils [1], "libc" [2], kernels [3], browser engines [4]. [1] https://github.com/uutils/coreutils https://github.com/uutils/coreutils [2] https://github.com/japaric/steed https://github.com/japaric/steed [3] https://github.com/redox-os https://github.com/redox-os [4] https://github.com/servo/servo https://github.com/servo/servo

tannhaeuser 10y ago
> IMO it's not appropriate to lump Rust in with "nice FP language"s. Maybe I should have expressed it better, but I didn't intend to lump these together. >And don't look now but lots of stuff is being rewritten in Rust. I'm myself cautiously optimistic re Rust, but having been burnt by C++ in the past I'm not enthusiastic about fighting language idiosyncrasies (though modern C++ certainly deserves a second look). Then there's the issue (some might argue it's a plus) that Rust is at the same time a language, a lib, and the only compiler implementation (unlike C or C++ which give you choice).

fiedzia 10y ago

> the large collection of existing (mostly F/OSS) software not going to be rewritten in eg. Rust or some It is happening and will keep happening and it is really necessary at some point. Sure, I don't expect large project to be rewritten overnight, but every large project is being redone eventually. Especially when C becomes main source of problems. And you can introduce better languages gradually. > operating systems, drivers https://github.com/redox-os/redox https://github.com/redox-os/redox > IP stacks https://github.com/QuiltOS/QuiltNet https://github.com/QuiltOS/QuiltNet Many of those are often written in userspace, where you are free to use any language. Several of them will provide sufficient performance. > databases, Unix userland tools, web servers, mail servers, parts of web browsers and other network clients, language runtimes and libs of higher-level languages, compilers and almost all other infrastructure software we use daily. For all of those you'll find Rust implementations. Some are work in progress, some are already widely used.

vbezhenar 10y ago

A lot of mentioned software was started many years ago, when other languages were hardly viable options. And those programs are good enough now, so there's no much movement to replace them. It's not a good argument for C, IMO. It's like telling that Windows is awesome because so many users use it. But when people started from scratch (mobile world), it turned out, that Windows is not the best OS. Actually when I'm reading about new software, it's very rare to encounter C. Usually it's something else.