The idea of using a subset of an existing popular language is very wise IMHO. We can (and apparently are) debating the merits of the language runtime, but what a subset gives you is immediate access to a large pile of existing tooling that you'd have to write yourself, eg linters, formatters, lsps, etc. Stuff that is purely source-oriented.

That hadn't really occurred to me before.

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.

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.

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.

There is Biscuit from OSDI 2018 https://pdos.csail.mit.edu/projects/biscuit.html

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

The author's original blog post, which goes into some more detail: https://antonz.org/solod

How does it deal with pointers if everything is stack based? You can't really return a pointer to something on the stack because it could get overwritten between when you return it and when you access it.

Exactly as well as C does, it seems.

    func newPerson() *Person {
        p := Person{Name: "Alice", Age: 30}
        return &p
    }

becomes

    static main_Person* newPerson(void) {
        main_Person p = (main_Person){.Name = so_str("Alice"), .Age = 30};
        return &p;
    }

Quoting the FAQ: "So itself has few safeguards other than the default Go type checking. It will panic on out-of-bounds array access, but it won't stop you from returning a dangling pointer or forgetting to free allocated memory. Most memory-related problems can be caught with AddressSanitizer in modern compilers, so I recommend enabling it during development by adding -fsanitize=address to your CFLAGS."

So saying you get the "safety of Go" is a bit of a stretch.

Yeah that's not great. It's easy to be faster than go if you haven't thought about memory management yet. I bet go with GOGC=off is faster than plain go too.

Well, it does say:

"Everything is stack-allocated by default; heap is opt-in through the standard library."

So it supports both stack and heap, and I guess static allocation too.

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

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?

I really like this idea. I was reading a post earlier about how Go generics are implemented, and how they're sort of leveraging root GC-types in the "runtime" to avoid the same bloat as monomorphization causes in, say, C++. I wonder how Solod will do that? I guess plain monomorphization? I guess that's fine since C compilers are so speedy.

I've been using Go and Raylib to make a game lately and I really don't have a problem with garbage collection. It's so fast that it's not having an impact on my frame rate.

I was a little worried at the start because nobody would normally consider Go for games, but I did a bunch of tests and found it's just no big deal.

(I'm focused on game play and not interested in pushing hardware to its limits.)

I’ve been considering using Odin and Raylib for this because of its similarities to Go, but using Go itself is appealing. Do you have any good resources for what you’ve learned, or is it an unexplored frontier?

I’ve used Odin and Raylib for some prototypes, and it’s terrific!

I don't know If I can be very helpful, I'm using gen2brain's binding [1].

I started about a year ago asking the AI very beginner questions about Go and 3d math. I think it did steer me down some wrong path sometimes and of course I did some dumb things myself too. I'm not using Agents, just asking questions about features, then writing the code myself by hand.

I really like the power of the tools and the constraints of the language in Go. It's been fun so far.

[1] https://github.com/gen2brain/raylib-go

It's interesting you would mention Odin because I spend a fair amount of time playing with it as well. It was easy to get started and fun. Fast, easy to iterate. The reason I moved away was not the language itself, but I felt it was too much Ginger Bills baby. Oh, and managing memory is no fun. I want to make game play, not think about allocations :)

i've been using Go on backend now all the time.

Wish something like this existed instead i am stuck with flutter and react native on Mobile.

When will a time come when i can use some functional languages like Haskell or a plain boring language like Go for making apps with OTA ability for mobiles.

As vibe coding takes over, app store approval will become slowerer and OTA is really great when you need to make quick changes!

You can OTA each day and do base app release to store once each week.

i think this maybe the space where very little work is being done.

Not sure of your exact constraints but is something like this useful?

https://hyperview.org/

Insert Look What They Need To Mimic A Fraction Of Our Power meme here.

This is a very exciting project; love writing go with the tooling, but I miss writing C from my getting started days

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

It cannot. C is a wonderful language that makes me smile every time I pick it up. A truly universal tool that lets you go wherever your heart desires. Go is a prison designed to enforce a bleak uniformity on all of it's users. For only by painting everything a uniform gray can we ensure we are all equal.