3 ms·

> I'm sorry, but the C language toolchain is not great. The only part of the C language toolchain that is good is it's platform support. Every platform has a C

by User23 4y ago

> I'm sorry, but the C language toolchain is not great. The only part of the C language toolchain that is good is it's platform support. Every platform has a C compiler. Please take a few days to review John Regehr’s excellent blog. I’m certain that you’ll find dispelling your ignorance rewarding. > How do you grab dependencies for and build javascript? npm install, npm build. Npm is the poster child for supply chain attacks.

cogman10 4y ago
> Please take a few days to review John Regehr’s excellent blog. Haven't heard of him but will certainly give a read. Thanks for the heads up. > Npm is the poster child for supply chain attacks. The only reason C doesn't (often) have similar supply chain attacks is because pulling in dependencies is so hard that you aren't likely to end up with a 10k dependency project. Hard to say that's really a plus. Other ecosystems have their own problems and certainly aren't perfect. However, the toolchains are generally leaps and bounds ahead of what C currently has.
- ducktective 4y ago
  >The only reason C doesn't (often) have similar supply chain attacks is because pulling in dependencies is so hard that you aren't likely to end up with a 10k dependency project. Or the lack of canonical package manager means the developer has to actually spend time to inspect the quality of each dependency instead of `npm install is-odd`ing like there is no tomorrow. It also acts as a "filter" to prevent adding complexity to the dependency tree.
  - pjmlp 4y ago
    They will do `apt-get install is-odd` instead, or yum, pacman, or...
    - intelVISA 4y ago
      I do most of my heavy lifting with Git commit hashes via FetchContent and it's been pretty good to be fair, surprising number of well written CMakeLists in popular lib repos.
