This is a very exciting project; love writing go with the tooling, but I miss writing C from my getting started days
Solod: Go can be a better C
21–30 of 188 posts
Re: Solod: Go can be a better C
#22Go 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.
Re: Solod: Go can be a better C
#23> So is for Go developers who want systems-level control without learning a new language. And for C programmers who like Go's safety, structure, and tooling.
Wut?
Also, how do you preserve garbage collector semantics without garbage collector?
Re: Solod: Go can be a better C
#24Go 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]
Re: Solod: Go can be a better C
#25It cannot be a better C. You cannot implement exceptions in it using set jump for example, but the biggest problem is memory management. You can't implement your own arena allocator in golang.
To be fair, you don't need to implement exceptions in golang because they already exist in the language, they're just called panics
Indeed, but I guess OP is saying that the panics are not supported in this language.
Re: Solod: Go can be a better C
#26It cannot be a better C. You cannot implement exceptions in it using set jump for example, but the biggest problem is memory management. You can't implement your own arena allocator in golang.
I've drastically sped up commercial shipping C code by implementing arena allocators and Go is my daily driver and it's not clear to me why you're making this claim.
Not the OP but I guess what they are saying is that since this language is a subset of go and if you use it as such then an arena allocator cannot be used in the transliterated code.
Maybe it's possible to force the transliteration to use a different allocator and then you could use the one you wrote in C?
Re: Solod: Go can be a better C
#27Yet another attempt to reinvent a better C. Curious, but unpractical. If one need a better C, C++ should be used instead.
Re: Solod: Go can be a better C
#28Go 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.
Re: Solod: Go can be a better C
#29Go 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.
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.
Re: Solod: Go can be a better C
#30Yet another attempt to reinvent a better C. Curious, but unpractical. If one need a better C, C++ should be used instead.
C++ is like PHP: it used to be a terrible language, and you can still reach for everything terrible if you wish. But during last maybe 10 years, C++ made a lot of effort to become a language with fewer footguns and more safe, high-level tools.
Still I won't start a new project in C++. If I wanted high-level features and zero-cost abstractions, I'd take Rust. If I wanted working really close to hardware, do bit-twiddling and knowing where every byte is allocated, I'd take Zig. If I wanted to write a small piece of code intended to run absolutely everywhere, including old and esoteric architectures, I would still have to go with C (plain, old).