23 ms·

I use C when I believe in memory safety

• nequo 4y ago
  Great write-up on the author's personal perspective. This part in particular I think is a good summary of why this works for him: The next reason is that during my time with C, I have developed a custom software stack designed around memory safety. [...] In other words, I am not using C; I am actually using the partially memory-safe Gavin D. Howard dialect of C. In other words, don't try this at home? I definitely should not try it at home.
  • deleted 4y ago
    [deleted]
  • oconnor663 4y ago
    Bryan Cantrill making a similar "I Work Alone" point: https://youtu.be/HgtRAbE1nBM?t=2359 https://youtu.be/HgtRAbE1nBM?t=2359 > I can write C that frees memory properly...that basically doesn't suffer from memory corruption...I can do that, because I'm controlling heaven and earth in my software. It makes it very hard to compose software. Because even if you and I both know how to write memory safe C, it's very hard for us to have an interface boundary where we can agree about who does what.
    • nequo 4y ago
      What a clear way to describe the difficulty with manual memory management. So like Lisp, C might end up being a solo programmer’s tool too. But not because it is a breeding ground for DSLs but because everyone is adhering to different conventions in the absence of the compiler enforcing one.
      • menaerus 4y ago
        I don't think that the composability/interface-boundary/memory-mgmt argument stands for C and much even less so for C++. There's nothing difficult about it nor ambiguous.
        • bcantrill 4y ago
          Did you actually watch the linked presentation? If so, I would be curious in an earnest rebuttal: I very much stand by my conclusions -- and even more so after having spent the years since on Rust-based systems and C/Rust hybrids. Specifically, I have not seen a BTree implementation in C that I would consider to be composable; can you point me to one?
          • menaerus 4y ago
            I did not watch the presentation, sorry. Depends what the definition of composability you have in mind so if you share what you mean by "composable BTree" implementation, I would be happy to give my opinion. I ask because there's no much I can see about the composability of a b-tree implementation other than supporting multiple types, and this is certainly doable although not as elegant as in C++.
            • bcantrill 4y ago
              While I appreciate your candor, you may want to know what argument, exactly, you are putatively refuting? (Specifically: the argument is not about types -- it's about ownership.) If it's not too much to ask, take two minutes to watch the linked clip. As for the composable BTree implementation, I actually am not asking for your opinion -- I'm asking for a link to the implementation itself. The details here matter (and indeed, that's the whole point).
              • menaerus 4y ago
                I watched the video now and it is literally what one of the parent comments paraphrased and what I was responding to. What you said is: > I can write C that frees memory properly...that basically doesn't suffer from memory corruption...I can do that, because I'm controlling heaven and earth in my software. It makes it very hard to compose software. Because even if you and I both know how to write memory safe C, it's very hard for us to have an interface boundary where we can agree about who does what. And I stand by my point. Single-responsibility principle will get you covered, yes, even in C. > I actually am not asking for your opinion -- You could show some respect. > I'm asking for a link to the implementation itself. The details here matter B-tree btw is a silly example which particularly is not among the hard design problems out there and there are dozens of implementations laying around. Obvious examples to look for would be in transactional database systems implemented in C. > (and indeed, that's the whole point). ... and the point not being quite clear, even after politely asking for a clarification, so perhaps next time you don't try to play the authority but try to provide an actual example to support your otherwise questionable claim. I'm sure Rust community will profit from individuals like yourself.
      • bstpierre 4y ago
        I’ve only played around with lisp a little bit, what about it makes it a solo programmer tool?
        • nequo 4y ago
          I saw it expressed by multiple people whose language of choice was Lisp but the only one that I specifically remember is Ron Garret’s recent post called Lisping at JPL Revisited[1]: All this is a reflection of the so-called Lisp curse, the fundamental problem with Lisp -- its great strength is simultaneously its great weakness. It is super-simple to customize Lisp to suit your personal tastes, and so everyone does, and so you end up with a fragmented ecosystem of little sub-languages, not all of which (to put it mildly) are particularly well designed. He doesn’t specifically say here though that this makes Lisp a solo tool. I can’t find a source for that right now unfortunately. [1] http://blog.rongarret.info/2023/01/lisping-at-jpl-revisited.html http://blog.rongarret.info/2023/01/lisping-at-jpl-revisited....
        • tmtvl 4y ago
          Lisp is the most powerful and elegant language. That is a problem because you're giving weak, fallible monkeys phenomenal cosmic powers. Now, many monkeys are well-behaved and disciplined, so they create reasonable, pleasant codebases. But some monkeys go bananas.
        • kazinator 4y ago
          Mainly, the online opinions of people who have no Lisp experience, solo or collaborative, but have read something to that effect somewhere.
  • habibur 4y ago
    I see this as positive. Giving you a large array possibilities and choices.
  • TheLoafOfBread 4y ago
    I agree, don't try this at home, try this at work.
• Ombudsman 4y ago
  TLDR: Author just likes C
  • rapsey 4y ago
    Same as with any other c/c++ stalwart.
  • deleted 4y ago
    [deleted]
  • mrweasel 4y ago
    Which is fair. The author also highlights an interesting problem: Some of us will opt to not use Rust, even when we should, simply because the language doesn't appeal to us. I love the idea of Rust, but find the syntax to be just awful, and the entire thing just overly complex. I'm not saying that Rust isn't the way it is for good reasons, but the code is often hard to read. Some of the syntax choices are in my mind questionable and serves only to have Rust programmer appear smarter than the rest of us. Rust shouldn't try to accommodate people like me, because it will make everything worse for everyone. Instead I should look elsewhere, may not to C, I'm not that clever, but to languages like Go, Nim, Crystal or Hare. It's important that we have choices, because even the best designed language, and I do consider Rust a well designed language, will fail to appeal to everyone.
    • t43562 4y ago
      The language is just an interface between humans and the machine to make it easier for us humans - machines aren't all the same so why should humans be?
    • azubinski 4y ago
      "Some of us will opt to not use Rust, even when we should" Nobody SHOULD use Rust. Some may use it, but nobody should. And because of this "should" many will not use it, especially when you consider that the language is conceptually overweight and there was already one "very popular" conceptually overweight Scala language, which now only the old people remember (laughs).
• mlindner 4y ago
  The "Rust Evangelism Strike Force" isn't actually a thing that exists. From my understanding the term was created as a self-deprecating meme by some Rust users to describe other Rust users. It's not a core policy and basically all serious Rust users don't do any of the alleged activities claimed to happen. They're too busy actually writing software.
  • yjftsjthsd-h 4y ago
    Er, it's not a formal thing, but it's absolutely an emergent phenomenon that exists. Every single discussion on HN about either software vulnerabilities or C will have comments asserting that everything must be rewritten in rust. I would believe that it's not from "serious Rust users", but someone will show up to say it.
    • Ygg2 4y ago
      It exists in same way every C developer is a sweaty greybeard. It's a meme.
  • deleted 4y ago
    [deleted]
    • deleted 4y ago
      [deleted]
  • simplotek 4y ago
    > The "Rust Evangelism Strike Force" isn't actually a thing that exists. (...) It's not a core policy and basically all serious Rust users don't do any of the alleged activities claimed to happen. If that was remotely true how do you explain the Actix episode?
    • mlindner 4y ago
      Some over zealous Redditors doing Redditor things. That's where it started anyway. There was no coordinated effort. Probably some people from 4chan as well.
• kstenerud 4y ago
  Therein lies hubris. I like C as well, but I never kid myself into thinking that discipline and documentation can replace compiler restrictions. I've written large codebases in C, sometimes alone, sometimes in a team, and despite DECADES of experience and meticulous attention to detail, I STILL find the same old memory errors in my own code. C cannot be made safe because you are not a god.
  • throwawaymaths 4y ago
    > C cannot be made safe because you are not a god I mean this is demonstrably untrue: SEL4 is written by mere mortals, in C. It's safer than rust, there are formally verified security guarantees that include and go beyond the memory safety of rust. It is the case though that c is an incredibly shitty language to do this sort of static analysis on because for example it's easy to do shenanigans like lexical macros that make the static analyzers job much much harder.
    • vore 4y ago
      seL4 also has the whole Isabelle/HOL theorem prover to verify its properties, so it's not quite right to claim it's written in C. If you can claim seL4 is "written in C", you could equally claim that if the Rust compiler emitted C, you're writing a C program -- after all, a static type checker is just a shittier theorem prover.
      • throwawaymaths 4y ago
        This is like saying <insert language with docstrings> is not actually writing in <lang> because you need whatever engine's target language (md, XML, whatever) to compile the docs.
        • avgcorrection 4y ago
          That comparison is nonsensical and you know it. You can delete all the comments and have the same guarantees about what the code does (none). You can’t write a kernel without some formal verification tool and then claim that it adheres to the specification.
• lenkite 4y ago
  That stack allocator lib sounds sweet. Is it open source by any chance ?
  • signa11 4y ago
    here is an example of one from howard-hinnant: http://howardhinnant.github.io/stack_alloc.html http://howardhinnant.github.io/stack_alloc.html
  • gavinhoward 4y ago
    Author here. It's in my current project at https://git.yzena.com/Yzena/Yc https://git.yzena.com/Yzena/Yc . Code is at https://git.yzena.com/Yzena/Yc/src/branch/master/src/alloc/stackpool.c https://git.yzena.com/Yzena/Yc/src/branch/master/src/alloc/s... , and header is at https://git.yzena.com/Yzena/Yc/src/branch/master/include/yc/stackpool.h https://git.yzena.com/Yzena/Yc/src/branch/master/include/yc/... .
    • torstenvl 4y ago
      Yikes. I do not think you have thought through the implications of licensing (or purporting to license) under the union of three contradictory licenses. I didn't read anything past that, because this is very much a "only way to win is not to play" kind of situation.
      • gavinhoward 4y ago
        That's on purpose. At least for now. Once my own licenses have been looked at and adjusted by a lawyer, I'm going to drop the other two. Until that point, the other two licenses are meant to make my code radioactive. This is so I have breathing space as I work on the code. And because I own the copyright on most of that code free and clear, I am well within my rights to license the code under all three.
• burnished 4y ago
  Title and content dont really match do they? The article itself is basically this guys journey with C and the steps he takes to get something other languages now build in - ironically I think it was a stronger argument to write everything in Rust than any 'rust evangelism strike force' has put together. Neat article, always interesting to take a peak at some ones highly idiosyncratic process.
  • raverbashing 4y ago
    Yeah true. "Oh he only finds C fun to work with" sorry, that sounds like maybe Stockholm Syndrome or maybe unchecked perfectionism > "The next reason is that during my time with C, I have developed a custom software stack designed around memory safety." Oh ok then. Again goes to show how C is deficient in some areas I get something being fun, but C ends up needing to worry about a lot of details where you could be actually improving the code in other languages
    • simonh 4y ago
      Finding things fun = Stockholm syndrome? I don't think so. it just means there are other aspects of the language that make up for the deficiencies. Also if he already has a framework that solves that problem for him, then it's not deficient in that areas, for him, right?
      • throwbadubadu 4y ago
        Yes, like enjoying wood work == stockholm syndrome, why not go to Ikea?? Also to gp, title perfectly matches, pointing out why he believes in memory safety when using C, everytime also pointing out the flaws with his thinking, and why this only applies to him in his completely owned projects. Not sure what's wrong with the critics here.
    • t43562 4y ago
      C is fun - there's elegance in writing good C code and the mental model you need to understand it is much simpler than the higher level languages. It's also fun to write data-structures yourself instead of being a mere user all the time. In C you can tell yourself that your take on how to do datastructures is worthwhile and unique (might be a slight stretch) but in other languages almost anything you can do is redundant.
• Liberonostrud 4y ago
  Why is it posted here? He is using some custom made tools to find his bugs. No, thank you. Will stay with Rust.
  • flohofwoe 4y ago
    What is the Rust compiler other than a "custom made tool" though ;)