- jjav 4y ago
  > you aren't likely to end up with a 10k dependency project. > Hard to say that's really a plus. I'll definitely call that a plus. All dependencies introduce risk. Sure, we can't avoid all dependencies, but carefully evaluating them and keeping the list small is a big win for maintainability and security. If a random library has a 0.1% chance of having malicious code (I'd say it's more like 1%, but let's be generous), a 10K-dependency program is guaranteed to be pulling in at least something malicious.
jhatemyjob 4y ago
Good eye. I might add: the blind praise of garbage collection, and the "symbol not found xyz" bit raised an eyebrow for me. You can't trust HN comments. Most of them sound good to laymen. But to a trained eye, it's a comment tree of cards.
- cogman10 4y ago
  > i might add the blind praise of garbage collection raised an eyebrow for me. Like it or not, a problem C has is that it's pretty much impossible to determine why a piece of memory is currently being retained. Tools like valgrind and jemalloc can give you good starting points but really can't point to issues where "This memory is being retained because of this linked list over here" Languages with GCs can, at any point, dump the heap and provide tools for analyzing that heap to point to the exact reason why a bit of memory is currently being retained. That's not really "blind" praise of GCed languages, simply a fact of how they operate.
  - User23 4y ago
    You’re not wrong that aliasing presents serious practical problems for building an efficient object graph. The thing is the defining characteristic of a C-like is that it has an ultra lightweight runtime[1]. The way I look at it, every C program has a bespoke garbage collector of variable quality. It’s fair to say the median is pretty dismal sure, but tooling does exist to tame that beast. I think there’s a wide open research space to work on taming the aliasing problem. There are PhDs to be had, and maybe even Turing awards. [1] C gets to cheat a little bit here because Unix and friends are its runtime.
    - cogman10 4y ago
      > he thing is the defining characteristic of a C-like is that it has an ultra lightweight runtime Agreed. And with my critique of the toolchain, I didn't mean to imply that C isn't a reasonable choice in many situations. But rather, holding up the C toolchain as a reason to pick C over an alternative isn't reasonable in my opinion. In particular, because a lot of C alternatives piggy back on the C ecosystem by using LLVM as a backend. So you end up with a superset of tools. The C alternative ecosystem and the C ecosystem. Pick C if it's all that's available. Pick it if you plan on distributing your app/lib onto that IBM RPG server. Pick it if your software is already written in C. Pick it if your software is a simple app that runs for 1 second then shuts down (and it isn't really mission critical). Pick it if memory safety isn't really a problem. Pick it if that ultra thin runtime is an absolute necessity. Pick it if you have a bunch of C devs that don't want to learn a new language. But don't pick it because you are afraid new languages won't have something as good as valgrind or gdb. Any semi-popular language born in the last 20 years (that wasn't written yesterday) will almost certainly have better tooling than C.
DoctorOW 4y ago
> Please take a few days to review John Regehr’s excellent blog. I’m certain that you’ll find dispelling your ignorance rewarding. Just a heads up, this reads to me as condescending.
lifthrasiir 4y ago
> Please take a few days to review John Regehr’s excellent blog. I’m certain that you’ll find dispelling your ignorance rewarding. I regularly read his blog and I found nothing to back you up. He mostly work on a generic compiler toolchain (LLVM) other than C-specific tools and his work easily translates to many other languages using LLVM. And even a rare C-specific tool like C-Reduce is not that hard to adapt for other languages; C-Reduce is actually language-agnostic and works well for many other curly-brace languages as well.

by User23 4y ago

cogman10 4y ago

> Please take a few days to review John Regehr’s excellent blog. Haven't heard of him but will certainly give a read. Thanks for the heads up. > Npm is the poster child for supply chain attacks. The only reason C doesn't (often) have similar supply chain attacks is because pulling in dependencies is so hard that you aren't likely to end up with a 10k dependency project. Hard to say that's really a plus. Other ecosystems have their own problems and certainly aren't perfect. However, the toolchains are generally leaps and bounds ahead of what C currently has.

ducktective 4y ago
>The only reason C doesn't (often) have similar supply chain attacks is because pulling in dependencies is so hard that you aren't likely to end up with a 10k dependency project. Or the lack of canonical package manager means the developer has to actually spend time to inspect the quality of each dependency instead of `npm install is-odd`ing like there is no tomorrow. It also acts as a "filter" to prevent adding complexity to the dependency tree.
- pjmlp 4y ago
  They will do `apt-get install is-odd` instead, or yum, pacman, or...
  - intelVISA 4y ago
    I do most of my heavy lifting with Git commit hashes via FetchContent and it's been pretty good to be fair, surprising number of well written CMakeLists in popular lib repos.
jjav 4y ago
> you aren't likely to end up with a 10k dependency project. > Hard to say that's really a plus. I'll definitely call that a plus. All dependencies introduce risk. Sure, we can't avoid all dependencies, but carefully evaluating them and keeping the list small is a big win for maintainability and security. If a random library has a 0.1% chance of having malicious code (I'd say it's more like 1%, but let's be generous), a 10K-dependency program is guaranteed to be pulling in at least something malicious.

jhatemyjob 4y ago

Good eye. I might add: the blind praise of garbage collection, and the "symbol not found xyz" bit raised an eyebrow for me. You can't trust HN comments. Most of them sound good to laymen. But to a trained eye, it's a comment tree of cards.

cogman10 4y ago
> i might add the blind praise of garbage collection raised an eyebrow for me. Like it or not, a problem C has is that it's pretty much impossible to determine why a piece of memory is currently being retained. Tools like valgrind and jemalloc can give you good starting points but really can't point to issues where "This memory is being retained because of this linked list over here" Languages with GCs can, at any point, dump the heap and provide tools for analyzing that heap to point to the exact reason why a bit of memory is currently being retained. That's not really "blind" praise of GCed languages, simply a fact of how they operate.
- User23 4y ago
  You’re not wrong that aliasing presents serious practical problems for building an efficient object graph. The thing is the defining characteristic of a C-like is that it has an ultra lightweight runtime[1]. The way I look at it, every C program has a bespoke garbage collector of variable quality. It’s fair to say the median is pretty dismal sure, but tooling does exist to tame that beast. I think there’s a wide open research space to work on taming the aliasing problem. There are PhDs to be had, and maybe even Turing awards. [1] C gets to cheat a little bit here because Unix and friends are its runtime.
  - cogman10 4y ago
    > he thing is the defining characteristic of a C-like is that it has an ultra lightweight runtime Agreed. And with my critique of the toolchain, I didn't mean to imply that C isn't a reasonable choice in many situations. But rather, holding up the C toolchain as a reason to pick C over an alternative isn't reasonable in my opinion. In particular, because a lot of C alternatives piggy back on the C ecosystem by using LLVM as a backend. So you end up with a superset of tools. The C alternative ecosystem and the C ecosystem. Pick C if it's all that's available. Pick it if you plan on distributing your app/lib onto that IBM RPG server. Pick it if your software is already written in C. Pick it if your software is a simple app that runs for 1 second then shuts down (and it isn't really mission critical). Pick it if memory safety isn't really a problem. Pick it if that ultra thin runtime is an absolute necessity. Pick it if you have a bunch of C devs that don't want to learn a new language. But don't pick it because you are afraid new languages won't have something as good as valgrind or gdb. Any semi-popular language born in the last 20 years (that wasn't written yesterday) will almost certainly have better tooling than C.

DoctorOW 4y ago

> Please take a few days to review John Regehr’s excellent blog. I’m certain that you’ll find dispelling your ignorance rewarding. Just a heads up, this reads to me as condescending.

lifthrasiir 4y ago

> Please take a few days to review John Regehr’s excellent blog. I’m certain that you’ll find dispelling your ignorance rewarding. I regularly read his blog and I found nothing to back you up. He mostly work on a generic compiler toolchain (LLVM) other than C-specific tools and his work easily translates to many other languages using LLVM. And even a rare C-specific tool like C-Reduce is not that hard to adapt for other languages; C-Reduce is actually language-agnostic and works well for many other curly-brace languages as well.