4 ms·

I think these threads attract people that write code for performance-critical use cases which explains the "cosmic horror" over pretty benign things. I agree th

by hypeatei 11mo ago

I think these threads attract people that write code for performance-critical use cases which explains the "cosmic horror" over pretty benign things. I agree though: most programs aren't going to be brought to their knees over some GC sweeps every so often.

KerrAvon 11mo ago
Outside of hobbyist things, performance-critical code is the only responsible use case for a non-memory safe language like C in 2025, so of course it does. (Even that window is rapidly closing, though; languages like Rust and Swift can be better than C for perf-critical things because of the immutability guarantees.)
- lelanthran 11mo ago
  > Outside of hobbyist things, performance-critical code is the only responsible use case for a non-memory safe language like C in 2025, so of course it does. Maybe; I sometimes write non-hobbyist non-performance-critical code in C. I'm actually planning a new product for 2026 that might be done in C (the current iteration of that product line is in Go, the previous iteration was in Python). I've few qualms about writing the server in C.
  - josephg 11mo ago
    > I've few qualms about writing the server in C. Bad Unicode support. Lack of cross platform system libraries. Needing to deal with CMake / autotools / whatever. Poor error handling. No built in string, list or map types. No generics. Nullability. No sum types. No option, tuples or multi returns. Generally worse IDE support than a lot of languages. No good 3rd party package ecosystem. The modern idiocy of header files. Memory bugs. Debugging memory corruption bugs. … I mean, yeah other than all those problems, C is a great little language.
    - lelanthran 11mo ago
      > Bad Unicode support. Lack of cross platform system libraries. Needing to deal with CMake / autotools / whatever. Poor error handling. No built in string, list or map types. No generics. Nullability. No sum types. No option, tuples or multi returns. Generally worse IDE support than a lot of languages. No good 3rd party package ecosystem. The modern idiocy of header files. Memory bugs. Debugging memory corruption bugs. … You make some good, if oft-repeated, points; but for my product: 1. Bad Unicode support - I'm not sure what I will use this for; glyphs won't be handled by a server program and storage/search of UTF8/codepoints will be handled by the data store (PostgreSQL, if you must know). 2. CMake/autotools/etc - low list of 3rd party dependencies, so a plain Makefile works. 3. Worse IDE support than a lot of languages - not sure what you mean by this. C has LSP support, like every other language. I haven't noticed C support in editors to be worse than other languages. 4. No 3rd party package ecosystem - That's fine, I'm not pulling in many 3rd party packages, so those that are pulled in can be handled with the Makefile and manual updates. 5. The modern idiocy of header files - this confuses me; there is still no good alternative to header files to support exporting to a common ABI. Functions, written in C, will be callable from any other language because header files are automatically handled by swig for FFI.[1] 6. Memory bugs + debugging them - thankfully, using valgrind, then sanitisers in my build/test step makes this a very low priority for me. Not that bugs don't slip through, but single-exit error handling using goto's and cleanups make these kinds of bugs rare. Not impossible, but rare. Having the test steps include valgrind, then various sanitisers reduces the odds even more. For the rest, yeah, nice to have "No built in string, list or map types. No generics. Nullability. No sum types. No option, tuples or multi returns. ", but those are optional to getting a product out. If C had them I'd use them, but I'm not exactly helpless without them. The downside of writing a product in C, in 2025, isn't in your list above. ======================================== [1] One of my two main reasons for switching to C is because the product was so useful to paying clients that they'd like more functionality, which includes "use their language of choice to interact with the product.". Thus far I've hacked in solutions depending on which client wanted what, but there's limits to the hacked-in solutions. IOW, "easily extendable by clients using their language of choice" is a hard product requirement. If it wasn't a hard requirement they can continue using the existing product.
  - lmm 11mo ago
    > I've few qualms about writing the server in C. Why are you not worried about becoming the next Cloudbleed? Do you believe you have superhuman programming abilities?
    - lelanthran 11mo ago
      > Why are you not worried about becoming the next Cloudbleed? The odds are just too low. > Do you believe you have superhuman programming abilities? I do not believe I have superhuman abilities.
