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

71–80 of 188 posts

Re: Solod: Go can be a better C

#71

Post by pjmlp »

yvdriess wrote: post #44
nine_k wrote: post #28

Earlier quoted context omitted.

Go is not a better C, in the sense that you cannot write an OS with it. Runtime, GC, etc. But Go is a better language for many programs that were often written in C: network servers, CLI utilities, TUI utilities, etc.

The larger runtime makes bootstrapping go for unsupported architectures more laborious than C, but it's not a hard blocker. The function call overhead for inline assembly feels like more of an issue doing close to hw programming. It can be avoided for the runtime, but user go code can't escape it afaik.

Just like when C was being brought to life in PDP hardware and there was nothing else, someone has to put the work into it.

Re: Solod: Go can be a better C

#72

Post by owaislone »

pjmlp wrote: post #22

Go is a better C already, designed by C authors themselves, with other UNIX key figures. Which while some of the design decisions might be debatable, they actually knew what C is all about, informed by their own experience with what worked in C, Alef and Limbo, across UNIX, Plan 9 and Inferno.

Yeah but they were intentionally trying to build a better C++/Java, not a better C. It wasn't even aimed at things that C is good at. It was mostly aimed at writing high performance servers that have to scale really big not only in terms of performance but software complexity, size and contributions. So Go is a better C++ or Java for writing servers according to its creators.

Re: Solod: Go can be a better C

#73

Post by sanbor »

pulkas wrote: post #64

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.

Good point! Regarding C being the language of choice for mission-critical systems, probably you want to avoid memory bugs that might result ruining the mission. I understand many projects have large C codebases or interact with other projects in C, but migrating to Rust when possible (like replacing lead pipes as you find them for plastic pipes) sounds like a smart choice to build mission-critical low level systems.

Re: Solod: Go can be a better C

#74

Post by pjmlp »

owaislone wrote: post #72
pjmlp wrote: post #22

Go is a better C already, designed by C authors themselves, with other UNIX key figures. Which while some of the design decisions might be debatable, they actually knew what C is all about, informed by their own experience with what worked in C, Alef and Limbo, across UNIX, Plan 9 and Inferno.

Yeah but they were intentionally trying to build a better C++/Java, not a better C. It wasn't even aimed at things that C is good at. It was mostly aimed at writing high performance servers that have to scale really big not only in terms of performance but software complexity, size and contributions. So Go is a better C++ or Java for writing servers according to its creators.

A better C++ is by definition a better C, no one should be using C in 21st century beyond UNIX clones, and embedded devs that are religiously against C++, even all modern C compilers are written in C++ nowadays.

Anything you can think C is better, it isn't ISO C, rather non standard C compiler specific extensions, which can language can also be.

Just do like in K&R C days, use Assembly for what language isn't directly capable of, and it is right there as part of a regular Go toolchain installation.

Re: Solod: Go can be a better C

#75

Post by jorams »

pulkas wrote: post #64

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.

[dead]

Re: Solod: Go can be a better C

#76

Post by throwaway81523 »

This looks silly. It's about a Go subset with no GC and various other restrictions that make it map onto C. But then you have most of the problems of C. It's unclear what the advantages are supposed to be. Rust or Ada seem way preferable, depending on the application area.

Re: Solod: Go can be a better C

#77

Post by loup-vaillant »

pjmlp wrote: post #22

Go is a better C already, designed by C authors themselves, with other UNIX key figures. Which while some of the design decisions might be debatable, they actually knew what C is all about, informed by their own experience with what worked in C, Alef and Limbo, across UNIX, Plan 9 and Inferno.

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

Re: Solod: Go can be a better C

#78

Post by dwattttt »

jamiejquinn wrote: post #57
kfreds wrote: post #50

Earlier quoted context omitted.

That seems like a brittle approach to transpilation. A transpiler should translate all of the language's semantics, including resolving identifiers as symbols, and then choose legal names for them in the target language. Also, there is so much more to a language than its surface syntax. I've never designed a transpiler (I'm not a programmer), but surely the correct approach is to transform the source code into its ty…

I'm really sorry to be harsh but if you don't use programming languages and have never written a transpiler, why should anyone read your comment? You critique the approach as brittle and yet the approach you propose doesn't solve the thorny problem gp described of a growing ball of reserved keywords.

You may have missed this in their comment:

> resolving identifiers as symbols, and then choose legal names for them in the target language

The responsibility for avoiding collision with the target language is in the transpiler; it should mangle identifiers appropriately to ensure you can't accidentally hit a keyword in the target language.

Re: Solod: Go can be a better C

#79

Post by nixon_why69 »

DanielHB wrote: post #66
nixon_why69 wrote: post #41

Earlier quoted context omitted.

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.

In C you explicitly malloc things onto the heap. In go, taking the address of something maybe allocates on the heap, or maybe not if escape analysis can keep it on the stack.

Re: Solod: Go can be a better C

#80

Post by nixon_why69 »

aw1621107 wrote: post #60
nixon_why69 wrote: post #42

Earlier quoted context omitted.

That's undefined behavior in C I thought? You're addressing the memory of a stack frame that already collapsed when it returned. I think it's ok for compilers to either segfault or work like you'd think they would for that example in C. You can pass pointers to earlier frames in the stack, they're still active, but you can't return a pointer to an expired stack frame.

I think you're basically agreeing with the person you're replying to; they're pointing out that Solod doesn't really provide the "safety of Go" since the translation trivially exposes the user to UB that would not be present in Go.

You're right, I misread their point, sorry for the pedantry OP.
Post reply on HN