The Scar Programming Language

Looks incomplete. I got intrigued by:

> Optional garbage collection. The standard library will work with or without the GC.

but the corresponding section in docs (Memory Management -> Optional Garbage Collection) returns 404 for me. And the other docs make it not clear.. for example "heap" section [0] makes no mention of how to deallocate things. And json stdlib [1] has many allocating methods which return "json_t pointer" and yet make no methods for de-allocation.

I wonder if when they say "The standard library will work without the GC" they imply "... but no objects will get de-allocated ever and memory usage will grow infinitely"

[0] https://scarlang-docs.pages.dev/heap/

[1] https://scarlang-docs.pages.dev/stdlib/json/

Looking at Scar through the eyes of a senior developer the reaction is more curious than dismissive. There is a bit of surprise because in the past system languages were almost always implemented in C and that was considered a mark of seriousness. Now we see an example built on Go and that shows how approaches are shifting. The choice of Go has strengths like simple syntax, fast development cycle, built in support for concurrency, and good infrastructure. At the same time there are compromises like weaker memory control compared to C and some runtime overhead which can be critical for low level languages. Scar looks more like an experimental attempt to propose a new view on language design with emphasis on simplicity, immutability, and optional GC. As an engineer I find the idea interesting but its value can only be judged when real use cases appear and we see how it behaves under production workloads and whether it can compete with Rust or Zig.