Switching to C over 'Modern' Programming Languages

Post by krinkatt » Thu, Apr 13, 2023, 8:26 AM UTC

ChrisRR wrote: post #36

hnarn wrote: post #16

Is this becoming a thing now (or maybe it was always a thing), where a language, like Rust, has become popular enough that instead of everyone talking about learning it, they now want to talk about how “simple” and “beautiful” C is for no other reason than signaling how different you are from the zeitgeist? Rust exists for a reason, and it solves specific problems. That’s the “magic”, just like any abstraction in any…

I'm a C programmer by day and I disagree with them, C is only simple if you're trying to do simple tasks with it. The very common thing I want to use in C is some sort of variable size string object. But no, I have to dynamically allocate a buffer that I know will be at least the right size for any text I ever put into it, or do I create a buffer that's the correct size for that string but re-alloc if I ever change i…

  struct strbuf { size_t cap, len; char *str; };
  void sb_setf(struct allocator *a, struct strbuf *sb, const char *fmt, ...);
  void sb_appendf(struct allocator *a, struct strbuf *sb, const char *fmt, ...);
  // have other convenience functions for formatting fixed point values like "prefix AAA.BBB suffix" ("voltage: 7.23 V")
  // special helpers for dates, times, etc.

Post by jbstack » Thu, Apr 13, 2023, 8:29 AM UTC

KyeRussell wrote: post #45

The author appears to be quite green behind the ears, which is fine! They’re certainly doing themselves a disservice by being so sure of themselves. There’s a lot here that feels right in the pocket of Dunning-Kruger ignorance. Being able to analyse the benefits of new tech at a distance (which is what the author is doing with their sterile toy projects) is not something that you can “fake until you make it”. It requ…

Post by chongli » Thu, Apr 13, 2023, 8:30 AM UTC

jacquesm wrote: post #15

throwawaymaths wrote: post #6

Earlier quoted context omitted.

This is silly. Assembly is an abstraction too. Do you think the CPU actually runs the code you give it? Of course not. There's microcode, register aliasing, speculative execution, etc. Even assembly itself has symbols and labels, which are themselves abstractions.

Did you really not understand the point the GP was trying to make or is this an attempt to be clever? Of course assembly is an abstraction, but it is the lowest level programming language that ordinary mortals can still write code in, which was the point the GP was making. Exactly nobody writes applications in microcode. Register aliasing and speculative execution have under normal circumstances no effect other than…

Post by psd1 » Thu, Apr 13, 2023, 8:36 AM UTC

1vuio0pswjnm7 wrote: post #12

kvark wrote: post #9

Don’t expect to see immediate benefit from Rust by writing a small Pong application. Rust gives you confidence at scale: the ability to depend on many 3rd party blocks without compromising stability or performance, the ability to grow and maintain the code, collaborate on it, etc. Nothing of this is easily seen on a small self-contained program you can write in C.

I still cannot figure out how to easily write small applications with Rust on low resource computers, like the one I'm typing this from. (Limited storage, CPU, memory.) It seems even the smallest programs require a massive toolchain. The default reliance on network connection for compilation is offputing. It's vastly easier for me to write small programs, offline, with C. The rationale for using Rust over C that I se…

Post by Someone » Thu, Apr 13, 2023, 8:52 AM UTC

krinkatt wrote: post #62

ChrisRR wrote: post #36

Earlier quoted context omitted.

I'm a C programmer by day and I disagree with them, C is only simple if you're trying to do simple tasks with it. The very common thing I want to use in C is some sort of variable size string object. But no, I have to dynamically allocate a buffer that I know will be at least the right size for any text I ever put into it, or do I create a buffer that's the correct size for that string but re-alloc if I ever change i…

I have something like this that serves me well: struct strbuf { size_t cap, len; char *str; }; void sb_setf(struct allocator *a, struct strbuf *sb, const char *fmt, ...); void sb_appendf(struct allocator *a, struct strbuf *sb, const char *fmt, ...); // have other convenience functions for formatting fixed point values like "prefix AAA.BBB suffix" ("voltage: 7.23 V") // special helpers for dates, times, etc. Just keep…