5 ms·

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 actu

by pjmlp 4mo ago

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.

deleted 4mo ago
[deleted]
nine_k 4mo ago
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.
- pjmlp 4mo ago
  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 OS in a GC language" discourse. It isn't only a mainstream thing because everyone only cares about UNIX clones.
  - cturner 4mo ago
    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?
    - meling 4mo ago
      There is Biscuit from OSDI 2018 https://pdos.csail.mit.edu/projects/biscuit.html https://pdos.csail.mit.edu/projects/biscuit.html
    - pjmlp 4mo ago
      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 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. We see this happening even with Haiku, Genode, Redox OS, or Windows now shipping alongside Linux on top of Hyper-V. Unless one is an Apple or Google, with the money and will power to push something out the door, using Objective-C, Swift, Java, Kotlin, with plain C and C++ standard libraries, and even then people will bend backwards to put UNIX into those systems, even when the platform owners went to great effort to hide it under the official userspace APIs.
      - bigfatkitten 4mo ago
        > 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.
      - loup-vaillant 4mo ago
        > 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.
  - pizza234 4mo ago
    > 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.
    - pjmlp 4mo ago
      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.
      - pizza234 4mo ago
        > but used as an attack against other languages, as if to prove they are not good enough for a specific use case. Ultimately, it comes down to the (subjective, sure) ergonomic limitations of a language. To me, Go without garbage collection and implemented using specific compiler support and significant amount of unsafe operations, does not really represent Go, just as, so to speak, a Rust project containing 90% unsafe code does not really represent Rust. Both are possible of course, and there are even use cases in which they may be desirable in the broader context (ie. the Go runtime). Therefore, this is not an attack on the language; it is simply an assessment of its ergonomics for particular use cases.
- yvdriess 4mo ago
  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.
  - pjmlp 4mo ago
    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.
- Someone 4mo ago
  > 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 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?
owaislone 4mo ago
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.
- pjmlp 4mo ago
  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.
  - loup-vaillant 4mo ago
    > 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.
    - pjmlp 4mo ago
      I see it differently, given how C with Classes came to be, a Typescript for C in 1989.
loup-vaillant 4mo ago
> 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.
- gwbas1c 4mo ago
  > 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.)
  - dlisboa 4mo ago
    > C is great when you need to do manual memory management. Is it still, today? There are other manual memory languages today with better safety records and ergonomics. Plus a host of new and better features. I think C is really great if you need C. For libraries, for knowledge, for size, for compatibility, for "simplicity", for fun, for whatever. But other than having a strong reason to want C, on a purely language feature comparison, it's not great.
    - loup-vaillant 4mo ago
      Compatibility is a big one. Probably the biggest reason to chose C over Zig or Rust today. But that can be remedied if the new language has a C compilation target.
    - gwbas1c 4mo ago
      Rust is memory safe, but not "manual memory management." IE, the vast, vast majority of Rust doesn't use pointers.
  - loup-vaillant 4mo ago
    > Most software written today doesn't need to do manual memory management. Need? Not really, not on the desktop (embedded is a different story entirely). But there are still benefits, as well as costs. Thing is, most programmers have no idea what the actual costs an benefits are, because they have a hopelessly incomplete view of what manual memory management actually is. To them, and this includes long time C++ programmers, manual memory management means calling the general purpose allocator for every little object. At best they’d batch allocation in arrays or vectors, but otherwise it’s RAII for most stuff, and new/malloc() for anything more complicated. This kind of memory management have high costs and low benefits. In some cases the runtime overhead is even greater than using a GC. And then there are arenas. Much easier to deal with, much lower overhead, much safer, more predictable… They make the cost/benefit analysis completely different, to the point you could ask yourself why you would even bother depending on a GC and the heavy runtime that goes with it. https://www.dgtlgrove.com/p/untangling-lifetimes-the-arena-allocator https://www.dgtlgrove.com/p/untangling-lifetimes-the-arena-a...
dzonga 4mo ago
ZIG is already the better C.
- pjmlp 4mo ago
  Zig is what Modula-2 already offered in 1978, Ada in 1983, Object Pascal in 1986, revamped in curly bracket syntax. We need a little more in 2026, besides compile time execution.
  - tocariimaa 4mo ago
    Aside from a GC, what other features are "more 2026"? I'm curious.
- lioeters 4mo ago
  I really wish it had more industry buy-in, in terms of funding and community participation. The language has so much to love about it, and even the typical criticisms - some deserved, some not - can be improved or solved over time because it has solid design and foundation. Like most well-built systems, there's a single person (or few people) with coherent vision driving the development, in contrast to C++ and other "design by committee" style projects.
anamitra- 4mo ago
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.
- pjmlp 4mo ago
  My point was not about Go vs Java.
  - anamitra- 4mo ago
    You missed a bit of my point. The point am trying to convey is that what it was made for that is efficiency and networking it fails somehow and somewhere in both. As i was surprised when i came across the thread safety issue of go which for me was diabolical, because go was meant to be lean at least on threads while maintaining thread safety by default. The next point would be gc,maybe it can be improved and its being improved the recent being mark sweep algorithm was made a bit efficient by addition of more meta data about the total object structure, not going into it more. Thing is it breaks the fundamental promise it was suppose to keep and yes its better than rust for network applications(am talking of getting things done in default way). It's stdlib is the strongest among all languages. That summarises my point go needs severely improve it's issue of thread safety by default provision and gc efficiency.
RetroTechie 4mo ago
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).
- pjmlp 4mo ago
  Which is another proof, that the professional experience of the UNIX idols, has shaped why Go, and not C all the way.

