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

161–170 of 188 posts

Re: Solod: Go can be a better C

#161

Post by win311fwg »

loup-vaillant wrote: post #157
win311fwg wrote: post #152

Earlier quoted context omitted.

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

> many do not use dynamic allocation at all.

Exactly. You don’t need GC if you don’t produce garbage. And since Go uses stack-based memory like C you can avoid producing garbage just the same.

And if you do need some kind of special memory allocation then you can do the same tricks you do with C. You still don’t have to use the built-in allocator.

All the bellyaching about GC is silly because you don’t need it in the first place. The cries are like saying C isn’t suitable for microcontrollers because its standard library includes malloc… Just don’t use it.

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

Sure. The Go creators were explicit that Go is designed for building network systems. That doesn’t mean it is impossible to use for anything else, but it was optimized for a particular niche. You will feel more comfortable using languages designed for microcontrollers when programming for microcontrollers.

But it’s not GC you aren’t using that gets in the way. You don’t have to use every language feature just because it is there. Rust doesn’t become unusable for programming because it has a string type and you only need integers. Just don’t use it.

Re: Solod: Go can be a better C

#162

Post by sylware »

win311fwg wrote: post #149
sylware wrote: post #84

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. There is a more brutal option: AI could help write a c++ to plain and simple C transpiler... then we would lose the semantics of the original program, but free ourself from the very few toxic and real-life c++ compilers out there.

> but free ourself from the very few toxic and real-life c++ compilers out there. Funny because the canonical C++ compiler for the first decade of the language's life did compile to C. People eventually moved on to other compilers to free themselves from having to deal with the toxicity of C output. What's old is new again.

You are an odd one: we all know that c++ syntax complexity is beyond salvation : it has reach such an absurd and grotesque level, we are in mental pathology realm: Rube Goldberg Machine accute syndrome. And it is not even a matter of argumentation, unless being of accutely bad faith.

It seems you are failing to see that this is this very syntax complexity which makes most of this toxicity.

And having a modern c++ transplier to plain and simple C, would re-open the door to alternative and 'real-life' small/medium compilers, not like those vendor/developer-locked very few options we have today.

Somebody did it for microsoft rust. Would just be a good idea for nowadays c++.

Re: Solod: Go can be a better C

#163

Post by win311fwg »

sylware wrote: post #162
win311fwg wrote: post #149

Earlier quoted context omitted.

> but free ourself from the very few toxic and real-life c++ compilers out there. Funny because the canonical C++ compiler for the first decade of the language's life did compile to C. People eventually moved on to other compilers to free themselves from having to deal with the toxicity of C output. What's old is new again.

You are an odd one: we all know that c++ syntax complexity is beyond salvation : it has reach such an absurd and grotesque level, we are in mental pathology realm: Rube Goldberg Machine accute syndrome. And it is not even a matter of argumentation, unless being of accutely bad faith. It seems you are failing to see that this is this very syntax complexity which makes most of this toxicity. And having a modern c++ tra…

> You are an odd one

Well, we are talking about programming languages after all. That goes without saying. One has to be odd to want to do that. But we wouldn’t have it any other way!

Re: Solod: Go can be a better C

#164

Post by win311fwg »

mpyne wrote: post #155
win311fwg wrote: post #139

Earlier quoted context omitted.

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

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

He says as he then tries to prove it by showing rates of use and mentions inside programming bubbles, forgetting that we're talking about popularity. Time to step outside into the real world, away from screens. Many non-programmers who make up the vast majority of the population have heard of C++. Typescript is largely unknown.

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

The earlier claim was that transpiled languages never become popular because of the impedance mismatch between the source language and the target language, which introduces a number of practical problems. If your language is identical except for a couple of features nobody uses then you will never hit the impedance mismatch spoken of. You are technically right in a vacuum, but what about the rest of the universe? It is an example, but it remains unclear how it is a better example.

> But even there, erasing types is still a transpilation

If we are ignoring the couple of exceptions, then that is debated. Some definitions of transpilation declare that there must be a translation to a different language. Typescript is the same language as the target with extensions.

Since the larger discussion is about Go, did you know that there is also a Go with extensions language that the gc compiler[1] implements? It is especially apt because it also only needs erasure. Do you consider it to be transpiled? Or is it just plain old Go, with extensions? The sentiment I see on HN is that it's just plain old Go, not a different language that needs to be transpiled to Go. Chances are you aren't even aware that this language exists because everyone just calls it Go as well. It isn't thought of as something else even though it technically is.

But we don't have to worry about semantics. What remains clear is that simple erasure doesn't run into the impedance mismatch problem, and thus doesn't run into what was originally claimed. Hell, even the exceptions, where Typescript truly requires transpilation by any definition, map fairly cleanly to Javascript so there still isn't any major impedance mismatch to run up against like there generally is when the languages have larger gaps in functionality. It is an example, but what makes it a better example?

