4 ms·

> C is not elegant okay, tastes differ, but it remains what it was in one of its original definitions: a sufficiently portable assembly. > #include hell / mod

by kelas 3y ago

> C is not elegant okay, tastes differ, but it remains what it was in one of its original definitions: a sufficiently portable assembly. > #include hell / modularity okay, so rust has cargo, so we’re all better now, right? but what if someone will dare to argue that C has a whole bunch of cargos, some less terrible than others, if we reframe the problem like so: $ [rpm|dpkg|dnf|yum|apt|brew|pkg-add] install libcurl libcurl-dev(el) (this makes me wonder how any software even works anymore in absence of universal cargo cult, but hey)

viraptor 3y ago
Different things entirely. System-specific packages have no concept of C building or linking. Things work because of some agreement about paths + pkgconfig + others. This is very far from the idea of a dependency manager like cargo which is very much aware of project-specific and language features.
- kelas 3y ago
  > Different things entirely yes, they are. > System-specific packages have no concept of C building or linking. every day i learn something new, but this time around I’m gonna go ahead a tell you that you are very mistaken. > Things work because of some agreement about paths + pkgconfig + others. True. By convention, we call it “convention”, or “standard” for short, e.g. POSIX or ISO C. Call us back once you have something like that in rustland. > This is very far from the idea of a dependency manager like cargo which is very much aware of project-specific and language features. All good and sound, and makes total sense for userland software. But what is being discussed here is an operating system and core userland. If you can imagine that to be your “project”, such as linux or OpenBSD, maybe my tongue-in-cheek comparison of a system-wide dependency manager suddenly looks less dissimilar to cargo. needless to say, things like Linux and OpenBSD will stay written in C for a little while longer. In case of BSD specifically, you can go as crazy as to bump and rebuild your entire system from source in place, kernel and userland. BSD is one pretty old cargo cult in that sense, and pretty cool, i might add. > language features right… rust 2018 edition is not really rust as of 2023, or is it? This where those pesky standards come very handy.
  - viraptor 3y ago
    > tell you that you are very mistaken. Go on then. Beyond RPMs ability to depend on soname, what else is there on the structure/installation/usage side (not on the building side which can include whatever scripts you want). Where are they now aware of the libraries more than tar.gz is?
    - kelas 3y ago
      I think I see your point. Thing is, a C program can be built and executed without that cargo dependency pyramid sandwiched into a gigantic runtime polyp. The whole operating system is your environment, and yes - if ‘man ldconfig’ is not your friend, then maybe pkg-config is, or, worse to worst, link against project-local structure, where you can indeed build the bejesus out of your imagination and ship it. That’s ok. It’s linux, after all. That’s what we do for embedded systems, anyway. I haven’t seen much success for rust in this department, although people are clearly trying to make it work. It just keeps coming out fat and ugly. A few more decades of hard push, call me a maybe. Do you know what riscv version of xv6 rev3 compiles to in terms of object size? I will not spoil it for you, but it compiles to total shreds.
lproven 3y ago
> a sufficiently portable assembly. No, it isn't, and it hasn't been for about 40 years. « C Is Not a Low-level Language Your computer is not a fast PDP-11. » https://queue.acm.org/detail.cfm?id=3212479 https://queue.acm.org/detail.cfm?id=3212479 David Chisnall, ACM Queue, April 30, 2018
- kelas 3y ago
  Sounds expensive, thanks. So: Preface to the Digital Edition of Kernighan and Ritchie's The C Programming Language Oct 31, 2012 “… Remarkably, in spite of all of this change, C retains a central position. It is still the core language for operating system implementation and tool building. It remains unequaled for portability, efficiency, and ability to get close to the hardware when necessary. C has sometimes been called a high-level assembler, and this is not a bad characterization of how well it spans the range from intricate data structure and control flow to the lowest level of external devices.” (sorry, I messed up the lyrics a bit, but also I didn’t, really) Also, my computer is a fast Turing machine. And so is yours.
  - lproven 3y ago
    I can't make any sense of a single sentence of that. > Sounds expensive, thanks Huh? What does? The paper is entirely free. That's why I posted a link. Go read it. It's not very long, it's interesting, it's accessible, it's provocative and insightful and profound. > Kernighan and Ritchie Creator of C is biased about the language he created. Shock. Pictures at 11. K&R was published in 1988. Then, your PC was to some degree a fast PDP-11. That was over 1/3 of a century ago and it is no longer even remotely true. > Also, my computer is a fast Turing machine. And so is yours. Reductio ad absurdam. Here's a talk from the inventor of the Arm architecture. It's pretty good. https://www.youtube.com/watch?v=6lOnpQgn-9s https://www.youtube.com/watch?v=6lOnpQgn-9s She talks about her more recent baby, Firepath. It can, for instance, in a single opcode and a single CPU cycle load 4 separate different 32 bit integers, multiply them by 4 other 32-bit ints and store the result. (Around 25 min in but it's very worth watching the whole talk.) Her point is that C can't express stuff like this well at all. A modern CPU has dozens of execution units doing stuff in parallel, applying matrix operations and transformations to multiple different streams of data simultaneously: SIMD and MIMD combined. C has no way of even beginning to express any of this. C is no more a high-level assembly language for any 21st century CPU than a Falcon-9 reusable orbital launch vehicle is a space-going version of the Wright Flyer.

