Solod: Go can be a better C • Hacker News Board

Re: Solod: Go can be a better C

#171

Post by gwbas1c » Sun, Jul 19, 2026, 3:20 PM UTC

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…

Rust is memory safe, but not "manual memory management." IE, the vast, vast majority of Rust doesn't use pointers.

Re: Solod: Go can be a better C

#172

Post by win311fwg » Sun, Jul 19, 2026, 10:16 PM UTC

throwaway894345 wrote: post #170

win311fwg wrote: post #151

Earlier quoted context omitted.

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

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

> It seems like you’re conflating dynamic

Perhaps I should have said heap memory to be more clear, but the intent was to recognize that C does have memory management (the stack), but it manages it automatically. However, I don't think the intent was actually lost as you specifically called out malloc, which was directionally correct. So I guess there was no need to be more clear as the message was delivered just fine.

> C definitely has manual memory management via malloc

No. malloc isn't part of the C language, it is a library function and one that isn't guaranteed to be available at that.

> It can be reasoned about, but doing so correctly is very difficult

To the best of our knowledge it is impossible. That is why Rust's claim to fame is adding a model necessary to make reasoning about memory possible.

> C has dynamic memory (again, malloc and free)

Again, malloc and free are not language features. They are bolted on top. You can bolt malloc and free onto every language under the sun. You can even bolt malloc and free onto Rust, but you will then break the ability to reason about its memory if you use it.

Re: Solod: Go can be a better C

#173

Post by win311fwg » Mon, Jul 20, 2026, 4:51 AM UTC

loup-vaillant wrote: post #169

win311fwg wrote: post #167

Earlier quoted context omitted.

> I mean implementations, but we can conflate the two in most cases Perhaps there is something to be said about that within the space of all programming languages, but why would you conflate them in our discussion about Go given that having multiple implementations was established as a language design requirement? For many years the core Go team maintained two different Go compilers themselves to ensure that requirem…

> In practice, if you were going use Go on a microcontroller you would not use the same compiler as you would use if you writing a web server. Is that a fact? Are you telling me that today , there's a Go compiler that's best suited for web servers, and a different Go compiler best suited for micro-controllers? Could you name the micro-controller one? > As we already discussed, one such tradeoff is in GC implementatio…

> Are you telling me that today, there's a Go compiler that's best suited for web servers, and a different Go compiler best suited for micro-controllers?

No, I would have no reason to tell you that because, given what we're talking about, you would already know that. You couldn't possibly partipcate in good faith if weren't familiar with the Go ecosystem. This is such a strange comment.

Re: Solod: Go can be a better C

#174

Post by sylware » Mon, Jul 20, 2026, 12:02 PM UTC

potus_kushner wrote: post #165

Chu4eeno wrote: post #143

Earlier quoted context omitted.

> A good test is to try to port significant from c++ to plain and simple C using "AI". Maybe it can retain some of the semantics for the original code. So updating cfront for modern C++.

it's already happening: https://github.com/rolandpj1968/sea-front

Sanity and common sense are starting to fight back?

Re: Solod: Go can be a better C

#175

Post by throwaway894345 » Mon, Jul 20, 2026, 12:23 PM UTC

win311fwg wrote: post #172

throwaway894345 wrote: post #170

Earlier quoted context omitted.

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

> It seems like you’re conflating dynamic Perhaps I should have said heap memory to be more clear, but the intent was to recognize that C does have memory management (the stack), but it manages it automatically. However, I don't think the intent was actually lost as you specifically called out malloc, which was directionally correct. So I guess there was no need to be more clear as the message was delivered just fine…

malloc and free are part of the C standard library. I don’t see the point in picking nits between language features you don’t have to use and standard library functions that you don’t have to use.

Re: Solod: Go can be a better C

#176

Post by [deleted] » Mon, Jul 20, 2026, 2:38 PM UTC

throwaway894345 wrote: post #175

win311fwg wrote: post #172

Earlier quoted context omitted.

