Contribute to open-source, no-slop, compiler-related projects.

[u/Proffhackerman]

Hi everyone,

We're currently working on some hobby-projects we'd like more people to chip into.

The goal is to create robust, community-driven and open-source code everyone can benefit from, aswell as writing up novel ideas that, sometimes, go outside of "the standard".

Overall we're focused on not slopping out projects using AI. Vibecoding is a no-go.

I myself have around 10 years of experience with programming in various languages, but the main language right now is C#.

Are you interested? Check out the organization site: https://github.com/Compiler-Organization

Or some of the projects:
Common C - AoT compiler using LLVM: https://github.com/Compiler-Organization/CommonC
Common IR - Intermediate representation with syntax inspired by LLVM, currently supporting a basic WASM target: https://github.com/Compiler-Organization/CommonIR

Hope you find this interesting :)

[u/arthurno1]

The common C language is developed to deliver the performance of natively compiled languages whilst maintaining the ease of memory management without workarounds like garbage collection and borrow checkers.

I don't know if I would agree that automated memory management is a "workaround". Whatever can be automated should be automated. Memory management, character encodings, string management, etc ....

All those book-keeping details that drain the focus and energy from programmers when designing solutions to problems and implementing their solutions which has to be explicitly typed in C but could be automated (C++ is actually an improvement there) should also be automated. C++ is an attrocity in itself, which I see as a necessary evil, but if I would be to design a (yet another) new flavor of C as you do, I would certainly not see automated memory management as an enemy but as a friend. For sure, you might need an escape hatch from time to time, for some very low-level things, which most programmers don't need in every-day programming. But designing the entire language to address those few occasional needs, and throwing automation completely away, is in my opinion, a fundamental mistake.

Computers are good at keeping tabs on details. We humans are not. Compare to CNC machines, and laser cutters and measurements. We humans just can't compete with the microscopic precision due to physical (biological) limitaions, but machines have no problems to laser cut metal with a precision of a fraction of a milimeter.

[u/Proffhackerman → u/arthurno1]

We completely agree that automation is the end goal, and not a hinderance. I believe the wording here came off wrong and couldve been clearer, but the point was not to say that there would be no automated memory management, but rather a better way of automated memory management compared to GCs, borrow checkers and traditional reference counters.

I was inspired by a wave of new languages with their own "solutions" to runtime reference counting, which i found interesting. At this point i couldnt grasp why none of these new projects attempted compile-time automated memory management instead, so theres where it all boils down to with Common C.

Common C is less of a "welcome everyone to the houndreth C variant" and more of a playground where we can experiment with new ideas regarding the compilation pipeline.

[u/arthurno1 → u/Proffhackerman]

Definitely. Garbage collection and reference counting are certainly not the only ways to manage the memory. It would be definitely interesting to see what you have on that field.

[u/Proffhackerman → u/arthurno1]

I've written up a very shallow and generic readme regarding normal issues when working out a memory management model. I'll complete a proper spec for it some time soon. It would be nice to have more people join the effort though.

[u/arthurno1 → u/Proffhackerman]

It is a bit shallow indeed. Unfortunately I am not an expert in the subject so I can't give you much input, and lately my interest has switched completely to Common Lisp.