• antirez 4y ago
  I have a similar issue. I like the memory safety in Rust, but I don't like Rust: it limits my productivity for two reasons. 1. In order to reach memory safety it add abstractions that don't make programming simpler, but harder. 2. It is a language that started to enter the slippery slope of too many ad-hoc features. And given that I work alone, I try to write safe C code as much as I can (it is impossible to reach perfection, anyway), and avoid Rust as much as I can. What I will do more, however, is using more other safe languages when the C low-level control is not needed. Go is a good option, for my tastes. P.S. I see in realtime, reloading the post, the number of downvotes received (the score goes up and then ways down with the downvotes). Another problem is the Rust community. It has a very peculiar way to stay in this world.
  • rapsey 4y ago
    What slippery slope exactly?
    • simonh 4y ago
      I suppose once you have accepted ad-hoc features, you don't have a strong argument against adding more of them.
      • rapsey 4y ago
        Not becoming c++ is a strong argument
    • antirez 4y ago
      One is a cultural matter: A design idea that no longer actively attempts to produce a language with few orthogonal features that work well together. The second is a side-effect: the more features you have in a language, the more complex new features will be to accomodate all the past cases.
  • rapsey 4y ago
    Also nothing prevents you from using Rust without higher abstractions.
• t43562 4y ago
  I understand why the OP likes C. I was looking at a couple of old projects of mine and I remember the satisfaction at least in one (a SASL library) of how I made various classes of error impossible using a fairly simple strategy and my own string handling routines. In a memory safe language with lots of assistance for threading there would never have been that pleasure. It was not amazing or anything but it was elegant to my eyes. I feel I have to develop an economy of effort in C because there usually isn't a dumb and easy way to do things - this pleases me. C has a mental model that seems relatively simple - I feel I can reason about what's going to happen to a greater degree than higher level languages. C++ is the worst IMO because it has lots of abstractions but they don't make programming simpler because you pretty well have to understand the low level aspect of what they're doing to get performance - so the complexity is much greater. Rust seems to put a lot of difficulty up front which is of no value in the kind of typical short program I write most of the time. I just didn't enjoy it. If I had something complicated to do I might eventually appreciate it. The more high-level the language the less one tends to understand it and that's unsatisfying. Having said all of that though, I tend to "just write python" whenever I can. If it's a throwaway program one doesn't need more and if it turns out to be necessary to interface to some library or other I know C well enough to sort that kind of thing out. I use threading.....never - at least never by choice.
  • atorodius 4y ago
    I have found pleasure in combining „just write python“ with some C compiled code linked in and bridged via numpy for performance critical loop. I just love how fast I can write code in Python for when I do side projects
    • dilawar 4y ago
      You may want to checkout pybind11 library. And checkout NIM lang too.
      • TkTech 4y ago
        Pybind11 has significant overhead that makes it non-viable for some projects, even if it has a nice API. For pysimdjson we switched back to cython for an order of magnitude improvement.
