Hacker News Reader

Comment by userbinator | Hacker News Reader

Controversial opinion, somewhat philosophical: I use C because I still believe in freedom, and I think you should too.

If we gradually destroy all semblance of individual thought and discretion and replace that with something that essentially approaches rule-by-machine, what remains is not far from an authoritarian dystopia in societal terms. Even more so when you realise the direction Big Tech is taking. Jailbreaking and rooting are an escape hatch that they're certainly trying to close with all the "memory safety" stuff.

C also has an advantage of being simple enough that a single person can write a compiler for a nearly full subset of it. The same can't be said of many other languages.

I'm not saying I can write 100% correct code, although I certainly try (and IMHO it's not too difficult to get close.)

"Freedom is not worth having if it does not include the freedom to make mistakes."

"The road to hell is paved with good intentions."

View on HN

I think equating a compiler that stops you from making runtime mistakes to authoritarian social dystopia is ungrounded, baseless and frankly dumb. My idea of freedom is not wasting my life debugging null ref errors on weekends because somebody else wants the freedom to do bad ideas.

to me the assertion has merit from the point of view that being able to understand what your application does completely is much easier in a small language like C or lisp/scheme, which i believe is essential to maintaining the proper master -> tool relationship with the computer. it seems straigh forward to me that if you use things you dont understand it is likely you will open your application to all sorts of potential unexpected behaviour

Having worked on C and C++ compilers for a few years at this point: I would say that there’s a strong negative correlation between claiming that C is a simple language and actually understanding C, as specified.

C is actually a fantastically complicated language, both syntactically and at the semantic and abstract machine level.

while i said its small, not simple, i do not think it is controversial to say that c is simplER than rust if what you aim for is a complete understanding of your aplication

I think that is controversial: Rust has more complex syntax than C does, but has a substantially simpler semantic model. Just a small example: given just `T*`, neither you nor your compiler knows what your global aliasing set is. The compiler has to do significantly more work to prove exclusive ownership (necessary for many optimizations), and you have no formal guarantee that your data doesn’t change underneath you.

> Rust has more complex syntax than C does, but has a substantially simpler semantic model

i am not sure i understand, are you saying that c and rust have the same semantics ?

They’re comparable, as evidenced by both being representable within existing compiler IRs. But no, I said that C’s semantics are significantly more complex.

my view of c is as an abstraction over assembly. from this perspective i just cannot see that rust provides simpler semantics, unless you are trying to make c do something which you should probably use another language for, like lisp :)

This is what I mean: C is absolutely not a naive abstraction over assembly. The C standard is clear on this: C is defined in terms of an abstract machine, which in turn doesn’t cleanly map to any particular machine architecture.

Treating C like a “high level assembler” needs a rule like the cryptographic doom principle: it will inevitably lead you astray, and “astray” for C generally means memory unsafety.

> Treating C like a “high level assembler” needs a rule like the cryptographic doom principle: it will inevitably lead you astray, and “astray” for C generally means memory unsafety

you are right. however, i think c does a better job at being a model of an abstract machine than rust. if we restrict semantics to that, and the developer accepts that they need more knowledge than just c, i think the semantics are simpler than rust's. in the same way, dont you think that rust can create a false sense of security to those not completely understanding what protections it provides? if we see programming languages as a hci problem, then i think c by default offers more freedom, and consequently more unsafety. amyway i dont want to come off as hating rust, i think it is a good language, but more importantly its community seems fantastic and i wish it success

> dont you think that rust can create a false sense of security to those not completely understanding what protections it provides?

No: the entire point of Rust's design is that you don't need to know the abstract machine semantics to write Rust safely. The compiler enforces the semantics for you, rather than pushing them onto you.

C on its own does feel like a simpler language though I think it’s true that the semantics taken literally undermine it (the generated assembly can be really surprising sometimes). I do trust a given Rust program to have a specific runtime behavior much more when optimized. It might be interesting to come up with a variant of C that has genuinely simpler semantics as well (not sure how useful I’d find it though)

It’s a common argument that a more simple language makes for more understandable code, yet practical programming tells a different story. From web browsers to every major C compiler, C++ is the language of choice. Similarly for GUI frameworks, GPGPU programming, etc. So what is it? Are we supposed to believe the, frankly pompous, notion that those developers/firms/institutions/etc were tricked? No, I think not.

If we are being honest with ourselves the truth is that even a language as nightmarishly complex as C++ is preferable to C. And whether or not you agree with that the fact is that the world marches on regardless.

Rust is a defined space. It doesn't restrict your freedom of thought or speech on your personal GitHub, you can use C or brainfuck there just fine.

Rust just says "This is an engineering project, not a philosophy paper, or science lab. It is not the time or place for experimentation, new ideas, and individual discretion, or for trusting each other or ourselves, we want reliability at all costs".

Which is exactly the attitude I want to see, when failure means I lose important notes, money, or get lost because GPS crashed, or my battery runs down because everyone was too afraid to optimize their brittle bug heaps, or a self driving car murders me, or we return to 1970s level tech due to nobody trusting software.

You can absolutely code in Rust for fun or experimentation. There's absolutely room for new ideas and individual expression in Rust. It's not a straight jacket. It's like you and the compiler are pair programming together; it's a collaborator, not a task master.

> Rust just says "This is an engineering project, not a philosophy paper, or science lab. It is not the time or place for experimentation, new ideas, and individual discretion, or for trusting each other or ourselves, we want reliability at all costs".

