31–40 of 188 posts
That hadn't really occurred to me before.
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.
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…
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?
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?
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.
> 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?
- Everything in the language is statically allocated or stack-allocated. You have to call a malloc / free function to get heap allocated things
- The language is not memory safe (you can't return slices, pointers, or interface types from a function if the thing was created inside the function, unless you used heap allocation)
- Interfaces (the only variable size struct Go has) are implemented by creating a struct of function pointers. Arrays and maps (the non-struct variable size types) are implemented as stack-only and maps are limited to 1024 keys. You can opt into heap-based arrays / maps in the standard library to bypass this.
> 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?
The answer is apparently "you don't": - Everything in the language is statically allocated or stack-allocated. You have to call a malloc / free function to get heap allocated things - The language is not memory safe (you can't return slices, pointers, or interface types from a function if the thing was created inside the function, unless you used heap allocation) - Interfaces (the only variable size struct Go has) ar…
Yet 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-twiddl…
Why not C++? It allows as many low-level operations as one wishes, but don't forces you to manage memory manually where it isn't necessary.
> If I wanted to write a small piece of code intended to run absolutely everywhere
GCC and Clang have support of C++ since many years. Is there any modern platform for which no GCC or Clang backend exist?
Yet another attempt to reinvent a better C. Curious, but unpractical. If one need a better C, C++ should be used instead.
Those two languages are on the opposite ends of any complexity scale. Someone looking for a better C has a ton of options before getting to "lets use C++ and ask our devs to practice discipline".