by kelas 3y ago

viraptor 3y ago

Different things entirely. System-specific packages have no concept of C building or linking. Things work because of some agreement about paths + pkgconfig + others. This is very far from the idea of a dependency manager like cargo which is very much aware of project-specific and language features.

kelas 3y ago
> Different things entirely yes, they are. > System-specific packages have no concept of C building or linking. every day i learn something new, but this time around I’m gonna go ahead a tell you that you are very mistaken. > Things work because of some agreement about paths + pkgconfig + others. True. By convention, we call it “convention”, or “standard” for short, e.g. POSIX or ISO C. Call us back once you have something like that in rustland. > This is very far from the idea of a dependency manager like cargo which is very much aware of project-specific and language features. All good and sound, and makes total sense for userland software. But what is being discussed here is an operating system and core userland. If you can imagine that to be your “project”, such as linux or OpenBSD, maybe my tongue-in-cheek comparison of a system-wide dependency manager suddenly looks less dissimilar to cargo. needless to say, things like Linux and OpenBSD will stay written in C for a little while longer. In case of BSD specifically, you can go as crazy as to bump and rebuild your entire system from source in place, kernel and userland. BSD is one pretty old cargo cult in that sense, and pretty cool, i might add. > language features right… rust 2018 edition is not really rust as of 2023, or is it? This where those pesky standards come very handy.
- viraptor 3y ago
  > tell you that you are very mistaken. Go on then. Beyond RPMs ability to depend on soname, what else is there on the structure/installation/usage side (not on the building side which can include whatever scripts you want). Where are they now aware of the libraries more than tar.gz is?
  - kelas 3y ago
    I think I see your point. Thing is, a C program can be built and executed without that cargo dependency pyramid sandwiched into a gigantic runtime polyp. The whole operating system is your environment, and yes - if ‘man ldconfig’ is not your friend, then maybe pkg-config is, or, worse to worst, link against project-local structure, where you can indeed build the bejesus out of your imagination and ship it. That’s ok. It’s linux, after all. That’s what we do for embedded systems, anyway. I haven’t seen much success for rust in this department, although people are clearly trying to make it work. It just keeps coming out fat and ugly. A few more decades of hard push, call me a maybe. Do you know what riscv version of xv6 rev3 compiles to in terms of object size? I will not spoil it for you, but it compiles to total shreds.

lproven 3y ago

> a sufficiently portable assembly. No, it isn't, and it hasn't been for about 40 years. « C Is Not a Low-level Language Your computer is not a fast PDP-11. » https://queue.acm.org/detail.cfm?id=3212479 https://queue.acm.org/detail.cfm?id=3212479 David Chisnall, ACM Queue, April 30, 2018

kelas 3y ago
Sounds expensive, thanks. So: Preface to the Digital Edition of Kernighan and Ritchie's The C Programming Language Oct 31, 2012 “… Remarkably, in spite of all of this change, C retains a central position. It is still the core language for operating system implementation and tool building. It remains unequaled for portability, efficiency, and ability to get close to the hardware when necessary. C has sometimes been called a high-level assembler, and this is not a bad characterization of how well it spans the range from intricate data structure and control flow to the lowest level of external devices.” (sorry, I messed up the lyrics a bit, but also I didn’t, really) Also, my computer is a fast Turing machine. And so is yours.
- lproven 3y ago
  I can't make any sense of a single sentence of that. > Sounds expensive, thanks Huh? What does? The paper is entirely free. That's why I posted a link. Go read it. It's not very long, it's interesting, it's accessible, it's provocative and insightful and profound. > Kernighan and Ritchie Creator of C is biased about the language he created. Shock. Pictures at 11. K&R was published in 1988. Then, your PC was to some degree a fast PDP-11. That was over 1/3 of a century ago and it is no longer even remotely true. > Also, my computer is a fast Turing machine. And so is yours. Reductio ad absurdam. Here's a talk from the inventor of the Arm architecture. It's pretty good. https://www.youtube.com/watch?v=6lOnpQgn-9s https://www.youtube.com/watch?v=6lOnpQgn-9s She talks about her more recent baby, Firepath. It can, for instance, in a single opcode and a single CPU cycle load 4 separate different 32 bit integers, multiply them by 4 other 32-bit ints and store the result. (Around 25 min in but it's very worth watching the whole talk.) Her point is that C can't express stuff like this well at all. A modern CPU has dozens of execution units doing stuff in parallel, applying matrix operations and transformations to multiple different streams of data simultaneously: SIMD and MIMD combined. C has no way of even beginning to express any of this. C is no more a high-level assembly language for any 21st century CPU than a Falcon-9 reusable orbital launch vehicle is a space-going version of the Wright Flyer.