Live data from Hacker News

Two types of C programmers

utcc.utoronto.ca

91–100 of 225 posts

Re: Two types of C programmers

#91

I'm the former kind: I choose C because I like it above all else. [1] That said, like the author, I'm trying to find an alternative. Well, more like I'm building my alternative because I hate Go. And Rust. And anything else. I don't know why C fits my brain, but it does. I think it's because my brain is low-level; I like messing with assembler when I get the chance to optimize. [1]: https://gavinhoward.com/2023/02/wh…

it's not possible for human beings to write correct C code, measured over time

this is not a controversial statement, it's the clear conclusion from any evaluation of available evidence

it's fine that you like messing with assembler, but you can't do that safely -- if the programs you write don't need to be correct then carry on, but if they do need to be correct, then you have a professional obligation to use a higher-level language, with stronger guarantees

edit:

> This brings me to my next reason: I have the discipline to write C at a high level.

factually, you do not. nobody does. you think you do, until you don't. human cognition is insufficient to satisfy this requirement. "discipline" does not fix the problem.

Re: Two types of C programmers

#92
I don't get enjoying every second line being "if (r == -1) goto cleanup" and then a cleanup block freeing every pointer which is not null. True, you can define macros to automate that, but then you just end up with clunkier version of C++ destructors. The rest depends on what you are doing, no need for heavy OOP for simple tasks and on the other hand automatic memory management is great when reliability is more important than hardware access or real time performance. But at least no reason to avoid automated facilities that replace well known red tape.

Re: Two types of C programmers

#93

I'm the former kind: I choose C because I like it above all else. [1] That said, like the author, I'm trying to find an alternative. Well, more like I'm building my alternative because I hate Go. And Rust. And anything else. I don't know why C fits my brain, but it does. I think it's because my brain is low-level; I like messing with assembler when I get the chance to optimize. [1]: https://gavinhoward.com/2023/02/wh…

What type of projects do you work on?

Re: Two types of C programmers

#94
post #5

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…

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

C is not aligned with modern hardware and optimizing compilers are severely hampered by things like undeclared pointer aliasing.

Re: Two types of C programmers

#95

I'm the former kind: I choose C because I like it above all else. [1] That said, like the author, I'm trying to find an alternative. Well, more like I'm building my alternative because I hate Go. And Rust. And anything else. I don't know why C fits my brain, but it does. I think it's because my brain is low-level; I like messing with assembler when I get the chance to optimize. [1]: https://gavinhoward.com/2023/02/wh…

it's not possible for human beings to write correct C code, measured over time this is not a controversial statement, it's the clear conclusion from any evaluation of available evidence it's fine that you like messing with assembler, but you can't do that safely -- if the programs you write don't need to be correct then carry on, but if they do need to be correct, then you have a professional obligation to use a high…

Oh wow, someone should alert the Linux kernel maintainers. Do you want to tell them that it’s impossible to write correct C code? And the rust compiler team, too. After all, if nobody can write safe assembly then whatever they’re doing is either unsafe or magically gets the computer to understand rust directly. Or are they relying on LLVM for their code generation? I forget what language that’s written in, but nothing “unsafe” happens there surely.

All code is machine code at bottom. Including the code that maintains abstractions convincing enough for you to think the “memory-safety” of rust or any other language is a static and guaranteed thing and not something that needs “unsafe” scaffolding to support it.

Re: Two types of C programmers

#96

C with libdispatch and clang blocks is the most fun I’ve had programming in quite some time! Here’s a web framework (complete with ORM) modeled on ExpressJS written in C: https://github.com/williamcotton/express-c The finished product is There’s also a lot of examples of the (basically required) support tooling like Valgrind, AdSan, etc. Check it out!

this project makes assumptions about received input (specifically encoding) which aren't guaranteed

fine for a toy project, not something that can be used in anger

Re: Two types of C programmers

#98
C programmers are implicitly converted to the required type.

Implicit conversions are one thing I don't like about C, or at least the way it ended up as int grew (maybe it would have been better if ANSI had picked unsigned-preserving, but maybe that's just grass-is-greener thinking). I also don't like how UB turned into “a license for the compiler to undertake aggressive optimizations that are completely legal by the committee's rules, but make hash of apparently safe programs.”

I do like the directness and explicitness. Good C can be very nice.

Re: Two types of C programmers

#99
post #32

C with libdispatch and clang blocks is the most fun I’ve had programming in quite some time! Here’s a web framework (complete with ORM) modeled on ExpressJS written in C: https://github.com/williamcotton/express-c The finished product is There’s also a lot of examples of the (basically required) support tooling like Valgrind, AdSan, etc. Check it out!

It looks cool. The DB library is appreciated. However, you would get about the same idle memory and docker size with Go's Fibers framework :)

go-fiber is a weird, non-idiomatic, and non-serious project, fine for a proof of concept, but definitely not something anyone should be using in prod

but your point is sound, any reasonable go http server will have the same level of memory usage at idle

Re: Two types of C programmers

#100

I'm the former kind: I choose C because I like it above all else. [1] That said, like the author, I'm trying to find an alternative. Well, more like I'm building my alternative because I hate Go. And Rust. And anything else. I don't know why C fits my brain, but it does. I think it's because my brain is low-level; I like messing with assembler when I get the chance to optimize. [1]: https://gavinhoward.com/2023/02/wh…

it's not possible for human beings to write correct C code, measured over time this is not a controversial statement, it's the clear conclusion from any evaluation of available evidence it's fine that you like messing with assembler, but you can't do that safely -- if the programs you write don't need to be correct then carry on, but if they do need to be correct, then you have a professional obligation to use a high…

> it's not possible for human beings to write correct C code, measured over time

I don't disagree [1], but remember that Rust can be unsafe too. Async is not a panacea, and it's confusing. And the `unsafe` escape hatch is still unsafe.

> you have a professional obligation to use a higher-level language, with stronger guarantees

Oh? So we have professional obligations now? For FOSS? News to me.

I don't get paid for my work. Not yet. So I have no obligation.

And when I do get paid, my code will be in my own safe language.

This accusatory response is exactly the kind of thing that puts a lot of people off Rust.

> factually, you do not. nobody does.

When I say "write C at a high level," I don't mean that I'm perfect. I mean that I write excellent C compared to all C programmers out there.

Engineering is not about perfection; it never was. It's about doing the best we can with the tools that we have.

[1]: https://git.gavinhoward.com/gavin/bc/src/branch/master/MEMOR...

Post reply on HN