• jokoon 4y ago
  I'm currently making a language that translates directly to C. There won't be pointers, and I think everything will be passed by value. I'm not sure that compilers can optimize this and "move" returned data. But the goal is to greatly limit side effects and improve cache locality by encouraging the coder to use more functional habits instead of oop. There are grey areas because I'm not sure the design is sound, but even if it's not, it can be safe and fast enough.
  • Gigachad 4y ago
    How would you pass an open file by value? What happens when one copy tries to close the file while another still has it open?
    • starbugs 4y ago
      Use a handle and pass that by value?
      • UncleMeat 4y ago
        How do you implement a handle if pointers aren't allowed?
        • starbugs 4y ago
          Call a function that is implemented in C returning you the handle? I didn't say it's a good idea… Isn't that how PHP started off?
      • bruce343434 4y ago
        So a pointer into the file system?
        • starbugs 4y ago
          It’s more like an abstract reference to an opened file.
    • 4y ago
• KaiserPro 4y ago
  > Am I a hypocrite? > Yes, actually, but please hear me out for the rest of the post. I have reasons, I promise. This is the kind of honesty that I live for.
• woodruffw 4y ago
  I also like to program in C; the fundamental error is not programming in C (or liking C), but thinking that you’re special or uniquely able to use C safely. The author adequately defends their predilection for C, which was never doubted; they don’t produce a great argument for why C is good (which, perhaps, they didn’t intend to). Most of the defensive programming techniques covered in the post reflect this: asserts, for example, only catch the bugs you know about.
  • jillesvangurp 4y ago
    Exactly. Objectively, there's no such thing as a disciplined and effective C programmer. Everybody makes mistakes. You can't guarantee that you won't. Believing that you can is in itself dangerous. It's delusional. Experienced programmers know they make mistakes and even anticipate that they will. My attitude these days is "I wonder where I messed up; let's find out!". Basically, like a good scientist, I try to falsify the hypothesis that I messed things up. Only when I start failing to do so, I move on. I make all sorts of silly mistakes. Off by 1 errors, logic errors, inverted conditions, etc. You name it, I do it. There are all sorts of valid arguments for not immediately porting over the huge legacy of C/C++ code bases to something less likely to blow up in your face. However, the amount of valid arguments for starting new code bases in those languages is rapidly declining. I'm sure there are some corners where you just have no other valid choice and that's fine. But increasingly it's just a matter of people being stubborn, rigid, and unwilling. Half the success is just understanding your own limitations and mitigating those. The rest is just dealing with the inevitability of people messing up.
  • gavinhoward 4y ago
    Author here. > they don’t produce a great argument for why C is good (which, perhaps, they didn’t intend to) Never intended to.