- sramsay 11mo ago
  I keep hearing this, but I fail to see why "the massive, well-maintained set of critical libraries upon which UNIX is based" is not a good reason to use C in 2025. I have never seen a language with a better ffi into C than C.
  - lmm 11mo ago
    > the massive, well-maintained set of critical libraries upon which UNIX is based What massive, maintained set is that? Base Unix is tiny, and any serious programming ecosystem has good alternatives for all of it.
- jstimpfle 11mo ago
  Productivity, portability, stability, mind-share, direct access to OS APIs... there's a lot of reasons to still use C.
  - pjmlp 11mo ago
    Only if the OS is written in C, and has its APIs exposed as C APIs to userspace. Quite a few OSes don't fit that rule.
    - mbac32768 11mo ago
      Could you name two of these that are important to you?
      - cryptonector 11mo ago
        Or even one. I know there are operating systems in use that are not written in C, but the major ones are written in C. And anyways, it's not just the OS. There's a pile of C code. Fil-C is a fantastic idea. I think Fil is going to make it good enough to use in production, and I badly want to use it in production.
      - pjmlp 11mo ago
        Android, userspace is Java, and what is exposed on the NDK is a tiny portion, as it is only meant for games and implementing native methods for better performance beyond what JIT/AOT do, or bindings to existing libraries. About 80% of the OS APIs are behind JNI calls, when using the NDK. iOS, iPadOS, watchOS, the large majority of userspace APIs is based on Objective-C, or Swift, bare bones C is only available for the POSIX leftovers. You need to call the Objective-C runtime APIs for anything useful as an app that Apple would approve. For the Plan 9 geeks, Inferno, OS APIs are exposed via Limbo. For folks that still find mainframes and micros cool, IBM i, IBM z/OS, Unisys ClearPath MCP, Unisys OS 2200. For retrogaming folks, most 8 and 16 bit home computers.
jvanderbot 11mo ago
I think these threads attract people like that, but also people that want to be like that. I've seen a lot of people do "rigor theater", where things like reproduce-able builds, garbage collection, or, frankly, memory safety are just thought terminating cliches.

KerrAvon 11mo ago

Outside of hobbyist things, performance-critical code is the only responsible use case for a non-memory safe language like C in 2025, so of course it does. (Even that window is rapidly closing, though; languages like Rust and Swift can be better than C for perf-critical things because of the immutability guarantees.)

