Live data from Hacker News

Solod: Go can be a better C

solod.dev

81–90 of 188 posts

Re: Solod: Go can be a better C

#81
post #34
post #32

Earlier quoted context omitted.

The fact that people care a lot about Unix clones is significant, though. nine_k could have been more effective in arguing the point, but it seems like a strong point to argue. Do you think you Go is flexible enough to write a Unix clone with performance equivalent to a C-unix? If so, why has it not been done?

Besides the sibling Biscuit, maybe because no one bothered to do it? As simple as that, not everyone of us is a Linus. I should also point out that if you are using a Mac, changes are its iBoot Safe C might already been replaced by Embedded Swift, a GC enabled systems language. Chapter 5 of The Garbage Collection Handbook, or A Unified Theory of Garbage Collection paper for the incoming replies related to RC. People…

> People care about UNIX clones because they are lazy, UNIX has the source code available, and an existing ecosystem that they don't want to replicate, so it always ends up being yet another clone, thus throwing away all the possible innovations.

Which is a real shame, because people thinking outside the UNIX clone box have come up with some incredibly innovative operating systems like Plan 9 and OS/400.

Re: Solod: Go can be a better C

#82
post #74

Earlier quoted context omitted.

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

> A better C++ is by definition a better C

The definition is wrong, then.

I wrote C++ for most of my career. And as of late, I found myself avoiding more and more features from it. The STL is mostly trash, not worth the increase in compilation times. Templates are good for containers, but that’s about it. Inheritance and polymorphism are circumstantial enough that I’m not sure they’re worth adding to the language: in the rare cases I do need them, I can always write my v-table by hand.

The more I write C++, the more I find C is not that far from that "much smaller and cleaner language struggling to get out". And I say that fully aware of the many egregious faults still present in C.

There are two features from C++ I would really miss in a big C project: generics (templates), and destructors. But then we can always write a lightweight pre-processor to add those generics and a `defer` statement. Even if it requires a full parser, C parsers are pretty easy to write.

Re: Solod: Go can be a better C

#83
post #32
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…

The fact that people care a lot about Unix clones is significant, though. nine_k could have been more effective in arguing the point, but it seems like a strong point to argue. Do you think you Go is flexible enough to write a Unix clone with performance equivalent to a C-unix? If so, why has it not been done?

> If so, why has it not been done?

Because of the 30 million lines problem. Writing a serious OS kernel nowadays is flat out impossible: the hardware is just too diverse, it requires too many drivers. The best we can do right now is just add to an existing kernel. Kind of a vicious cycle: the more drivers we accrete to any given OS, the more impossible it is to get feature parity from the ground up.

The only solution to that is for hardware vendor to standardise their interfaces (at the hardware level), and actually give us the fucking manual. And I mean the real manual, the one that tells us voltages and pins and baud rates and the actual wire formats required to talk to it. A proprietary Windows driver is not a manual, even if it comes with an SDK. Heck I’m not even sure the source code of a Linux driver would count.

But they won’t do it. They just won’t. So unless we do something drastic like forbidding hardware vendor to ever ship software (to force them to standardise and document their actual interfaces), writing another OS that can actually compete with the existing ones will remain flat out impossible.

Re: Solod: Go can be a better C

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

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.

Re: Solod: Go can be a better C

#85
post #34
post #32

Earlier quoted context omitted.

The fact that people care a lot about Unix clones is significant, though. nine_k could have been more effective in arguing the point, but it seems like a strong point to argue. Do you think you Go is flexible enough to write a Unix clone with performance equivalent to a C-unix? If so, why has it not been done?

Besides the sibling Biscuit, maybe because no one bothered to do it? As simple as that, not everyone of us is a Linus. I should also point out that if you are using a Mac, changes are its iBoot Safe C might already been replaced by Embedded Swift, a GC enabled systems language. Chapter 5 of The Garbage Collection Handbook, or A Unified Theory of Garbage Collection paper for the incoming replies related to RC. People…

> As simple as that, not everyone of us is a Linus.

I’m pretty sure Linus could not have written Linux today. Too much hardware to support, too many drivers to write, before it’s remotely useful. Well, except perhaps on some specialised servers.

Yes, not everyone is Linus. Otherwise we’d be using GNU Hurd. But he also came at the right time.

Re: Solod: Go can be a better C

#87
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?

In go you don’t need to care, the GC will take care of allocations on the heap and the runtime will choose when something should go on the stack. That’s the problem: in this other language it’s suicidal to program as if it was the same as Go as you will just make huge mistakes like returning a pointer to a local variable.

Re: Solod: Go can be a better C

#88
post #28
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 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.

> Go is not a better C, in the sense that you cannot write an OS with it

Can you even write an OS in pure ISO standard C? I know atomic (https://en.cppreference.com/c/language/atomic) was added in C11, but is that sufficient to write an OS? How do you write a kernel-user space transition in standard C, for example?

Re: Solod: Go can be a better C

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

What's the lesson to be learned from Roc migrating from Rust to Zig?

Re: Solod: Go can be a better C

#90
Very interesting. I have a personal experimental project to convert go to c++ but it's less advanced than this (https://github.com/Rokhan/gocpp). My initial intention was to manage garbage collector with some smart pointer or something like Boehm GC but I've still not reached the point where it's the main problem to solve.
Post reply on HN