6 ms·

I'd consider myself the former: I use C because it's the only viable option for what I'm doing - but most of the time it's nothing to do with C itself, but the

I'd consider myself the former: I use C because it's the only viable option for what I'm doing - but most of the time it's nothing to do with C itself, but the various extensions and builtins of GCC. It's the inline asm, the control of registers, placement of code and data, control of inlining, etc, which are missing from all of the C "replacements". The replacements assume you are building a user application on top of an existing unix-like OS or VM, but they're missing the parts necessary to write the OS or VM itself. They don't provide simple ways to use hardware-specific features. Obviously there is C++ which can leverage most of this too, but C++ traps you into an ABI which is difficult to use from any language which is not C++.

galaxyLogic 4y ago
Good points. I like C, I think simplicity and hardware alignment make it very useful. Simplicity wins in the end.
- cat_plus_plus 4y ago
  C is not aligned with modern hardware and optimizing compilers are severely hampered by things like undeclared pointer aliasing.
  - fsckboy 4y ago
    so then, add a declarator or two to solve the problem, don't just throw the baby out with the bathwater. The population of C programmers who understand how C works is the population of people who can understand how hardware works. The reverse has never been true, hardware designers have never understood software, and academic software experts have spent too much time babysitting college freshman who can't code and spend all their time dreaming about languages that freshmen could learn well enough to TA the course. But that's probably not a language good enough for systems programmers to adopt.
    - pjmlp 3y ago
      It is called restrict and usually a fun problem to debug if one causes UB by actually having two restrict pointers doing aliasing.
  - lelanthran 3y ago
    > C is not aligned with modern hardware and optimizing compilers are severely hampered by things like undeclared pointer aliasing. Which language is? I mean, if you're going to parrot this line, surely you have an example of a language that is more closely aligned to hardware than C, right? I see this line repeated in every HN thread about C. It's not a new sentiment, but it is mostly wrong because the implication is that there exists some other popular language that actually aligns with the hardware better than C does.
    - galaxyLogic 3y ago
      A language can not be exactly aligned to every possible hardware variation at the same time of course. So C does dome abstracting from the hardware level but keeps the mental model of memory locations which can be pointed to by pointers.
      - lelanthran 3y ago
        > A language can not be exactly aligned to every possible hardware variation at the same time of course. So C does dome abstracting from the hardware level but keeps the mental model of memory locations which can be pointed to by pointers. Sure, and I agree with you, but anyone complaining that the language which models hardware more closely than any other language, "doesn't model the hardware" should be prepared for the followup question of "Well, which other language in common use is closer to the hardware?" It's really tiring reading the same old assertions in every thread about C; usually backed up by the same two or three sources that everyone has already read.