[1] In case you are aren't aware, the gc compiler is the canonical Go compiler implementation provided by the Go project.

Re: Solod: Go can be a better C

#165

Post by potus_kushner »

Chu4eeno wrote: post #143
sylware wrote: post #84

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. There is a more brutal option: AI could help write a c++ to plain and simple C transpiler... then we would lose the semantics of the original program, but free ourself from the very few toxic and real-life c++ compilers out there.

> 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

Re: Solod: Go can be a better C

#166

Post by loup-vaillant »

win311fwg wrote: post #161
loup-vaillant wrote: post #157

Earlier quoted context omitted.

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

> many do not use dynamic allocation at all. Exactly. You don’t need GC if you don’t produce garbage. And since Go uses stack-based memory like C you can avoid producing garbage just the same. And if you do need some kind of special memory allocation then you can do the same tricks you do with C. You still don’t have to use the built-in allocator. All the bellyaching about GC is silly because you don’t need it in the…

"Just don’t use it" is a valid argument, if it’s clear when you’re using it or not. It’s easy not to use `malloc()`: just don’t call it, and don’t call dependencies that call it. Same for Rust’s string: don’t construct strings, and don’t depend on stuff that does.

In some cases, avoiding heap allocation is just impossible. Take OCaml: last time I checked (over 10 years ago) there are two kinds of values: integers, and pointers to heap allocated objects. That’s basically it. Even floats are allocated on the heap (except when inside an array that’s the only optimisation). So unless you only do integer operations and avoid constructing any kind of data structure, you can’t avoid heap allocation.

Other languages are much more conservative than OCaml in this regard. That with value types and all. If they’re clear enough which constructs don’t trigger heap allocation, and the set of thereof is rich enough to allow significant work, then yes "just don’t use the GC" is a valid option. Not all languages (I mean implementations, but we can conflate the two in most cases) fulfil those two conditions. Maybe Go does.

Re: Solod: Go can be a better C

#167

Post by win311fwg »

loup-vaillant wrote: post #166
win311fwg wrote: post #161

Earlier quoted context omitted.

> many do not use dynamic allocation at all. Exactly. You don’t need GC if you don’t produce garbage. And since Go uses stack-based memory like C you can avoid producing garbage just the same. And if you do need some kind of special memory allocation then you can do the same tricks you do with C. You still don’t have to use the built-in allocator. All the bellyaching about GC is silly because you don’t need it in the…

"Just don’t use it" is a valid argument, if it’s clear when you’re using it or not. It’s easy not to use `malloc()`: just don’t call it, and don’t call dependencies that call it. Same for Rust’s string: don’t construct strings, and don’t depend on stuff that does. In some cases, avoiding heap allocation is just impossible. Take OCaml: last time I checked (over 10 years ago) there are two kinds of values: integers, an…

> 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 requirement was met, although these days it has turned its focus to one, relying on the community of other compilers to fulfill the other implementation requirements. It is impossible to have that conflation because there isn't just one implementation in which to conflate it with.

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. There are different tradeoffs for different computing environments and so different compilers can focus on different machines. As we already discussed, one such tradeoff is in GC implementations. While it is fair to say that dynamic memory allocation is not ideal on microcontrollers to begin with, if you chose to go down that road and accepted GC to go with it you'd want a GC designed for microcontrollers, not a GC designed for handling web requests. Those needs are very different. Conflating languages and implementations straight up doesn't make any sense in the context of this particular discussion.

Re: Solod: Go can be a better C

#168

Post by throwaway894345 »

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

Earlier quoted context omitted.

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

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

Re: Solod: Go can be a better C

#169

Post by loup-vaillant »

win311fwg wrote: post #167
loup-vaillant wrote: post #166

Earlier quoted context omitted.

"Just don’t use it" is a valid argument, if it’s clear when you’re using it or not. It’s easy not to use `malloc()`: just don’t call it, and don’t call dependencies that call it. Same for Rust’s string: don’t construct strings, and don’t depend on stuff that does. In some cases, avoiding heap allocation is just impossible. Take OCaml: last time I checked (over 10 years ago) there are two kinds of values: integers, an…

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

The internals of the GC are less important than how they affect the language itself. When memory is very limited, I need predictable memory usage, so memory usage must be part of the language's semantics. If they're not, I can't use that language in a constrained environment, full stop.

At the very least, I need to know which subset of Go's language and standard library have predictable memory usage. If there is no such clear subset, then Go cannot reliably be used in a constrained environment.

Re: Solod: Go can be a better C

#170

Post by throwaway894345 »

win311fwg wrote: post #151
throwaway894345 wrote: post #129

Earlier quoted context omitted.

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

Post reply on HN