• userbinator 4y ago
  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."
  • einpoklum 4y ago
    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...
    • nayuki 4y ago
      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.
  • 4y ago
• francois_h 4y ago
  I laughed a bit when I saw “memory safety” and C in the same sentence. Your program is only as good as the programmer writing the program. Having said that, it just takes one missed check to cause a buffer overflow in C.
• crabbone 4y ago
  The whole bulleted list from "Custom Memory Safety"... this makes me want to run away towards the horizon and scream. In the 90's it was very common that big shops that did some programming would have their own languages, which continued into the 00's in the form of everyone rolling their own C++ standard library. I had the "pleasure" to work with both. Invariably, this stuff was so much worse than off-the-shelf stuff and yet the authors believed themselves to be geniuses. I mean, there's a chance this guy did something outstanding and actually improved something about C, but so far I've seen so many fail to do that in such a predictable patterned way I just don't want to see any more of that. My favorite C code is the one that has no macros, as few of typedefs as possible, no acrobatics with alloca() or any platform-dependent stuff. I think, FIO is a good example of what I'm talking about. The whole thing just sounds like "yeah, it's a swamp, but it's my swamp and I like my swamp!" kind of thing.
  • woodruffw 4y ago
    Well put. Another way to think about it: every major OS and systems vendor has had some custom “safe” C variant over the years, to empirically mediocre results. It's unlikely that this author has done better; it’s much more likely they simply haven’t received the same scrutiny.
    • gavinhoward 4y ago
      Author here. I know this. The only reason the custom stuff works for me is because it works for me. I accept no outside contributions, and this is one reason why.
  • simplotek 4y ago
    > (...) big shops that did some programming would have their own languages, which continued into the 00's in the form of everyone rolling their own C++ standard library. It sounds like you're talking about using libraries as if it was a bad thing. > had the "pleasure" to work with both. Invariably, this stuff was so much worse than off-the-shelf stuff (...) Where do you think "off-the-shelf" stuff comes from? It sounds like you're trying to mistepresent the adoption of subjectively sub-optimal libraries as somehow the issue caused by using libraries and frameworks. > mean, there's a chance this guy did something outstanding and actually improved something about C, but so far I've seen so many fail to do that in such a predictable patterned way I just don't want to see any more of that. You're showing a tremendously naive and misguided belief that libraries are somehow bad. Languages such as Rust flourish with the adoption of third party libraries,some of them euphemistically described as "not stable". Languages such as C++ flourish with third-party components like Boost and POCO. But applying the same principle to a language like C warrants an automatic and mindless putdown like blindly accusing anything of being bad? It makes no sense.
• grashalm 4y ago
  Oh the wonderful luxury of writing code alone. I have not encountered this pleasure in commercial projects so far.
• newpavlov 4y ago
  >This means that I get many of the advantages of Rust Arguably, you don't. The big difference is whether your compiler enforces and tracks your documentation, assumptions used by your code, often critically important for correctness. Unfortunately, Rust is far from being perfect in this regard (e.g. SPARK probably does a better job here), but it significantly improves on C/C++ in this regard. >I Work Alone Unfortunately, even if you are the only soul touching the code, it often quickly becomes false. On a big enough project, "alone" inevitably becomes "me and that guy who wrote this part of the code". This also can be formulated as "me and 2-years-ago-me". In other words, we quickly forget a lot of context used for writing a piece of code. >Rust is too big for my small brain, unfortunately. I think the lack of hubris, the understanding that small human brains are not enough to keep track of all necessary context required for writing correct software is the key element for liking Rust and similar languages. Rust is not about building ivory towers of abstractions for the sake of it (though some people try to walk in this direction), but about offloading as much as possible of the context on compiler. Unlike humans, the compiler does not get tired, it does not forget. Yes, it's limited and because of those limitations it requires to restructure our code and sprinkle it with additional information, but more often than note it's a good thing. As sel4 and other formally verified software demonstrates, it absolutely can be done in C. But one could say that C used in sel4 is not a C language anymore. After all, you can not take a random C library and use it in sel4.
  • thrwawy74 4y ago
    There are 2 things I've obsessed about in C & C++ land: 1) Why are we explicitly directing a loop forward or backward most of the time when it's not necessary. The compiler should direct the loop unless we want to explicitly do this for the body of the loop. My thinking is that there may be performance reasons to reverse a loop or even split it into separate threads. (unlikely) 2) In C++, I've always wondered how template types get instantiated for POD that is represented the same at the bit level. Does the compiler duplicate the templated code or is it smart enough to say "this std::vector<int> is the same as that std::vector<intalias>". Rust prides itself on zero-cost abstractions, I have wondered if they reduce binary bloat in this area. (as a naive C++ person)