I'm rather fascinated that you put this in these terms, because I've seen the exact opposite (specifically the philosophy paper). The few times I've seen rust tried out, it seemed to turn into a competition between devs about how clever they could be with category theory. Then an abstraction stack grows until logic errors creep in because nobody understands what the thing is actually doing anymore.

I don't want to blame rust specifically for this, because the same thing happened with scala. Not sure what it is, possibly just a lack of dev discipline. I can't help but view this category of languages (rust, scala, haskell, etc) as competitive philosophy because I have to spend several hours sitting around pondering the nature of things before I can make minor changes from my jira ticket.

End result ends up being that someone usually re-writes an "interim" solution in java/go/etc, over a couple of sprints and then nobody ever gets back to the long term solution written in the elegant language because they don't have time to understand it.

As a counterpoint, I wrote an "interim solution" in Rust in a few weeks that ended up replacing both the python and C++ versions that had been months in the making. I suspect the difference might be more about the skill and pragmatism of the developers involved than the languages used. Heavily functional code is not consisdered idiomatic in Rust.

> might be more about the skill and pragmatism

They're all plenty skilled, but I'll give you the pragmatism one. A certain style of dev seems to have a compulsion to violate Kernighan's Law.

Eventually that abstraction hierarchy collapses on itself. I don't want to pin this purely on rust either, since I've seen it in plenty of languages (including java), but I see it happen often enough that I'm reluctant to trust my co-workers with rust at this point.

Or maybe they all can and I'll retreat into my little abstraction-minimal kingdom where the code's not very elegant, but I can figure it out, and I can onboard people in less than a month.

I feel like this is trying to solve an ethics issue using technology. It would seem more appropriate to fight for freedom by joining or supporting the people who already fight for it, than sitting and thinking by using C one helps the world in that regard.

I’ve seen you post a variant of this comment on multiple Rust-adjacent threads, and I still don’t understand it: Rust was by no means the first “safe” language, it wasn’t the one pushed by Big Tech (that’s Go, another good language!), and there’s no particular evidence that preventing jailbreaks is the actual, secret intention here. That last part borders on conspiracy, given that engineers are overwhelmingly anti-DRM and pro-modification.

given that engineers are overwhelmingly anti-DRM and pro-modification.

If they were, things wouldn't be the way they are today. Perhaps you're saying that they are, but can only express that position in the form of subtle exploits (which seem to be decreasing over time)? No, I think the majority of engineers are overwhelmingly complacent and obedient, and won't oppose.

As for why Rust, that's because the amount of prosletysing of that language seems to be far more than all the others.

> Controversial opinion, somewhat philosophical: I use C because I still believe in freedom, and I think you should too.

Rustacean Abraham Lincoln might quibble on what freedom means in this context: https://news.ycombinator.com/item?id=34620164

Dont mind the downvotes, I somewhat agree with you with the the lack of freedom argument (although not quite sure about the larger context around dystopia).

To put it in other words, I want my tools to do whatever I want them to do and not the other way around.

I want my tools to do whatever I meant to write. If I made what I consider a mistake, I want a tool to point it out. And I want memory safety, because without that, terrible things can happen that nobody ever wrote.

pointing mistakes is the job of the linter, the job of the compiler is to run my program asap and even try to fix my mistakes automatically. There is nothing more pedantic than a compiler saying "Oh you shouldnt do this as it can potentially be a race condition"

“If the government takes away my AR-15, dystopia is next!”, systems programmer edition.

>> Controversial opinion, somewhat philosophical: I use C because I still believe in freedom, and I think you should too.

>> "Freedom is not worth having if it does not include the freedom to make mistakes."

>> "The road to hell is paved with good intentions."

Having a smarter compiler that prevents errors does not reduce individual thought or hinder creativity.

It incorporates best practices and discipline that should be followed anyway into the creative process to prevent errors at the source.

"Freedom isn't free."

"The price of freedom is eternal vigilance."

"The same can't be said of many other languages"

except... Forth or Pascal, perhaps?

Maybe it's controversial if I understood what the hell it means. Freedom? Destroy all semblance of individual thought? Authoritarian dystopia? ...

Am I dreaming?

The ability to write your own compiler for a language... that's related to the above?

If rules and structure and grammar are so bad, why is your comment written in readable English? D0lt.

.i lorovi prenu cu na tavla bau la lojban

Is there no semblance of individual thought in C++? No discretion in Python? Are you ruled-by-machine if you use Go? Is using Javascript an authoritarian dystopia?

Apparently the road to hell is paved with vague slogans...

I don't agree with the grandparent post but can offer an interpretation of what they mean. Languages like Go, Rust, Java, etc. are enormous and are designed and managed by a committee. Sometimes, they go in a direction that you might not like. For example, many people were pissed off by the compatibility break between Python 2 and 3. If you find yourself disagreeing with the designers' decisions, you have very little recourse but to stick with an old version of the language/tooling while the rest of the world moves forward, because you are in no position to understand and maintain a huge language implementation codebase. The grandparent is implying that C is so simple that if you disagree with the direction of the official C language and major compiler vendors, you can simply write fork the language and reasonably your own compiler. But of course, I would say that you have the freedom to reinvent the same bugs over and over again, that the committee was trying to proactively solve for you.

Reply on news.ycombinator.com