lelanthran 11mo ago
> Outside of hobbyist things, performance-critical code is the only responsible use case for a non-memory safe language like C in 2025, so of course it does. Maybe; I sometimes write non-hobbyist non-performance-critical code in C. I'm actually planning a new product for 2026 that might be done in C (the current iteration of that product line is in Go, the previous iteration was in Python). I've few qualms about writing the server in C.
- josephg 11mo ago
  > I've few qualms about writing the server in C. Bad Unicode support. Lack of cross platform system libraries. Needing to deal with CMake / autotools / whatever. Poor error handling. No built in string, list or map types. No generics. Nullability. No sum types. No option, tuples or multi returns. Generally worse IDE support than a lot of languages. No good 3rd party package ecosystem. The modern idiocy of header files. Memory bugs. Debugging memory corruption bugs. … I mean, yeah other than all those problems, C is a great little language.
  - lelanthran 11mo ago
    > Bad Unicode support. Lack of cross platform system libraries. Needing to deal with CMake / autotools / whatever. Poor error handling. No built in string, list or map types. No generics. Nullability. No sum types. No option, tuples or multi returns. Generally worse IDE support than a lot of languages. No good 3rd party package ecosystem. The modern idiocy of header files. Memory bugs. Debugging memory corruption bugs. … You make some good, if oft-repeated, points; but for my product: 1. Bad Unicode support - I'm not sure what I will use this for; glyphs won't be handled by a server program and storage/search of UTF8/codepoints will be handled by the data store (PostgreSQL, if you must know). 2. CMake/autotools/etc - low list of 3rd party dependencies, so a plain Makefile works. 3. Worse IDE support than a lot of languages - not sure what you mean by this. C has LSP support, like every other language. I haven't noticed C support in editors to be worse than other languages. 4. No 3rd party package ecosystem - That's fine, I'm not pulling in many 3rd party packages, so those that are pulled in can be handled with the Makefile and manual updates. 5. The modern idiocy of header files - this confuses me; there is still no good alternative to header files to support exporting to a common ABI. Functions, written in C, will be callable from any other language because header files are automatically handled by swig for FFI.[1] 6. Memory bugs + debugging them - thankfully, using valgrind, then sanitisers in my build/test step makes this a very low priority for me. Not that bugs don't slip through, but single-exit error handling using goto's and cleanups make these kinds of bugs rare. Not impossible, but rare. Having the test steps include valgrind, then various sanitisers reduces the odds even more. For the rest, yeah, nice to have "No built in string, list or map types. No generics. Nullability. No sum types. No option, tuples or multi returns. ", but those are optional to getting a product out. If C had them I'd use them, but I'm not exactly helpless without them. The downside of writing a product in C, in 2025, isn't in your list above. ======================================== [1] One of my two main reasons for switching to C is because the product was so useful to paying clients that they'd like more functionality, which includes "use their language of choice to interact with the product.". Thus far I've hacked in solutions depending on which client wanted what, but there's limits to the hacked-in solutions. IOW, "easily extendable by clients using their language of choice" is a hard product requirement. If it wasn't a hard requirement they can continue using the existing product.
- lmm 11mo ago
  > I've few qualms about writing the server in C. Why are you not worried about becoming the next Cloudbleed? Do you believe you have superhuman programming abilities?
  - lelanthran 11mo ago
    > Why are you not worried about becoming the next Cloudbleed? The odds are just too low. > Do you believe you have superhuman programming abilities? I do not believe I have superhuman abilities.
sramsay 11mo ago
I keep hearing this, but I fail to see why "the massive, well-maintained set of critical libraries upon which UNIX is based" is not a good reason to use C in 2025. I have never seen a language with a better ffi into C than C.
- lmm 11mo ago
  > the massive, well-maintained set of critical libraries upon which UNIX is based What massive, maintained set is that? Base Unix is tiny, and any serious programming ecosystem has good alternatives for all of it.
jstimpfle 11mo ago
Productivity, portability, stability, mind-share, direct access to OS APIs... there's a lot of reasons to still use C.
- pjmlp 11mo ago
  Only if the OS is written in C, and has its APIs exposed as C APIs to userspace. Quite a few OSes don't fit that rule.
  - mbac32768 11mo ago
    Could you name two of these that are important to you?
    - cryptonector 11mo ago
      Or even one. I know there are operating systems in use that are not written in C, but the major ones are written in C. And anyways, it's not just the OS. There's a pile of C code. Fil-C is a fantastic idea. I think Fil is going to make it good enough to use in production, and I badly want to use it in production.
    - pjmlp 11mo ago
      Android, userspace is Java, and what is exposed on the NDK is a tiny portion, as it is only meant for games and implementing native methods for better performance beyond what JIT/AOT do, or bindings to existing libraries. About 80% of the OS APIs are behind JNI calls, when using the NDK. iOS, iPadOS, watchOS, the large majority of userspace APIs is based on Objective-C, or Swift, bare bones C is only available for the POSIX leftovers. You need to call the Objective-C runtime APIs for anything useful as an app that Apple would approve. For the Plan 9 geeks, Inferno, OS APIs are exposed via Limbo. For folks that still find mainframes and micros cool, IBM i, IBM z/OS, Unisys ClearPath MCP, Unisys OS 2200. For retrogaming folks, most 8 and 16 bit home computers.

jvanderbot 11mo ago

I think these threads attract people like that, but also people that want to be like that. I've seen a lot of people do "rigor theater", where things like reproduce-able builds, garbage collection, or, frankly, memory safety are just thought terminating cliches.