• deleted 4y ago
  [deleted]
• kuon 4y ago
  If you need C like memory access (embedded, performance..) I highly suggest zig, which is maturing really fast. We use rust and zig in house for our development and while rust is preferred for complex projects, we prefer zig when we need: super portable code, code that will work with a static memory buffer or datastructre that are hard to use in rust (like self referencing). We still have some chips that requires C because they have proprietary compiler, for those, we are very eager for the zig->C compiler that should be coming some day.
  • KingLancelot 4y ago
    [dead]
  • gavinhoward 4y ago
    Author here. I mentioned that I hate Zig. I've tried it. I do not like it. More power to you, though.
    • kuon 4y ago
      I'm curious, could you elaborate why you do not like it?
      • gavinhoward 4y ago
        There are many reasons. They are personal more than mistakes in Zig. * I don't like how compile-time code can be mixed with runtime code. The idea is nice otherwise, but it confuses me. * I spent a long time trying to understand Zig's async ([1]) and came away with more questions. * I don't like the async model in general; I prefer structured concurrency. I think this is a mistake in Zig. * The Zig community has put me off, though some of that is my own fault. This is just a sample. I've written more other places, but I don't have access or can't remember where right now. [1]: https://gavinhoward.com/2022/04/i-believe-zig-has-function-colors/ https://gavinhoward.com/2022/04/i-believe-zig-has-function-c...
        • kuon 4y ago
• KingLancelot 4y ago
  [dead]
• bayesian_horse 4y ago
  [flagged]
• MrBuddyCasino 4y ago
  [flagged]
  • Kamq 4y ago
    I think that's called the MIT school of design. As opposed to the New Jersey school that produced C/Unix/etc. Generally used along with the term "worse is better": https://en.wikipedia.org/wiki/Worse_is_better#Characteristics https://en.wikipedia.org/wiki/Worse_is_better#Characteristic...
  • globalreset 4y ago
    That's why Rust always wins the most loved SO survey?
    • MrBuddyCasino 4y ago
      No. The reason is everyone who works with Rust chooses to do so, because it is new and jobs are far and few, as opposed to the billions of legacy code lines in eg C++ that nobody likes but companies need maintained.
• sacnoradhq 4y ago
  This comes across as rationalization and investment bias. Because someone "likes" something doesn't make it better, it makes it philosophy or religion. You can put guards on a razor blade, but it's still going to slice your finger.
• mrlonglong 4y ago
  He needs to show us the code.
  • camel-cdr 4y ago
    Did you even read past the introduction?
  • gavinhoward 4y ago
    Author here. There's a link in the post. It's at https://git.yzena.com/Yzena/Yc https://git.yzena.com/Yzena/Yc .
    • mrlonglong 4y ago
      Thank you, time I had my eyes tested.
• zetalyrae 4y ago
  Reading the section on how the author just likes C much more than other languages, I was going to comment he should try building his own C-inspired language that he feels comfortable with but fixes some of C's flaws. But it turns out that's what he's already doing: https://gavinhoward.com/2018/08/pl-design-1-principles/ https://gavinhoward.com/2018/08/pl-design-1-principles/
• ekidd 4y ago
  I am more paranoid and cautious than, say, 95% of the programmers I've known. Maybe more. I still don't trust myself to write safe C. Specifically, I do not think I'm smart enough to violate the Chrome team's Rule of 2: https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md https://chromium.googlesource.com/chromium/src/+/master/docs... > The Rule Of 2 is: Pick no more than 2 of untrustworthy inputs; unsafe implementation language; and high privilege. I do know of a few C programmers I'd trust: DJB, many of the OpenBSD team, the Dovecot maintainers, and a few others with long track records of security. But I don't trust myself because I've used fuzzers on my Rust code, trying billions of inputs. And I've found DDOS bugs that would have been potential exploits in C. What's more damning, the most careful C code I ever wrote has an enormous, sneaky test suite. It was tested with every sanitizer I could find. It used carefully designed error handling conventions. Still, in the last 20 years, it has been the subject of several CVEs. You see, I relied on a high-quality 3rd party XML parser, and that parser had a handful of bugs. Out of 7 billion people on this planet, the number that I'd personally trust to reliaby write CVE-free C code is in the low triple digits. I'm not one of them. Understanding Rust is a cakewalk compared to understanding "undefined behavior" in the C standard, or to making sure a large C program never overflows an addition, or accesses memory out of bounds. But Rust is not the only option. Use Go or Java or Ada SPARK or a functional language or WUFFS. Any are fine. As an industry, we need to stop making the same endless security mistakes. It's not OK.
  • delusional 4y ago
    > You see, I relied on a high-quality 3rd party XML parser, and that parser had a handful of bugs. At that point it's hardly the fault of C. Even in supposedly "memory safe" languages like Java, XML (and json) parsers are often riddled with bugs and design problems that can be exploited for remote execution. It's a joke, but these parsers are still somehow considered "best in class" because many supposed "programmers" are willing to trade security for the ability to write annotations. I'd say that what you describe in your software is exactly what i like about C. You know it's dangerous, so you take precautions. You then discover that those precautions maybe aren't enough and you go looking for something more stringent (like rust). There's learning there. If we cargo cult Rust as "what people should learn instead of C because it's secure" bad programmers will go write poorly designed rust code that's as unsafe (if not more so) as any C code, except now they won't be careful because "the language is safe".
