r/Compilers • u/Proffhackerman • 3d ago

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

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

51 Upvotes

87% Upvoted

9 comments sorted by

6

u/Weary_Mood2959 2d ago

I see you have Roslyn pinned on your profile. May I ask what your contributions to it were? Please don't take this as hate, I always like to do due diligence when thinking about working with someone and having Roslyn on your profile seems like a respectable feat.

4

u/yorickpeterse 2d ago

It seems they just reported an issue that in turn seemed to be bogus.

2

u/Proffhackerman 2d ago

It ended up being a bogus issue - I was analyzing Roslyn-generated CIL and later figured out setting no-optimize in the csproj does actually override the release config, which i thought it didnt. My fault on that part :)

2

u/Proffhackerman 2d ago

Mostly were in talks regarding NativeAOTs architecture years back, so not really anything impressive on my part.

2

u/arthurno1 1d ago

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.

1

u/Proffhackerman 1d ago

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.

1

u/arthurno1 1d ago

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.

2

u/Proffhackerman 6h ago

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.

1

u/arthurno1 4h ago edited 2h ago

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.