Live data from Hacker News

Solod: Go can be a better C

solod.dev

91–100 of 188 posts

Re: Solod: Go can be a better C

#91
The problem with these type of new / transcompile languages is not the langue, its the lacking libraries and 3th party assets. Great if just want the most basic hello world programs, but the moment you need ... for example a http server. Then your often with:

a) none

b) http 1.1

c) ... forget about more

Maybe you need rar support ... O well, ... And then you always enter the world where you need to start linking external libs, and then your mixing not just the base language and the transcompile but also whatever interface for calling those external libs.

Ironically, with LLMs being around, your often better to just have it write whatever is missing. Until you find out then, that the language misses some feature.

O great, you needed crypto support. Ok let the LLM write it for you, its only 100x slower then whatever was written years ago and had tons of enhancements and edge cases fixed.

At that point, you can just tell a LLM to write in C from the start, and be done with it. lol.

Transcompile languages have always had tons of issues, and there is a reason why non became popular. Haxe comes to mind. How many years this exist and barely anybody knows it. Because your often just better writing in the original language and fixing the issues, or picking a better fitting language for your project.

Re: Solod: Go can be a better C

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

ZIG is already the better C.

Re: Solod: Go can be a better C

#93

The problem with these type of new / transcompile languages is not the langue, its the lacking libraries and 3th party assets. Great if just want the most basic hello world programs, but the moment you need ... for example a http server. Then your often with: a) none b) http 1.1 c) ... forget about more Maybe you need rar support ... O well, ... And then you always enter the world where you need to start linking exte…

> Transcompile languages have always had tons of issues, and there is a reason why non became popular.

While implementations have all died out now in favour of direct compilation, C++ the language was designed to be a transpiled language, and was for many years with C as the target. You can likely find many who agree that it has tons of issues, but unpopular it is not.

Re: Solod: Go can be a better C

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

If with "production software" you mean large pieces of software I'd generally agree.

I personally like Zig but I'd never write a huge 200k loc project with it, I see it more fit for low level stuff like small embedded devices where you must interface with C code.

Re: Solod: Go can be a better C

#96
Does it generate the same extremely fat binaries? I've seen Go binaries get into hundreds of megabytes for things you could do with C/C++ with a few megabytes. Most of it seemed to be string tables and other things that could be reduced but not eliminated with compression.

Re: Solod: Go can be a better C

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

I disagree. Go's main plus point is concurrency, whereas the irony is it lacks thread safety—something languages such as Java have had from, let's say, day one. You can fix that issue by manually managing sync.Pool objects for performance and, on top of that, use channels, but this completely defeats the purpose of Go's simplicity. Even if you want a top-of-the-line performance with some convenience, there exists an open-source framework called Netty. It is an absolute beast for network I/O, beating out Rust in some cases and sitting just behind C. And it's all in Java.

Re: Solod: Go can be a better C

#98
I know this is probably a bad question but it says that this language would be good for C developers who like Go's safety. Isn't Go's safety achieved by its garbage collection, which is eliminated in this language? What elements of Go are safer than C which would be preserved in this subset language?

Re: Solod: Go can be a better C

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

Wikipedia says Alef lacked garbage collection, contributing to it being abandoned.

But does Limbo have any 'fatal flaws' like that? Especially compared to Go.

No doubt Rob Pike is a prolific and capable programmer. But seems like he needed quite a few attempts before arriving at Go (looking at C's flaws -> Alef -> Limbo -> Go, Wikipedia also mentions a domain-specific language called Sawzall).

Re: Solod: Go can be a better C

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

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

Post reply on HN