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

Re: Solod: Go can be a better C

#61

Post by vednig » Fri, Jul 17, 2026, 9:00 AM UTC

rob74 wrote: post #51

odo1242 wrote: post #35

Earlier quoted context omitted.

The answer is apparently "you don't": - Everything in the language is statically allocated or stack-allocated. You have to call a malloc / free function to get heap allocated things - The language is not memory safe (you can't return slices, pointers, or interface types from a function if the thing was created inside the function, unless you used heap allocation) - Interfaces (the only variable size struct Go has) ar…

So much for "Go's safety" in the quote above. Ok, it doesn't explicitly say memory safety, but what other safety could if be referring to?

it could also be Typesafe at compile time

Re: Solod: Go can be a better C

#62

Post by jdw64 » Fri, Jul 17, 2026, 9:02 AM UTC

NO Developers who use a particular language reshape their mental model to fit that language. Go is centered around its runtime. If you switch to C11, do you really need to be thinking about a goroutine scheduler, never mind garbage collection? Even just looking at example code, would a Go developer ever think defer pool.free is necessary? The mental model is completely different.

Re: Solod: Go can be a better C

#63

Post by pulkas » Fri, Jul 17, 2026, 9:07 AM UTC

no it cant.

Re: Solod: Go can be a better C

#64

Post by pulkas » Fri, Jul 17, 2026, 9:11 AM UTC

bun tried hard to be written in zig.

eventually, they fell back to rust.

there's a lesson here: subset languages are fine for experiments and small projects, but they're rarely the right choice for production software.

...and C still can't be replaced. it's still the language of choice for mission-critical systems and low-level problem solving.

Re: Solod: Go can be a better C

#65

Post by DanielHB » Fri, Jul 17, 2026, 9:15 AM UTC

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…

It also varies heavily on the kind of static analysis tools you are using in conjunction with your compiler. Some "bad" things about the language are just fine if they can be caught by the static analysis you are using.

It is a major problem with most really old languages, JS is notoriously prone to this kind of "remove the bad bits" thinking when in actuality most of those complaints are non-issues if you run a linter.

Re: Solod: Go can be a better C

#66

Post by DanielHB » Fri, Jul 17, 2026, 9:18 AM UTC

nixon_why69 wrote: post #41

brabel wrote: post #37

Earlier quoted context omitted.

It sounds incredibly dangerous in the hands of a usual go programmer who has no idea what the difference between the stack and the heap is.

Been a while since I used go but I remember it being kind of uniquely hard to tell? Like a struct is on the stack, but a *struct is maybe on the heap, depending on escape analysis?

isn't it the exact same as C in this regard? The pointer being on the stack or not depends how it was originally allocated.

Re: Solod: Go can be a better C

#67

Post by lionkor » Fri, Jul 17, 2026, 9:19 AM UTC

Go is not like C in any way. It doesn't feel like C, it feels like C# with mediocre syntax changes and extremely explicit error handling -- like someone took the bad parts of C and added them to a high level language.

I don't get it at all. Green threads are cool, but again, it's easy to write unsafe concurrent code in Go, so why would I choose it over e.g. Rust (where its hard to write unsafe concurrent code) or C++ (which gives me more control)?

Re: Solod: Go can be a better C

#68

Post by DanielHB » Fri, Jul 17, 2026, 9:22 AM UTC

fragmede wrote: post #53

rob74 wrote: post #51

Earlier quoted context omitted.

So much for "Go's safety" in the quote above. Ok, it doesn't explicitly say memory safety, but what other safety could if be referring to?

comparing it with c? thread safety maybe?

As far as I understand co-routines help don't really help with memory shared across go-routines. They only help in the fact you need to manage spawning and joining threads, making it easier to do stuff in parallel. But they don't provide thread-safety.

edit: I suppose you don't get segfaults or buffer overflows and the sort in go for accessing memory in a parallel context, you get recoverable panics. But that is still not really thread safety in my opinion, it is memory safety.

Re: Solod: Go can be a better C

#69

Post by lou1306 » Fri, Jul 17, 2026, 9:23 AM UTC

ventana wrote: post #43

Translating a language into a different language is a popular thing to do these days, but still not a very easy one. I feel it's like peeling an infinite onion of misery. First, you write a parser of your source language, figure out the translation of the instructions, and emit the code in the target language, and you're very happy when your translated Hello world compiles. Then, a user (like me) tries writing someth…

Oof that's not a good look. You can trivially avoid this by just prefixing all variable names with a salt. By the way this (or a variant thereof) is called "avoiding unwanted name capture" if you want to sound all sophisticated :)

Re: Solod: Go can be a better C

#70

Post by pjmlp » Fri, Jul 17, 2026, 9:34 AM UTC

pizza234 wrote: post #45

pjmlp wrote: post #29

Earlier quoted context omitted.

Plenty of OSes, since Xerox PARC days have been written in GC systems languages. Interlisp-D, Smalltalk, Cedar, Topaz, Oberon, Active Oberon, Singularity, Midori, Ironclad Go's runtime is written in Go. The whole compiler toolchain, GC, compiler, linker, Assembler, is written in Go. There are Go compilers for bare metal, no OS needed, like TinyGo, the runtime, written in Go is the OS. I love the "you cannot write an…

> Go's runtime is written in Go. The whole compiler toolchain, GC, compiler, linker, Assembler, is written in Go. There's some nuance to this. The runtime code uses specific compiler support and restrictions that are not ordinary Go - possible (or even done, like this case) ≠ ergonomic. No doubt of course that for the Go project, this is still a win.

Do you think libc is also written in pure ISO C?

I love how language extensions, and subsets are always valid for C and C++, but used as an attack against other languages, as if to prove they are not good enough for a specific use case.

Well, neither are C and C++, as they either have to rely on hand written Assembly code, language extensions, or be gutted down into subsets outside the official language standard.