• avgcorrection 4y ago
  Bury The Lead/Lede: The Article > The final reason is the only one that justifies my decision: my code will be rewritten in a memory-safe language [which I wrote and designed]. Oh look. Haven’t seen that conclusion before.
• junon 4y ago
  I love C. I'm good at C. I have extensively researched undefined behavior, how to spot it, how to avoid it. I've written loads of C, and I consider my C to be pretty darn good. I learned Rust over the last 6 months. I'm not sure I'll ever go back to C. I still love C. But Rust is the future. I'm pretty sure of it. I don't have to worry about undefined behavior unless I opt into it, and I usually write more performant and powerful code in a shorter amount of time. I've gone down the road of trying to bolt on checkers and verification to C to achieve a better DX when writing safe C. C compilers just aren't extensible enough right now though (Clang would require some serious upgrades to the attributes and tablegen system in order for it to work well). Rust's compiler is already extensible today, and the language has most of that built in.
  • fallat 4y ago
    Have you tried zig?
    • lanza 4y ago
      I've experimented and liked it, but the odds of a language exploding in popularity without a massive investment from tech giants is nearly zero. It's not "may the best language win."
    • getoverit 4y ago
      [flagged]
    • junon 4y ago
      Yes. I'll leave it at I have serious concerns about the safety of Zig and refuse to use the language or anything written with it until its creator changes his approach when responding to critical security vulnerability reports.
      • AndyKelley 4y ago
        You have no idea what you are talking about.
• maxyurk 4y ago
  > "I can’t program effectively if I think my wife is mad at me." so it's not just me
  • dvhh 4y ago
    Tell that to my imaginary wife
  • punkbit 4y ago
    I found that one funny too :D
• Kwpolska 4y ago
  [flagged]
  • HL33tibCe7 4y ago
    The latter is sunk cost fallacy
    • deleted 4y ago
      [deleted]
  • loup-vaillant 4y ago
    Hating everything except a particular language is an excellent reason to use that particular language. He didn't explain why everybody should use C, he explained why he uses C. The time spent working with C is just used as a proxy for the switching costs. He's probably overly conservative here, but I'm not seeing Stockholm anything there.
• grumpyprole 4y ago
  > Rust is too big for my small brain, unfortunately. Rust is harder because it imposes constraints on the programmer in order to enforce memory safety. These constraints don't magically disappear if you are trying to write memory safe code in C.
  • zajio1am 4y ago
    The difference is that you can just use any kind of valid constrains or invariants to prove safety in C (but unfortunately these are just in mind or documentation and not verified by compiler), while you have to fit to specific model of constraints used by Rust.
  • deleted 4y ago
    [deleted]
  • mort96 4y ago
    The constraints imposed by Rust are more difficult to deal with though. There are so many cases where I know for sure 100% that something is completely safe, but I have to spend a whole lot of brain power trying to come up with a way to convince Rust that it's completely safe which doesn't just involve unnecessarily boxing a value.
    • aldanor 4y ago
      We've all been there – you know for sure something is 100% safe and then the fuzzer finds and UB that was outside of your mental model bounds... Thing is, if some system/concept/abstraction/model is memory-safe, more often than not it directly translates to Rust concepts via lifetimes and the such. If you've done it a number of times, you will find it very easy to map the former to the latter. In the rare cases when it doesn't fully translate, you can always dip into unsafe (usually at the lowest levels of your abstractions), same as the Rust's standard library does, and test/fuzz that part extensively.
      • mort96 4y ago
        I am not against the concept of safety guarantees. We have all been there where we have written code based on a faulty mental model which resulted in bugs. Yes. And more often than not, Rust would have prevented those bugs or made them less severe. But we have also all been there where we have had a solid mental model of what a system is doing and written correct code. Rust helps in the former case, but it makes the latter case harder. And no, it's not the case that "more often than not", if you need one const reference and one non-const reference to some data, your code is wrong. In fact, almost all code in almost all mainstream languages end up with multiple references where at least some are non-const, and it's fine most of the time. In Rust, all of those situations require type system and borrow checker gymnastics. I'm not against Rust. I think it's a fine language. I also think it's significantly harder to write than most other languages if you don't want to just punt and use Rc<RefCell<T>> all over the place.
• deleted 4y ago
  [deleted]
• Niksko 4y ago
  I couldn't quickly figure out what sort of applications this person writes for a living. But for 95% of applications I can think of: whatever, you do you. Lots of people have pointed out flaws in his arguments here. There are always at least two collaborators on a codebase: you and you in two years time. You can enforce your own documentation best practice, but it's always possible to make mistakes unless you have a probably correct way of enforcing those best practices. I'm sure there are other very valid criticisms. But in the end, there's a good chance that 100% guaranteed memory safety actually doesn't matter for the software that write. If you told me this person writes software for pacemakers or ABS systems or something similarly safety critical I'd take issue. But beyond that it's a sliding scale from merely irresponsible to an inconvenience.
  • gavinhoward 4y ago
    Author here. My monorepo (the "current project" linked in the post) has or will have: * A compiler library (replacement for LLVM). * A programming language. * A build system. * An init/supervision system. * A VCS/project management system. And maybe more.
