Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Solod: Go can be a better C

solod.dev

Post reply on HN
Print view View original

151–160 of 188 posts

Re: Solod: Go can be a better C

#151

Post by win311fwg »

throwaway894345 wrote: post #129
loup-vaillant wrote: post #77

Earlier quoted context omitted.

> 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.

> 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 les…

> 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.

Re: Solod: Go can be a better C

#152

Post by win311fwg »

jack_h wrote: post #114
pjmlp wrote: post #107

Earlier quoted context omitted.

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.

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.

> 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.

Re: Solod: Go can be a better C

#153

Post by awson »

RossBencina wrote: post #39

The "a better C" meme needs to die. It's ill defined. Everyone wants something different. For me, GC disqualifies any language as a better C. Bjarne Stroustrup promoted C++ as a better C. But C++ killed off some of C's killer low-level features like type-punning via unions. Indeed it's only in recent years that low-level memory manipulation, such as std::start_lifetime_as and the implicit lifetime rules were standard…

> C++ killed off some of C's killer low-level features like type-punning via unions

Yet all major C++ compilers support it.

Re: Solod: Go can be a better C

#155

Post by mpyne »

win311fwg wrote: post #139
mpyne wrote: post #119

Earlier quoted context omitted.

Typescript is an even better example. And there are some domain-specific languages that aren't meant to become popular general-purpose languages, but succeed in their niche through the help of transpilation to a general-purpose language.

Typescript isn't nearly as popular as C++ and, aside from a couple of legacy features that don't seem to be commonly used, it can be erased without needing transpilation. What makes it a better example?

> Typescript isn't nearly as popular as C++

Huh?

You should reassess how your current understanding of language popularity compares to what's actually going on outside your environment.

Typescript has already surpassed C++ in popularity. [1] [2] [3] [4]

As a primarily C++ dev myself I wish that wasn't the case, but it is.

> aside from a couple of legacy features that don't seem to be commonly used, it can be erased without needing transpilation

"If you ignore the parts that don't need transpilation, it doesn't need transpilation". Well yeah, sure.

But even there, erasing types is still a transpilation, just an error-prone version of it. It's still being run as Javascript at the end, whether you actually compile to Javascript or use a frankentranspilation instead.

[1] https://www.libhunt.com/index [2] https://www.itransition.com/developers/in-demand-programming... [3] https://eu.36kr.com/en/p/3549523189739394 [4] https://survey.stackoverflow.co/2025/technology

Re: Solod: Go can be a better C

#156

Post by loup-vaillant »

pjmlp wrote: post #105
loup-vaillant wrote: post #82

Earlier quoted context omitted.

> A better C++ is by definition a better C The definition is wrong, then. I wrote C++ for most of my career. And as of late, I found myself avoiding more and more features from it. The STL is mostly trash, not worth the increase in compilation times. Templates are good for containers, but that’s about it. Inheritance and polymorphism are circumstantial enough that I’m not sure they’re worth adding to the language: in…

I see it differently, given how C with Classes came to be, a Typescript for C in 1989.

You know, I’m actually tempted right now to do my own "C with ". Except I wouldn’t make the same choices as Stroustrup did. For one, I wouldn’t aim for popularity. I’d want something that works for me, and I’d consider it a success even if I’m the sole user. Source compatibility would not be a goal, and I’d most probably skip classes entirely.

The way C++ was first implemented was a good idea. It’s everything else I disagree with.

Re: Solod: Go can be a better C

#157

Post by loup-vaillant »

win311fwg wrote: post #152
jack_h wrote: post #114

Earlier quoted context omitted.

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.

> 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 h…

> * but if you have accepted the tradeoffs of using dynamic memory allocation then why not GC?*

That’s the thing: many do not use dynamic allocation at all. Did you know for instance that you could write an entire modern cipher suite using only a small (As for those who do use the "heap", many can do so with a strict stack discipline, so it’s not really a heap. Reason being, the environment has an extremely low call stack budget, so all bigger allocations happens in another stack, located in the heap.

Then there are arenas, which are much simpler to implement than a general allocator, tend to have less overhead (both space and runtime) than malloc() or a GC, though I reckon they can still run out of space. Still, less treacherous than uncontrolled use of malloc().

Most of all though, even if the compiler can do mighty static region analysis to minimise heap usage and GC overhead, heck, even perhaps reduce it to absolutely zero in some cases, there’s still the problem of the programming interface: how does the programmer know about stuff like max heap usage? I guess the compiler could tell them, but then how do they fix it if usage exceeds the limit, or is unbounded? The wouldn’t be any clear link from heap usage to the source code, or it would be so diffuse it would be hard to determine where to begin.

And of course, a GC’ed program would likely rely on many more pointers under the hood than one that manages its memory manually, which means significant space overhead even if the GC implementation itself is perfect.

You want me to write something for an ESP-32, it’s gonna be in something like C, Rust, or Zig.

Re: Solod: Go can be a better C

#158

Post by loup-vaillant »

throwaway894345 wrote: post #129
loup-vaillant wrote: post #77

Earlier quoted context omitted.

> 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.

> 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 les…

> I'm sure _someone_ thinks manual memory management is a feature rather than a bug,

I reckon mandatory manual memory management is not ideal. But the ability to manage some memory manually, including in cases that require something more flexible than a stack, is definitely a feature.

I believe every willing user of Zig, Odin, and Rust would agree with me on this one.

> […] with some care […] you can avoid allocating at all […]

As long as it’s crystal clear from the source code, or I have a tool that tells me which line of mine is responsible for the allocation.

Re: Solod: Go can be a better C

#159

Post by loup-vaillant »

dlisboa wrote: post #110
gwbas1c wrote: post #100

Earlier quoted context omitted.

> 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.)

> 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 f…

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.

Re: Solod: Go can be a better C

#160

Post by loup-vaillant »

gwbas1c wrote: post #100
loup-vaillant wrote: post #77

Earlier quoted context omitted.

> 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.

> 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.)

> 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-a...

Post reply on HN