21 ms·

> Go is a better C already It’s not. Garbage collection made sure of it. I believe everyone agrees that a "better C" has to have manual memory management. Mos

> Go is a better C already It’s not. Garbage collection made sure of it. I believe everyone agrees that a "better C" has to have manual memory management. Most even rule out Go as a systems language because of GC. Of course, I’m pretty sure Go is much better than C at some problems. But there’s no way in hell it supersedes it.

gwbas1c 2mo ago
> Of course, I’m pretty sure Go is much better than C at some problems. But there’s no way in hell it supersedes it. C is great when you need to do manual memory management. Most software written today doesn't need to do manual memory management. (And frankly, for the typical software project, manual memory management is a liability.)
- dlisboa 2mo ago
  > C is great when you need to do manual memory management. Is it still, today? There are other manual memory languages today with better safety records and ergonomics. Plus a host of new and better features. I think C is really great if you need C. For libraries, for knowledge, for size, for compatibility, for "simplicity", for fun, for whatever. But other than having a strong reason to want C, on a purely language feature comparison, it's not great.
  - loup-vaillant 2mo ago
    Compatibility is a big one. Probably the biggest reason to chose C over Zig or Rust today. But that can be remedied if the new language has a C compilation target.
  - gwbas1c 2mo ago
    Rust is memory safe, but not "manual memory management." IE, the vast, vast majority of Rust doesn't use pointers.
- loup-vaillant 2mo ago
  > Most software written today doesn't need to do manual memory management. Need? Not really, not on the desktop (embedded is a different story entirely). But there are still benefits, as well as costs. Thing is, most programmers have no idea what the actual costs an benefits are, because they have a hopelessly incomplete view of what manual memory management actually is. To them, and this includes long time C++ programmers, manual memory management means calling the general purpose allocator for every little object. At best they’d batch allocation in arrays or vectors, but otherwise it’s RAII for most stuff, and new/malloc() for anything more complicated. This kind of memory management have high costs and low benefits. In some cases the runtime overhead is even greater than using a GC. And then there are arenas. Much easier to deal with, much lower overhead, much safer, more predictable… They make the cost/benefit analysis completely different, to the point you could ask yourself why you would even bother depending on a GC and the heavy runtime that goes with it. https://www.dgtlgrove.com/p/untangling-lifetimes-the-arena-allocator https://www.dgtlgrove.com/p/untangling-lifetimes-the-arena-a...
pjmlp 2mo ago
Nope, only the anti-GC religion would agree to that. Most of those folks would never manage to replicate something like Xerox Cedar on their own, from 1980 in their beloved 2026 computers. Thankfully we have the likes of Apple and Google, that have a my way or the highway education system for such developers, that want to go through their magical gardens.
- jack_h 2mo ago
  There are roughly two orders of magnitude more microcontrollers in the world running code than application processors. GC is not acceptable on a microcontroller due to the extreme resource constraints. The GP post is correct, Go can replace some use cases for C, but it does not replace all use cases and GC is part of the reason.
  - throwaway894345 2mo ago
    Go already runs on microcontrollers, but _just like C_, care must be taken to avoid using features that are not compatible with microcontrollers (such as dynamic memory).
  - deleted 2mo ago
    [deleted]
  - win311fwg 2mo ago
    > GC is not acceptable on a microcontroller due to the extreme resource constraints. Dynamic memory allocation on a microcontroller can be treacherous full stop, but if you have accepted the tradeoffs of using dynamic memory allocation then why not GC? You wouldn't want gc[1]-style GC, but there are other GC algorithms that can work well enough on micros. The Go spec calls for garbage collection, but it doesn't say how you have to collect garbage. > but it does not replace all use cases It could replace all use cases. There are arguably much better tools for many jobs[2], but if you had to the language isn't going to stop you. [1] gc the compiler, not GC garbage collection. Naming is the hardest problem in CS. [2] Some would say all jobs, but for the sake of discussion let's agree that Go can be a reasonable choice at least sometimes.