• jasonhansel 4y ago
  The good thing about C is that, while its memory management is unsafe, it is at least explicit; there's generally no doubt as to whether a statement allocates memory or not, since "malloc" and "free" have to be written out explicitly in the code. The same cannot be said for C++.
  • robotresearcher 4y ago
    Various stdlib functions allocate heap memory without a visible malloc().
    • steveklabnik 4y ago
      Or even, uh... shell out to perl https://github.com/Apple-FOSS-Mirror/Libc/blob/2ca2ae74647714acfc18674c3114b1a5d3325d7d/gen/wordexp.c#L192 https://github.com/Apple-FOSS-Mirror/Libc/blob/2ca2ae7464771...
  • SubjectToChange 4y ago
    The behavior of malloc and free often isn’t explicit.
• jeffrallen 4y ago
  > Rust is too big for my small brain, unfortunately. This. So much this.
• mort96 4y ago
  Why was the "why" removed from the title? The author is writing about why they're doing something, not announcing to the world that they're doing the thing.
  • steveklabnik 4y ago
    Hacker News has some automated editing of article titles. Removing “why” from the start is one of them. At least this one isn’t incoherent because of this kind of transformation, that happens sometimes.
    • rrishi 4y ago
      Removing "why" from the beginning sounds pretty arbitrary. How did they come up with this?
      • steveklabnik 4y ago
        I don't know, you'd have to ask dang.
  • gavinhoward 4y ago
    Author here. What @steveklabnik said is correct. I knew this and actually added the "Why" back in manually after posting. Then someone came along and removed it, along with my title case, which makes me sad.
• dvhh 4y ago
  I have yet to touch Rust, as I am currently busy with other things and my work is in other computer language. And mostly glueing modules together. But yes, I am one of those weirdos that use C for their personal projects, and yes I find it "fun" to fire the debugger to look for my own mistake, see my code run magnitude slower through Valgrind to find my memory errors, and yes I know that my code will be riddled with UB and other kind of "fun" error, but again that is expected because (well) it is C. And I do it on my commute while ssh-ing with my phone. And while I am very impressed by the progress of Rust over the years. There are two aspects that kind of put me off. The community does come as very preachy and the language sound very close to the Ada language ( as in "not fun to work with"). And so far those two haven't been disproven. So maybe the day that I would have to write life critical software as a hobby I would consider writing in it in Rust. Or maybe in order for Rust to succeed it would have to make the other languages far less fun.
  • Aeolos 4y ago
    Rust is actually really fun to work with. Don't let random naysayers on hn convince you otherwise, try it for a month or three and form your own opinion. There is something magical about wri5ing code that is as fast as C++ but with a fraction of the bugs and effort.
    • thesuperbigfrog 4y ago
      >> try it for a month or three and form your own opinion Seconded. After you use it for a few months it begins to click and makes sense. I use C and C++ when I have to work with legacy code, but choose Rust for new projects.
  • nindalf 4y ago
    About the fun aspect of using Rust. Once I learned it, nothing feels as fun as Rust for two reasons - when I'm done writing the program it almost always works first try and second, when it runs I know this is the fastest possible program that I could have written. It takes a while to get to the point where writing Rust feels easy, but when you do it's so much fun. That's why Rust users love the language so much.
• aww_dang 4y ago
  I read the title as "Why I use C..." not, "Why you must use C..."
• projektfu 4y ago
  The title should be "Why I use C despite believing in memory safety (but you should use something safer that you prefer)". That better expresses the author's point and avoids the pointless comments about how hard it is to write C safely. Basically, the author says that he feels unproductive in other languages so he's better off doing a good job in C than not finishing in other languages, and he enumerates techniques to reduce memory errors, freely admitting that other languages give that by default.
  • gavinhoward 4y ago
    Author here. I agree that that's a good title. I have a thing against long titles though... Your comment is also a good summary of the post.