whstl 4y ago
I also consider myself the former. I often use C not so much to stay close to the hardware, but to be closer to the operating system APIs. Of course, there are often API bindings for other languages, but they're often very incomplete, buggy, non-idiomatic, non-ergonomic, or lacking performance. And IME you only find this out after a few months. But from the get-go they're always worse documented and less flexible. I tend to mix C with other languages, like Rust or Python. This is mostly for audio and graphics stuff. With that said: Swift replaced C (and Obj-C) 100% in the Apple world for me. Because the API bindings are as good.
bluejekyll 4y ago
Out of curiosity, have you looked at the ASM inlining options in Rust? https://doc.rust-lang.org/reference/inline-assembly.html https://doc.rust-lang.org/reference/inline-assembly.html
- infamouscow 4y ago
  Rust's inline assembly and configurable targets sets the standard going forward. I just wish their trademark policy relaxed some of the non-trademark related requirements making it a deal-breaker.
  - jenadine 4y ago
    What does the trademark policy has to do with this? Btw the recent fuzz recently was about some proposal and not the actual one. This is the policy: https://foundation.rust-lang.org/policies/logo-policy-and-media-guide/ https://foundation.rust-lang.org/policies/logo-policy-and-me... and I don't see any deal breaker.
    - infamouscow 3y ago
      The use of trademark enforcement to coerce conferences into certain policies (which might contradict local law) is a deal breaker. It also demonstrates a willingness of the foundation to use wield power for purposes completely unrelated to the language.
      - jenadine 3y ago
        There is no such things about forcing policies for conferences in the current trademark policy. (You're getting confused with a proposal that is being re-worked) And even if there was it's hardly a deal breaker to use the language.
        infamouscow 3y ago
        The proposed policy, which is clearly political in nature, has resulted in our firm decision not to adopt the crab language for our projects. Although Rust™ offers valuable features, introducing politics into the equation was both unnecessary and has caused a rift that may prove difficult to mend.
pjmlp 4y ago
Unless that ABI is something like COM or WinRT.
johnny22 4y ago
We have entire OSes built in rust, so that' not the case there. That's both for mcus and desktop machines and beyond.
WalterBright 4y ago
D has a very nice inline assembler, bitfields, inline control, alignment control, etc. C's "register" keyword has been ignored since 1990 or so.
- sparkie 4y ago
  "register" is still supported by GCC for combined use with asm. eg, `register uintptr_t x asm ("edx");` Does D support anything like `__attribute__((section("t1")))`, so we can have the linker decide how to locate some compiled code, or computed gotos? Can we use D's inline assembler to clobber registers? I've had trouble even with clang and extended asm. For example, LLVM does not support the "g" constraint. I understand that there aren't many use-cases for these specific features, but I have an unusual direct-threaded VM which relies on some of them, and the only real alternative I see is to write plain assembly.
  - zyedidia 4y ago
    I've been using D for OS development and have found it very good for controlling low-level details. GDC is the GCC frontend for D, and has most/all of the same features for controlling this stuff as GCC. For example, you can use `@register("edx") ulong x;` to specify that a variable should be in a particular register, `@section("t1")` on functions to place them in certain sections, and the inline assembler is the same as with GCC. Note: the @register feature is new with GDC 13. See here for the docs: https://gcc.gnu.org/onlinedocs/gdc/ https://gcc.gnu.org/onlinedocs/gdc/. And of course LDC supports all the LLVM custom attributes, plus GCC-compatible inline assembler (not sure about the "g" constraint though) and LLVM-style inline assembler.
    - sparkie 4y ago
      Thanks for the information. Appears that it does support the section attribute from GCC too. I'll have to explore this a bit and see if I can use it, since it seems to have all or most the features I use. I did learn D some years ago when the standard library situation was not great, but might be worth looking at again.
humanrebar 4y ago
> Obviously there is C++ which can leverage most of this too, but C++ traps you into an ABI which is difficult to use from any language which is not C++. To be fair to C++, all the other languages in this space are as bad at providing ABIs in their own languages. All (almost?) mostly provide ways to declare C ABIs, which C++ also supports. C++ has rough C++ ABIs, but mostly because it bothers to try in the first place. It's not like other languages really "solved" ABI better than C++ has. Even C ABIs are a little rough since there's so much preprocessor use to factor in and/or avoid.
- sparkie 4y ago
  C's ABI is that much simpler because it doesn't really place any constraints on the memory layout of your types. With C++ (and others), the values passed around may also have vtables linked to them, so your language must then also provide an in-memory representation of objects which is compatible with the C++ representation in order to do FFI method calls. That places quite a constraint on your language because to do it efficiently you basically want a copy of the C++ object model. So you're developing a kind of C++ sibling language, and C++ is quite complex, and now any other languages which want to interoperate with yours has to do the same. This is why it's pretty standard to just have a C FFI and provide a C wrapper for C++ libraries to use them with other languages.
  - jenadine 3y ago
    Of course the C ABI places constraints on the memory layout of the types. For example, alignment. Also in what register "small" types are passed when passing them to functions. It actually depends if the struct has float members or not. C itself is quite complex already. C++ adds more features. But for example, the Rust ABI uses the C++ ABI, because C is too simple and doesn't support unwinding (for panics) or 128bit integers
deleted 4y ago
[deleted]
zabzonk 4y ago
we don't have standard ABIs for either C or C++; we have conventions.
- msla 4y ago
  Counterpoint: https://wiki.osdev.org/System_V_ABI https://wiki.osdev.org/System_V_ABI The System V ABI is closer to being a standard than some official standards are. C++ gets odd with name mangling, but the platform's C ABI is typically the tune every other language must dance to for its FFI.
  - kps 4y ago
    > The System V ABI is closer to being a standard than some official standards are. That brings back some unpleasant memories. What happens when a popular compiler decides that whatever they choose is the ABI, and the published spec be damned? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
  - pjmlp 3y ago
    Counterpoint, https://en.wikipedia.org/wiki/IBM_i https://en.wikipedia.org/wiki/IBM_i https://os.mbed.com/docs/mbed-os/v6.16/apis/platform.html https://os.mbed.com/docs/mbed-os/v6.16/apis/platform.html Not every OS is written in C, thus the platform ABI isn't always C.

galaxyLogic 4y ago

Good points. I like C, I think simplicity and hardware alignment make it very useful. Simplicity wins in the end.

cat_plus_plus 4y ago
C is not aligned with modern hardware and optimizing compilers are severely hampered by things like undeclared pointer aliasing.
- fsckboy 4y ago
  so then, add a declarator or two to solve the problem, don't just throw the baby out with the bathwater. The population of C programmers who understand how C works is the population of people who can understand how hardware works. The reverse has never been true, hardware designers have never understood software, and academic software experts have spent too much time babysitting college freshman who can't code and spend all their time dreaming about languages that freshmen could learn well enough to TA the course. But that's probably not a language good enough for systems programmers to adopt.
  - pjmlp 3y ago
    It is called restrict and usually a fun problem to debug if one causes UB by actually having two restrict pointers doing aliasing.
- lelanthran 3y ago
  > C is not aligned with modern hardware and optimizing compilers are severely hampered by things like undeclared pointer aliasing. Which language is? I mean, if you're going to parrot this line, surely you have an example of a language that is more closely aligned to hardware than C, right? I see this line repeated in every HN thread about C. It's not a new sentiment, but it is mostly wrong because the implication is that there exists some other popular language that actually aligns with the hardware better than C does.
  - galaxyLogic 3y ago
    A language can not be exactly aligned to every possible hardware variation at the same time of course. So C does dome abstracting from the hardware level but keeps the mental model of memory locations which can be pointed to by pointers.
    - lelanthran 3y ago
      > A language can not be exactly aligned to every possible hardware variation at the same time of course. So C does dome abstracting from the hardware level but keeps the mental model of memory locations which can be pointed to by pointers. Sure, and I agree with you, but anyone complaining that the language which models hardware more closely than any other language, "doesn't model the hardware" should be prepared for the followup question of "Well, which other language in common use is closer to the hardware?" It's really tiring reading the same old assertions in every thread about C; usually backed up by the same two or three sources that everyone has already read.

whstl 4y ago

I also consider myself the former. I often use C not so much to stay close to the hardware, but to be closer to the operating system APIs. Of course, there are often API bindings for other languages, but they're often very incomplete, buggy, non-idiomatic, non-ergonomic, or lacking performance. And IME you only find this out after a few months. But from the get-go they're always worse documented and less flexible. I tend to mix C with other languages, like Rust or Python. This is mostly for audio and graphics stuff. With that said: Swift replaced C (and Obj-C) 100% in the Apple world for me. Because the API bindings are as good.

bluejekyll 4y ago

Out of curiosity, have you looked at the ASM inlining options in Rust? https://doc.rust-lang.org/reference/inline-assembly.html https://doc.rust-lang.org/reference/inline-assembly.html

infamouscow 4y ago
Rust's inline assembly and configurable targets sets the standard going forward. I just wish their trademark policy relaxed some of the non-trademark related requirements making it a deal-breaker.
- jenadine 4y ago
  What does the trademark policy has to do with this? Btw the recent fuzz recently was about some proposal and not the actual one. This is the policy: https://foundation.rust-lang.org/policies/logo-policy-and-media-guide/ https://foundation.rust-lang.org/policies/logo-policy-and-me... and I don't see any deal breaker.
  - infamouscow 3y ago
    The use of trademark enforcement to coerce conferences into certain policies (which might contradict local law) is a deal breaker. It also demonstrates a willingness of the foundation to use wield power for purposes completely unrelated to the language.
    - jenadine 3y ago
      There is no such things about forcing policies for conferences in the current trademark policy. (You're getting confused with a proposal that is being re-worked) And even if there was it's hardly a deal breaker to use the language.
      - infamouscow 3y ago
        The proposed policy, which is clearly political in nature, has resulted in our firm decision not to adopt the crab language for our projects. Although Rust™ offers valuable features, introducing politics into the equation was both unnecessary and has caused a rift that may prove difficult to mend.

pjmlp 4y ago

Unless that ABI is something like COM or WinRT.

johnny22 4y ago

We have entire OSes built in rust, so that' not the case there. That's both for mcus and desktop machines and beyond.

WalterBright 4y ago

D has a very nice inline assembler, bitfields, inline control, alignment control, etc. C's "register" keyword has been ignored since 1990 or so.

sparkie 4y ago
"register" is still supported by GCC for combined use with asm. eg, `register uintptr_t x asm ("edx");` Does D support anything like `__attribute__((section("t1")))`, so we can have the linker decide how to locate some compiled code, or computed gotos? Can we use D's inline assembler to clobber registers? I've had trouble even with clang and extended asm. For example, LLVM does not support the "g" constraint. I understand that there aren't many use-cases for these specific features, but I have an unusual direct-threaded VM which relies on some of them, and the only real alternative I see is to write plain assembly.
- zyedidia 4y ago
  I've been using D for OS development and have found it very good for controlling low-level details. GDC is the GCC frontend for D, and has most/all of the same features for controlling this stuff as GCC. For example, you can use `@register("edx") ulong x;` to specify that a variable should be in a particular register, `@section("t1")` on functions to place them in certain sections, and the inline assembler is the same as with GCC. Note: the @register feature is new with GDC 13. See here for the docs: https://gcc.gnu.org/onlinedocs/gdc/ https://gcc.gnu.org/onlinedocs/gdc/. And of course LDC supports all the LLVM custom attributes, plus GCC-compatible inline assembler (not sure about the "g" constraint though) and LLVM-style inline assembler.
  - sparkie 4y ago
    Thanks for the information. Appears that it does support the section attribute from GCC too. I'll have to explore this a bit and see if I can use it, since it seems to have all or most the features I use. I did learn D some years ago when the standard library situation was not great, but might be worth looking at again.

humanrebar 4y ago

> Obviously there is C++ which can leverage most of this too, but C++ traps you into an ABI which is difficult to use from any language which is not C++. To be fair to C++, all the other languages in this space are as bad at providing ABIs in their own languages. All (almost?) mostly provide ways to declare C ABIs, which C++ also supports. C++ has rough C++ ABIs, but mostly because it bothers to try in the first place. It's not like other languages really "solved" ABI better than C++ has. Even C ABIs are a little rough since there's so much preprocessor use to factor in and/or avoid.

sparkie 4y ago
C's ABI is that much simpler because it doesn't really place any constraints on the memory layout of your types. With C++ (and others), the values passed around may also have vtables linked to them, so your language must then also provide an in-memory representation of objects which is compatible with the C++ representation in order to do FFI method calls. That places quite a constraint on your language because to do it efficiently you basically want a copy of the C++ object model. So you're developing a kind of C++ sibling language, and C++ is quite complex, and now any other languages which want to interoperate with yours has to do the same. This is why it's pretty standard to just have a C FFI and provide a C wrapper for C++ libraries to use them with other languages.
- jenadine 3y ago
  Of course the C ABI places constraints on the memory layout of the types. For example, alignment. Also in what register "small" types are passed when passing them to functions. It actually depends if the struct has float members or not. C itself is quite complex already. C++ adds more features. But for example, the Rust ABI uses the C++ ABI, because C is too simple and doesn't support unwinding (for panics) or 128bit integers

deleted 4y ago

[deleted]

zabzonk 4y ago

we don't have standard ABIs for either C or C++; we have conventions.

msla 4y ago
Counterpoint: https://wiki.osdev.org/System_V_ABI https://wiki.osdev.org/System_V_ABI The System V ABI is closer to being a standard than some official standards are. C++ gets odd with name mangling, but the platform's C ABI is typically the tune every other language must dance to for its FFI.
- kps 4y ago
  > The System V ABI is closer to being a standard than some official standards are. That brings back some unpleasant memories. What happens when a popular compiler decides that whatever they choose is the ABI, and the published spec be damned? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
- pjmlp 3y ago
  Counterpoint, https://en.wikipedia.org/wiki/IBM_i https://en.wikipedia.org/wiki/IBM_i https://os.mbed.com/docs/mbed-os/v6.16/apis/platform.html https://os.mbed.com/docs/mbed-os/v6.16/apis/platform.html Not every OS is written in C, thus the platform ABI isn't always C.