3 ms·

> As a novice C programmer, the simplicity and immediacy of results opened my eyes to how C can feel as productive as higher level languages with robust standar

> As a novice C programmer, the simplicity and immediacy of results opened my eyes to how C can feel as productive as higher level languages with robust standard libs. TBH, once you have halfway-good libraries for dealing with `char *` strings as-is, dynamic arrays and hashmaps, you are not going to be much slowed-down using C than using a higher-level language. You even get much stronger isolation guarantees than most other high-level languages, while getting much more compatibility[1] with any other language you may wish to interface to: https://www.lelanthran.com/chap9/content.html https://www.lelanthran.com/chap9/content.html [1] I did a little Go project, and it annoyed me slightly when I wanted to do performant FFI. For Go, I think the situation has improved since I last checked, though.

neonsunset 3y ago
You can trivially replace Go with C# in order to get almost zero-cost FFI (you can make it fully zero-cost with additional effort but even the baseline is better than the alternatives, hell you can statically link other .lib/.a's into AOT compiled .NET binaries).
naasking 3y ago
> TBH, once you have halfway-good libraries for dealing with `char *` strings as-is, dynamic arrays and hashmaps, you are not going to be much slowed-down using C than using a higher-level language. That can't possibly be true. Not having to even think about object lifecycles and ownership because all memory is GC'd saves a lot of time all by itself, not even getting into debugging issues when you get it wrong.
- jesse__ 3y ago
  It's definitely true. Memory allocation takes a very small percentage of my time. I'd guess < 1%. Debugging memory issues used to take me more time, but these days it's basically inconsequential, too. Having written interpreted languages previously to jumping to C & C++ (>10y programming exp), there's a massive cost to using interpreted and/or GCd languages that comments like this one never seem to acknowledge. Random package bit-rot, high-difficulty memory leaks, high-difficulty AND high consequence manual memory management (to avoid the GC), poor performance tooling, nearly completely opaque performance characteristics, inability to optimize performance past a surface level... etc. If you're building anything more complex than simple web apps, this shit all adds up to a lot. I've worked at a couple shops that these issues hit like a ton of bricks.
  - neonsunset 3y ago
    What kind of GC-based languages were the source of issues for these use cases? Was C# among them (in any recent time)?
    - lelanthran 3y ago
      I've not used C# in recent years. While I actually liked the language, it's complexity is increasing with diminishing returns. There's no point in getting to a complexity level of, for example, C++ for any language - people who want such levels of complexity will be happy to use C++.
      - neonsunset 3y ago
        While it certainly will eventually die C++'s death (can't remove language features, only add), it's luckily far from that predicament today. I don't think you could reasonably compare the two in amount of tacit knowledge one has to posses to avoid all kinds of footguns and get best results. The rule of thumb today for C# is to go with simplest way to do something and don't ignore IDE/analyzers' suggestions or warnings. A lot of focus has been put on terseness and simplicity.
    - jesse__ 3y ago
      The experience I was referring to was JS, Python and Ruby
  - naasking 3y ago
    Literally all of the costs you list apply to C/C++ as well, except you have the additional hazards of having to worry about memory safety and leaks all of the time rather than only once every 5 years. Sorry, I don't find your claims plausible at all. It's just too easy to forget what you actually spend your time on. Edit: and the most significant evidence for this is in comparing all the CVEs for C/C++ vs. memory safe languages like C#/Java. > I've worked at a couple shops that these issues hit like a ton of bricks. What you're missing is that 99% those shops wouldn't have existed at all if they had tried to go the C/C++ route because their products just wouldn't have gotten to a viable state. What your experience shows is that working in memory safe languages is so much easier that even average or mediocre programmers can get a viable product.
- lelanthran 3y ago
  > That can't possibly be true. Not having to even think about object lifecycles and ownership because all memory is GC'd saves a lot of time all by itself, not even getting into debugging issues when you get it wrong. I think perhaps the context may make it clearer: it was about simplicity. >>> the simplicity and immediacy of results opened my eyes to how C can feel as productive as higher level languages with robust standard libs. So, sure, no one is saying that you'll be faster in C, but with such a small cognitive footprint, you can be faster than you'd think. When programming in C, I don't spend much time thinking about the language, I think about the problem more than the language. I don't think about complex relationships between language features; about what might happen if I use a reference in a lambda. I don't need to remember what the `this` keyword refers to depending on how the function was created. I don't need to puzzle my way out of a painted corner due to colored functions. It's the simplicity that I was responding to. You go faster than you would expect. As far as object lifecycles go, there's a small number of idiomatic ways to mitigate the problems. Not foolproof, but with such a simple language, whatever valgrind reports can be quickly fixed. Regarding ownership: I'm not really aware of how GC languages, by way of being GC, helps there. I'm pretty certain it doesn't. If you pass an object to a method in Java, C#, whatever, and that method starts a new thread with it, you're still going to be boned if the callee starts modifying it at the same time. Whatever ownership issues you have in C, you'll have in most other GC languages as well.
  - naasking 3y ago
    > So, sure, no one is saying that you'll be faster in C, but with such a small cognitive footprint, you can be faster than you'd think. I would agree that you can be faster than you'd think on problems that C is reasonably good for. This is a fairly small subset of problems though, where your original comment was phrased like a general statement for any sort of problem / general purpose programming. That's what I take issue with. If you're going to do any kind of programming that depends on interfacing with the world, UTF, protobufs, even rendering to a screen as with this article, you're going to be pulling in those same sorts of dependencies that you denounce from all of those other languages. > Whatever ownership issues you have in C, you'll have in most other GC languages as well. I agree you have similar thread safety issues, the ownership issues I was referring to was for managing lifetimes leading to double-frees or leaks. Yes there are some idioms that almost work, but "almost work" is exactly the point, in GC'd languages they actually do just work. I understand the appeal behind the economy of C but we just shouldn't pretend it's something that it's not.