> It seems like you’re conflating dynamic Perhaps I should have said heap memory to be more clear, but the intent was to recognize that C does have memory management (the stack), but it manages it automatically. However, I don't think the intent was actually lost as you specifically called out malloc, which was directionally correct. So I guess there was no need to be more clear as the message was delivered just fine…

malloc and free are part of the C standard library. I don’t see the point in picking nits between language features you don’t have to use and standard library functions that you don’t have to use.

[deleted]

Re: Solod: Go can be a better C

#177

Post by win311fwg » Mon, Jul 20, 2026, 2:49 PM UTC

throwaway894345 wrote: post #175

win311fwg wrote: post #172

Earlier quoted context omitted.

> It seems like you’re conflating dynamic Perhaps I should have said heap memory to be more clear, but the intent was to recognize that C does have memory management (the stack), but it manages it automatically. However, I don't think the intent was actually lost as you specifically called out malloc, which was directionally correct. So I guess there was no need to be more clear as the message was delivered just fine…

malloc and free are part of the C standard library. I don’t see the point in picking nits between language features you don’t have to use and standard library functions that you don’t have to use.

When you called attention to Rust you clearly understood the point of picking nits. Why pretend you have no idea what we are talking about now?

malloc/free, not being a language feature, cannot be reasoned about. Since the larger discussion is about Go, consider using malloc/free in Go. Of course you can do it. There is nothing stopping you. Since it is not part of a language it can be bolted on to any language, not just C. But if you do, it should be obvious you can no longer reason about the program in terms of how memory is used. If there was a way to reason about it, C would already have all the same memory guarantees that Rust does.

Re: Solod: Go can be a better C

#178

Post by loup-vaillant » Mon, Jul 20, 2026, 8:51 PM UTC

win311fwg wrote: post #173

loup-vaillant wrote: post #169

Earlier quoted context omitted.

> In practice, if you were going use Go on a microcontroller you would not use the same compiler as you would use if you writing a web server. Is that a fact? Are you telling me that today , there's a Go compiler that's best suited for web servers, and a different Go compiler best suited for micro-controllers? Could you name the micro-controller one? > As we already discussed, one such tradeoff is in GC implementatio…

> Are you telling me that today, there's a Go compiler that's best suited for web servers, and a different Go compiler best suited for micro-controllers? No, I would have no reason to tell you that because, given what we're talking about, you would already know that. You couldn't possibly partipcate in good faith if weren't familiar with the Go ecosystem. This is such a strange comment.

First, I’m not familiar with the Go ecosystem. I have never written a single line of Go, and I learned in this thread that there was more than one compiler. Second, please don’t accuse me of engaging in bad faith. I’m not.

My question was genuine. What triggered it is when you wrote "in practice". I myself draw a sharp distinction between a language and its implementation, but the moment "in practice" gets thrown in, I have to assume we’re talking about existing implementations only. And I have to say, as unfamiliar as I am with the Go ecosystem, the existence of a compiler (somewhat?) tailored to embedded use, is deeply surprising to me.

Re: Solod: Go can be a better C

#179

Post by loup-vaillant » Mon, Jul 20, 2026, 11:05 PM UTC

throwaway894345 wrote: post #168

loup-vaillant wrote: post #158

Earlier quoted context omitted.

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

> 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. The tool is the escape analyzer, but I don’t think anyone has made it ergonomic yet.

Then it needs to be made standard. Without that, or an equivalent solution, garbage collected languages will remain unusable in constrained environments.

Re: Solod: Go can be a better C

#180

Post by loup-vaillant » Mon, Jul 20, 2026, 11:11 PM UTC

throwaway894345 wrote: post #170

win311fwg wrote: post #151

Earlier quoted context omitted.

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

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

> It can be reasoned about, but doing so correctly is very difficult […]. I don’t think this is controversial?

It’s actually much easier than 95% of programmers think. The trick is to stop using fine grained allocations all the time, which are very difficult without tricks like RAII or a borrow checker (not to mention the high runtime overhead), and start using arenas instead. https://www.rfleury.com/p/untangling-lifetimes-the-arena-all...