throwaway894345 2mo ago
> I believe everyone agrees that a "better C" has to have manual memory management. This seems completely wrong. Manual memory management is perhaps C's most famous issue. I'm sure _someone_ thinks manual memory management is a feature rather than a bug, but I don't think there's any broad consensus about this at all. Moreover, Go gives you a lot of levers to control your allocations, and with some care (probably less care than writing correct C code) you can avoid allocating at all (this is how Go's own runtime works).
- win311fwg 2mo ago
  > Manual memory management is perhaps C's most famous issue C's most famous issue is that it doesn't have a dynamic memory management concept at all. You can implement manual memory management on top of C, like you can in any language, but it is not a core feature. If C had manual memory management then it could be reasoned about, which would avoid many of the pitfalls associated with memory management being bolted on top. Whether that is a feature or a bug probably depends on what kind of software you are building. If you are targeting a PC, a dynamic memory management concept in the language can be useful. If you are targeting a small microcontroller where you don't want dynamic allocation then things can get a bit weird having language features that need to be disabled or having to rely on outside processes (code review, linters, etc.) to control use. But the general consensus these days does seem to be that a language should include a dynamic memory management concept, even if it is sometimes disabled. So a "better C" likely would gain memory management, but you make a fair point that it doesn't have to be manual in nature.
  - throwaway894345 2mo ago
    > C's most famous issue is that it doesn't have a dynamic memory management concept at all. You can implement manual memory management on top of C, like you can in any language, but it is not a core feature. If C had manual memory management then it could be reasoned about, which would avoid many of the pitfalls associated with memory management being bolted on top It seems like you’re conflating dynamic and manual memory management? Or maybe you are using these terms in a way I’m unfamiliar with. C definitely has manual memory management via malloc and free. It can be reasoned about, but doing so correctly is very difficult (this is what Rust’s ownership system formalizes, after all). I don’t think this is controversial? > If you are targeting a small microcontroller where you don't want dynamic allocation then things can get a bit weird having language features that need to be disabled or having to rely on outside processes (code review, linters, etc.) to control use. C has dynamic memory (again, malloc and free) and thus it is in the same boat as other languages that have to take care to avoid using dynamic memory when writing embedded code (a decade and a half ago I was an embedded engineer using C and C++).

gwbas1c 2mo ago

> Of course, I’m pretty sure Go is much better than C at some problems. But there’s no way in hell it supersedes it. C is great when you need to do manual memory management. Most software written today doesn't need to do manual memory management. (And frankly, for the typical software project, manual memory management is a liability.)

dlisboa 2mo ago
> C is great when you need to do manual memory management. Is it still, today? There are other manual memory languages today with better safety records and ergonomics. Plus a host of new and better features. I think C is really great if you need C. For libraries, for knowledge, for size, for compatibility, for "simplicity", for fun, for whatever. But other than having a strong reason to want C, on a purely language feature comparison, it's not great.
- loup-vaillant 2mo ago
  Compatibility is a big one. Probably the biggest reason to chose C over Zig or Rust today. But that can be remedied if the new language has a C compilation target.
- gwbas1c 2mo ago
  Rust is memory safe, but not "manual memory management." IE, the vast, vast majority of Rust doesn't use pointers.
loup-vaillant 2mo ago
> Most software written today doesn't need to do manual memory management. Need? Not really, not on the desktop (embedded is a different story entirely). But there are still benefits, as well as costs. Thing is, most programmers have no idea what the actual costs an benefits are, because they have a hopelessly incomplete view of what manual memory management actually is. To them, and this includes long time C++ programmers, manual memory management means calling the general purpose allocator for every little object. At best they’d batch allocation in arrays or vectors, but otherwise it’s RAII for most stuff, and new/malloc() for anything more complicated. This kind of memory management have high costs and low benefits. In some cases the runtime overhead is even greater than using a GC. And then there are arenas. Much easier to deal with, much lower overhead, much safer, more predictable… They make the cost/benefit analysis completely different, to the point you could ask yourself why you would even bother depending on a GC and the heavy runtime that goes with it. https://www.dgtlgrove.com/p/untangling-lifetimes-the-arena-allocator https://www.dgtlgrove.com/p/untangling-lifetimes-the-arena-a...

pjmlp 2mo ago

Nope, only the anti-GC religion would agree to that. Most of those folks would never manage to replicate something like Xerox Cedar on their own, from 1980 in their beloved 2026 computers. Thankfully we have the likes of Apple and Google, that have a my way or the highway education system for such developers, that want to go through their magical gardens.

jack_h 2mo ago
There are roughly two orders of magnitude more microcontrollers in the world running code than application processors. GC is not acceptable on a microcontroller due to the extreme resource constraints. The GP post is correct, Go can replace some use cases for C, but it does not replace all use cases and GC is part of the reason.
- throwaway894345 2mo ago
  Go already runs on microcontrollers, but _just like C_, care must be taken to avoid using features that are not compatible with microcontrollers (such as dynamic memory).
- deleted 2mo ago
  [deleted]
- win311fwg 2mo ago
  > GC is not acceptable on a microcontroller due to the extreme resource constraints. Dynamic memory allocation on a microcontroller can be treacherous full stop, but if you have accepted the tradeoffs of using dynamic memory allocation then why not GC? You wouldn't want gc[1]-style GC, but there are other GC algorithms that can work well enough on micros. The Go spec calls for garbage collection, but it doesn't say how you have to collect garbage. > but it does not replace all use cases It could replace all use cases. There are arguably much better tools for many jobs[2], but if you had to the language isn't going to stop you. [1] gc the compiler, not GC garbage collection. Naming is the hardest problem in CS. [2] Some would say all jobs, but for the sake of discussion let's agree that Go can be a reasonable choice at least sometimes.

throwaway894345 2mo ago

> I believe everyone agrees that a "better C" has to have manual memory management. This seems completely wrong. Manual memory management is perhaps C's most famous issue. I'm sure _someone_ thinks manual memory management is a feature rather than a bug, but I don't think there's any broad consensus about this at all. Moreover, Go gives you a lot of levers to control your allocations, and with some care (probably less care than writing correct C code) you can avoid allocating at all (this is how Go's own runtime works).

win311fwg 2mo ago
> Manual memory management is perhaps C's most famous issue C's most famous issue is that it doesn't have a dynamic memory management concept at all. You can implement manual memory management on top of C, like you can in any language, but it is not a core feature. If C had manual memory management then it could be reasoned about, which would avoid many of the pitfalls associated with memory management being bolted on top. Whether that is a feature or a bug probably depends on what kind of software you are building. If you are targeting a PC, a dynamic memory management concept in the language can be useful. If you are targeting a small microcontroller where you don't want dynamic allocation then things can get a bit weird having language features that need to be disabled or having to rely on outside processes (code review, linters, etc.) to control use. But the general consensus these days does seem to be that a language should include a dynamic memory management concept, even if it is sometimes disabled. So a "better C" likely would gain memory management, but you make a fair point that it doesn't have to be manual in nature.
- throwaway894345 2mo ago
  > C's most famous issue is that it doesn't have a dynamic memory management concept at all. You can implement manual memory management on top of C, like you can in any language, but it is not a core feature. If C had manual memory management then it could be reasoned about, which would avoid many of the pitfalls associated with memory management being bolted on top It seems like you’re conflating dynamic and manual memory management? Or maybe you are using these terms in a way I’m unfamiliar with. C definitely has manual memory management via malloc and free. It can be reasoned about, but doing so correctly is very difficult (this is what Rust’s ownership system formalizes, after all). I don’t think this is controversial? > If you are targeting a small microcontroller where you don't want dynamic allocation then things can get a bit weird having language features that need to be disabled or having to rely on outside processes (code review, linters, etc.) to control use. C has dynamic memory (again, malloc and free) and thus it is in the same boat as other languages that have to take care to avoid using dynamic memory when writing embedded code (a decade and a half ago I was an embedded engineer using C and C++).