neonsunset 3y ago

You can trivially replace Go with C# in order to get almost zero-cost FFI (you can make it fully zero-cost with additional effort but even the baseline is better than the alternatives, hell you can statically link other .lib/.a's into AOT compiled .NET binaries).

naasking 3y ago

> TBH, once you have halfway-good libraries for dealing with `char *` strings as-is, dynamic arrays and hashmaps, you are not going to be much slowed-down using C than using a higher-level language. That can't possibly be true. Not having to even think about object lifecycles and ownership because all memory is GC'd saves a lot of time all by itself, not even getting into debugging issues when you get it wrong.

jesse__ 3y ago
It's definitely true. Memory allocation takes a very small percentage of my time. I'd guess < 1%. Debugging memory issues used to take me more time, but these days it's basically inconsequential, too. Having written interpreted languages previously to jumping to C & C++ (>10y programming exp), there's a massive cost to using interpreted and/or GCd languages that comments like this one never seem to acknowledge. Random package bit-rot, high-difficulty memory leaks, high-difficulty AND high consequence manual memory management (to avoid the GC), poor performance tooling, nearly completely opaque performance characteristics, inability to optimize performance past a surface level... etc. If you're building anything more complex than simple web apps, this shit all adds up to a lot. I've worked at a couple shops that these issues hit like a ton of bricks.
- neonsunset 3y ago
  What kind of GC-based languages were the source of issues for these use cases? Was C# among them (in any recent time)?
  - lelanthran 3y ago
    I've not used C# in recent years. While I actually liked the language, it's complexity is increasing with diminishing returns. There's no point in getting to a complexity level of, for example, C++ for any language - people who want such levels of complexity will be happy to use C++.
    - neonsunset 3y ago
      While it certainly will eventually die C++'s death (can't remove language features, only add), it's luckily far from that predicament today. I don't think you could reasonably compare the two in amount of tacit knowledge one has to posses to avoid all kinds of footguns and get best results. The rule of thumb today for C# is to go with simplest way to do something and don't ignore IDE/analyzers' suggestions or warnings. A lot of focus has been put on terseness and simplicity.
  - jesse__ 3y ago
    The experience I was referring to was JS, Python and Ruby
- naasking 3y ago
  Literally all of the costs you list apply to C/C++ as well, except you have the additional hazards of having to worry about memory safety and leaks all of the time rather than only once every 5 years. Sorry, I don't find your claims plausible at all. It's just too easy to forget what you actually spend your time on. Edit: and the most significant evidence for this is in comparing all the CVEs for C/C++ vs. memory safe languages like C#/Java. > I've worked at a couple shops that these issues hit like a ton of bricks. What you're missing is that 99% those shops wouldn't have existed at all if they had tried to go the C/C++ route because their products just wouldn't have gotten to a viable state. What your experience shows is that working in memory safe languages is so much easier that even average or mediocre programmers can get a viable product.
lelanthran 3y ago
> That can't possibly be true. Not having to even think about object lifecycles and ownership because all memory is GC'd saves a lot of time all by itself, not even getting into debugging issues when you get it wrong. I think perhaps the context may make it clearer: it was about simplicity. >>> the simplicity and immediacy of results opened my eyes to how C can feel as productive as higher level languages with robust standard libs. So, sure, no one is saying that you'll be faster in C, but with such a small cognitive footprint, you can be faster than you'd think. When programming in C, I don't spend much time thinking about the language, I think about the problem more than the language. I don't think about complex relationships between language features; about what might happen if I use a reference in a lambda. I don't need to remember what the `this` keyword refers to depending on how the function was created. I don't need to puzzle my way out of a painted corner due to colored functions. It's the simplicity that I was responding to. You go faster than you would expect. As far as object lifecycles go, there's a small number of idiomatic ways to mitigate the problems. Not foolproof, but with such a simple language, whatever valgrind reports can be quickly fixed. Regarding ownership: I'm not really aware of how GC languages, by way of being GC, helps there. I'm pretty certain it doesn't. If you pass an object to a method in Java, C#, whatever, and that method starts a new thread with it, you're still going to be boned if the callee starts modifying it at the same time. Whatever ownership issues you have in C, you'll have in most other GC languages as well.
- naasking 3y ago
  > So, sure, no one is saying that you'll be faster in C, but with such a small cognitive footprint, you can be faster than you'd think. I would agree that you can be faster than you'd think on problems that C is reasonably good for. This is a fairly small subset of problems though, where your original comment was phrased like a general statement for any sort of problem / general purpose programming. That's what I take issue with. If you're going to do any kind of programming that depends on interfacing with the world, UTF, protobufs, even rendering to a screen as with this article, you're going to be pulling in those same sorts of dependencies that you denounce from all of those other languages. > Whatever ownership issues you have in C, you'll have in most other GC languages as well. I agree you have similar thread safety issues, the ownership issues I was referring to was for managing lifetimes leading to double-frees or leaks. Yes there are some idioms that almost work, but "almost work" is exactly the point, in GC'd languages they actually do just work. I understand the appeal behind the economy of C but we just shouldn't pretend it's something that it's not.