• perryizgr8 4y ago
  > I can’t program effectively if I think my wife is mad at me. Can confirm :(
• H4ZB7 4y ago
  [flagged]
  • deleted 4y ago
    [deleted]
• coliveira 4y ago
  The only flaw in the original paper was the inclusion of "Rust" as a safe language. Anyone who understands what it really does knows that you can indeed write unsafe code in Rust, unlike Java for example. Rust makes it easier to write safe code, but doesn't prevent unsafe code to be written, which puts it back in the category that should be avoided by the masses. Moreover, Rust is extremely complex, similar or worse than C++. A programmer has to learn a lot of alien concepts that they don't need when using Java, Go, or similar safe languages.
  • jjnoakes 4y ago
    Rust is absolutely a safe language, and in more ways than just memory safety. The only way to get unsafe code in rust is to opt in to unsafety with a keyword that can easily be checked for, so that you can decide for yourself to enforce that no code in your project uses it. And unless you are writing a few specific types of code, using unsafe usually isn't ever necessary at all. The complexity is also very much not an issue in practice. If you rub up against complexity in C++, you might not even know it. UB could be silently ruining things. If you rub up against complexity in rust, you were either just saved from yourself, or you are hitting part of the language that is probably undergoing improvement. But you never have to worry about complexity silently making things worse.
    • mcronce 4y ago
      It's also super easy to enforce at the crate level with #![forbid(unsafe_code)] if you feel so inclined - no manual checks necessary
    • coliveira 4y ago
      > complexity is also very much not an issue in practice. In practice, people find otherwise. It takes a steep learning curve to use Rust compared to Java, for example.
      • jjnoakes 4y ago
        We're comparing rust to c++ in this thread. There are simpler languages than both out there, sure, but that's not really relevant here.
• astrange 4y ago
  > I run Clang and GCC with -Wall, -pedantic, and -Werror. This means I eliminate all warnings at every stage of development. > I even run Clang with -Weverything This isn't "discipline". Those warnings themselves aren't all tested and often don't work. There's no point in conforming to a broken check like -Wstrict-aliasing or one that could be arbitrarily hard to fix like -Wdeprecated.
• winstonprivacy 4y ago
  I stayed away from C++ for about 15 years, while working in higher level languages (C#, Go). I recently came back to it and my productivity is SOOO much higher, along with my code quality. I argue that for certain applications, the ability to work directly with memory is paramount. I shaved 35ns off of a critical routine the other day with a clever memory hack. And in another example, I doubled the speed of a critical loop simply by rearranging variables within a struct so that the CPU had more efficient access to them by avoiding page cache faults. Mind you, this code already runs hundreds of times faster than anything written in Go or any other garbage collection language can do.
  • vrnvu 4y ago
    How does these performance optimizations you mention translate to cost? How much money are you saving monthly for example? It's hard to justify the effort to write fast code nowadays without talking about cost or revenue.
  • celeritascelery 4y ago
    Do you think you would be as productive in Rust? Or have you you not tried it?
    • winstonprivacy 4y ago
      I haven't tried it but for what I do, I need to be very close to assembly. One microsecond of processing time incurs high costs.
• anthomtb 4y ago
  I also like writing code in C both professionally and for personal projects. One thing I LOVE about C is the offline documentation for standard libraries. Beej’s guide to network programming is amazing but also reproducible with “man socket” and then wandering down the rabbit hole. (Ref: https://beej.us/guide/bgnet/html/split/ https://beej.us/guide/bgnet/html/split/) C++, the sprawling beast that it is, you have no choice but to consult some web page to get decent documentation. The same goes for Rust (Please let me know if I am wrong here, I have not used Rust in several years). Maybe it’s just a personal quirk, but when programming I love to shut off Wi-Fi and focus on whatever it is I want to get done. It is not always feasible of course, but it is definitely my preferred way to work. And C is the most amenable language to being offline.
  • steveklabnik 4y ago
    Rust includes: * offline documentation for the standard library and other things, via rustup * the ability to generate full documentation for your project offline via “cargo doc,” including any dependencies This has been in place basically forever, so you must have just missed it last time.
• bob1029 4y ago
  It is absolutely possible to develop robust, complex applications that you can trust using C. I think the best example of this is SQLite. But, we need to recognize the size and coverage of the test suite involved with this product... I would be curious if any maintainers of SQLite have some commentary regarding the impact of unsafe programming on the extent of the testing.
  • steveklabnik 4y ago
    > I would be curious if any maintainers of SQLite have some commentary regarding the impact of unsafe programming on the extent of the testing. They sort of do, yeah https://www.sqlite.org/whyc.html https://www.sqlite.org/whyc.html
  • SubjectToChange 4y ago
    Then again, SQLite is notable exactly because of how exceptional it is. Indeed, most C projects can’t afford to be developed and tested in such a way. So the problem isn’t that C can’t be made safe, practically any language can be made safe, instead it’s that C can’t be made safe within the resource constraints of typical development.
• teunispeters 4y ago
  I like C better than every other language... for some of the same reasons. Mind, I'd prefer assembly but it's inconsistent between different versions of the same processor, let alone different processors ... I CAN code in a lot of languages. The only one I have no interest in ever revisiting is PHP. I rather dislike java's bytecode but the language itself is somewhat ok. But I prefer C. Not just due to "bare metal", but also because it's fairly easy to communicate with other hardware. I'll note - when multiple different hardware is involved, you'll never get "safe code". Not unless the hardware is "safe" too. I think the thing I'm wary about rust about is how much its claims depend on the underlying hardware being consistent, reliable and stable. But - I'll use whatever tools employers or contractors need. I think the hardest language for me is C++ - as above - because it's so "flexible" (and hides so much under the water) that it takes rather a lot of investment to learn every new stack. I use C on my own projects. I've yet to see a good argument to explore another option and still maintain consistency with communicating with disparate hardware.
• Nginx487 4y ago
  Software developers tend to love things that give them challenges and material for mental workouts, and it's fine. However, it has nothing to do with commercial software development, where system architects should think not only about the "coolness" of technology, but also about people who will support the final product. And team leaders think about how hard it would be to hire people who know how (and are willing!) to work with the said "cool technology", and since we are talking about statements like "I have developed a custom software stack designed around memory safety", i.e. non-standard solution with no documentation, (while there are alternatives, where memory safety assumed to be as a pre-requisite, not as an implementation artifact), actually, "close to zero". I was writing in C and classic C++ for 17 years, and I admit it is fun and challenging to design and implement systems using these tools. However, when in my team we have a library that we're expected to develop and write in C, I rewrite it in modern C++17 (I don't say "in Rust" exactly because of the second reason, but modern C++ is safer than old C by an order of magnitude), and the process rarely takes not more than 1 week. As a result its source code usually becomes about 10 times smaller, implementation faster in 80%, and the team is spared of wasting their time exploring undocumented solutions written decades ago.