by pjmlp 4mo ago

deleted 4mo ago

[deleted]

nine_k 4mo ago

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.

pjmlp 4mo ago
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 OS in a GC language" discourse. It isn't only a mainstream thing because everyone only cares about UNIX clones.
- cturner 4mo ago
  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?
  - meling 4mo ago
    There is Biscuit from OSDI 2018 https://pdos.csail.mit.edu/projects/biscuit.html https://pdos.csail.mit.edu/projects/biscuit.html
  - pjmlp 4mo ago
    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 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. We see this happening even with Haiku, Genode, Redox OS, or Windows now shipping alongside Linux on top of Hyper-V. Unless one is an Apple or Google, with the money and will power to push something out the door, using Objective-C, Swift, Java, Kotlin, with plain C and C++ standard libraries, and even then people will bend backwards to put UNIX into those systems, even when the platform owners went to great effort to hide it under the official userspace APIs.
    - bigfatkitten 4mo ago
      > 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.
    - loup-vaillant 4mo ago
      > 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.
- pizza234 4mo ago
  > 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.
  - pjmlp 4mo ago
    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.
    - pizza234 4mo ago
      > but used as an attack against other languages, as if to prove they are not good enough for a specific use case. Ultimately, it comes down to the (subjective, sure) ergonomic limitations of a language. To me, Go without garbage collection and implemented using specific compiler support and significant amount of unsafe operations, does not really represent Go, just as, so to speak, a Rust project containing 90% unsafe code does not really represent Rust. Both are possible of course, and there are even use cases in which they may be desirable in the broader context (ie. the Go runtime). Therefore, this is not an attack on the language; it is simply an assessment of its ergonomics for particular use cases.
yvdriess 4mo ago
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.
- pjmlp 4mo ago
  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.
Someone 4mo ago
> 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 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?

owaislone 4mo ago

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.

pjmlp 4mo ago
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.
- loup-vaillant 4mo ago
  > 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.
  - pjmlp 4mo ago
    I see it differently, given how C with Classes came to be, a Typescript for C in 1989.

loup-vaillant 4mo ago

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

gwbas1c 4mo ago
> 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.)
- dlisboa 4mo ago
  > C is great when you need to do manual memory management. Is it still, today? There are other manual memory languages today with better safety records and ergonomics. Plus a host of new and better features. I think C is really great if you need C. For libraries, for knowledge, for size, for compatibility, for "simplicity", for fun, for whatever. But other than having a strong reason to want C, on a purely language feature comparison, it's not great.
  - loup-vaillant 4mo ago
    Compatibility is a big one. Probably the biggest reason to chose C over Zig or Rust today. But that can be remedied if the new language has a C compilation target.
  - gwbas1c 4mo ago
    Rust is memory safe, but not "manual memory management." IE, the vast, vast majority of Rust doesn't use pointers.
- loup-vaillant 4mo ago
  > Most software written today doesn't need to do manual memory management. Need? Not really, not on the desktop (embedded is a different story entirely). But there are still benefits, as well as costs. Thing is, most programmers have no idea what the actual costs an benefits are, because they have a hopelessly incomplete view of what manual memory management actually is. To them, and this includes long time C++ programmers, manual memory management means calling the general purpose allocator for every little object. At best they’d batch allocation in arrays or vectors, but otherwise it’s RAII for most stuff, and new/malloc() for anything more complicated. This kind of memory management have high costs and low benefits. In some cases the runtime overhead is even greater than using a GC. And then there are arenas. Much easier to deal with, much lower overhead, much safer, more predictable… They make the cost/benefit analysis completely different, to the point you could ask yourself why you would even bother depending on a GC and the heavy runtime that goes with it. https://www.dgtlgrove.com/p/untangling-lifetimes-the-arena-allocator https://www.dgtlgrove.com/p/untangling-lifetimes-the-arena-a...

dzonga 4mo ago

ZIG is already the better C.

pjmlp 4mo ago
Zig is what Modula-2 already offered in 1978, Ada in 1983, Object Pascal in 1986, revamped in curly bracket syntax. We need a little more in 2026, besides compile time execution.
- tocariimaa 4mo ago
  Aside from a GC, what other features are "more 2026"? I'm curious.
lioeters 4mo ago
I really wish it had more industry buy-in, in terms of funding and community participation. The language has so much to love about it, and even the typical criticisms - some deserved, some not - can be improved or solved over time because it has solid design and foundation. Like most well-built systems, there's a single person (or few people) with coherent vision driving the development, in contrast to C++ and other "design by committee" style projects.

anamitra- 4mo ago

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.

pjmlp 4mo ago
My point was not about Go vs Java.
- anamitra- 4mo ago
  You missed a bit of my point. The point am trying to convey is that what it was made for that is efficiency and networking it fails somehow and somewhere in both. As i was surprised when i came across the thread safety issue of go which for me was diabolical, because go was meant to be lean at least on threads while maintaining thread safety by default. The next point would be gc,maybe it can be improved and its being improved the recent being mark sweep algorithm was made a bit efficient by addition of more meta data about the total object structure, not going into it more. Thing is it breaks the fundamental promise it was suppose to keep and yes its better than rust for network applications(am talking of getting things done in default way). It's stdlib is the strongest among all languages. That summarises my point go needs severely improve it's issue of thread safety by default provision and gc efficiency.

RetroTechie 4mo ago

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

pjmlp 4mo ago
Which is another proof, that the professional experience of the UNIX idols, has shaped why Go, and not C all the way.