octalide

Fantastic stuff! You should join the discord if that's your ballgame. If you DO run into problems, make sure to post an issue or let me know on discord!

As a note, I've made some massive upgrades to stability and the release pipeline since this post if you're still interested in the project.

Absolutely. We have the ability to match the performance of C very easily in the future. Priority is fleshing out the compilation target backends, but that's coming after.

We're "fast enough" for the time being, but we can always be faster ;)

The performance is definitely something I'm happy with at this early stage. A few optimizations get you a LONG way. I'm glad to hear that you found it easy to read (that was a main goal of the design)!

Thanks for actually reading code :)

Yes LOL. This was a little bit of an oversight on my part from back in the day. Mach can produce MachO binaries (no affiliation) that run on the Mach kernel (no affiliation). I see it as more of a funny coincidence than an impending lawsuit, though. Maybe one day we'll change the name if a single letter ever becomes free XD

Partially, yes, but not in the way you're thinking.

LLMs have done a significant amount of the "typing", but I was behind the wheel at every stage of development and wrote almost the entirety of the original compiler designs by hand.

There was no point in development when I said "claude, write me a programming language". I simply would not have been able to finish this project in my lifetime by myself without the assistance of LLMs in both the scale and speed that they can operate as well as using them as an accelerated learning tool for myself. It's been a great boon to this project and I have zero regrets :)

Please do! I've barely touched macos since I don't have the ability to properly test it from my end. If you want to take a crack at it, feel free to work on some of the open issues related to it!

To build mach from the archived bootstrap compiler, you need clang. That's it. git to clone the repo and a C compiler. That goes all the way through the self hosted compiler. Mach doesn't rely on LLVM, doesn't link to libc, doesn't use system linkers for object file management, etc. Everything is "in house".

You can shoot your legs all day in mach. There is no such thing as unsafe code, just poorly designed code.

The stdlib has patterns like zig's allocator design as well as Option and Result types that are used frequently through the stdlib itself and other projects written in mach. Achieving safety is very possible, and entirely optional.

That's a good point. I was thinking about that specific thing this morning (how the documentation doesn't fill it out properly).

Here's an easy comparison list for you. Mach vs:

- C: More modern and consistent syntax with a dramatically simplified tooling system (no 3rd party tooling required out of the box, even for dependencies).

- Go: More control over the "nitty gritty" stuff that go abstracts away too frequently. No garbage collector. Honestly, I love Go and lots of inspiration was taken directly from it, so I have no beef with the language lol.

- Rust: Dramatically simpler language to use. Flat out. Rust's tooling and ecosystem is the best bar none... but then you have to write code in Rust ;)

- Zig: Simpler version of a similar language philosophy, but without the "features" that can often become footguns like the metaprogramming system zig uses for types. Zig is a great example of a language done right, but I do personally feel that it attempts to make some things "do more" than they should. I'm also not a fan of the syntax personally lol

Thanks! The speed is almost entirely a dramatic optimization difference. From what I can tell, most of that difference comes from vectorization (like you stated) and other things like target-specific machine code optimization happening post-codegen.

Mach will eventually get to that point for most targets (or as close as possible). I stated 4x slower as the worst case I've observed so far. In some cases, we were only about 1.3x slower which is fantastic IMO.

LLMs were critical for me to be able to do this. I did not understand how compilers worked when I started this project. Once I was able to understand it, having an LLM churn out the enormous amounts of code was the only way for me to ever have been able to practically release a working codebase in a reasonable timeframe. It leaves a bad taste in peoples mouths (even mine), but it's an invaluable tool that simply can't go overlooked these days. To say mach was "vibe coded" is completely incorrect. To say it was largely "implemented" (typed out) by an AI is far closer to reality. I plan to use that tool for the rest of my career.

That's okay if you prefer something else! Mach isn't made to be the "please everyone" language! I'm glad you took the time to check it out and shared your opinion with me :)

I played around with an entire branch of the language that used a zig-style meta programming type system and it ended up just getting in the way more than it helped.

The only thing I may consider in the future is something along the lines of a VERY weak macros system, but that's a highly well explored and well known footCANNON that I'm not keen on implementing. I do have designs in mind if it ever becomes an essential, but for the foreseeable future, any sort of metaprogramming is practically off the table.

On safety... That's a big one. I'm absolutely prepared to take smoke for that all day and I know I will be. Memory management is one of those problems that every programmer has to deal with at some point in their career, whether it's fighting a GC, fighting a borrow checker, or fighting poorly written code. I decided to go "back to basics" and encourage programmers to fight their own knowledge of the system and to be more aware of the code they are writing. Yes, that means that it can be more difficult to write code that is... "safe"... but when it comes down to it, Rust and C are both compiled to CPU instructions that have no concept of memory management intrinsically. Taking the load off the developer has the side effect of removing total control with it. In my opinion, it's a situation of throwing the baby out with the bath water for a benefit that can be fully achieved through best practices and proper understanding of the code you're writing. Does that help clarify my stance? I hope it does lol

Glad you took the time to explore the project! Thank you for that!

You may not be the target, but that does not invalidate that point. My personal view of the what is and isn't hidden behavior is definitely something that will rub a LOT of people the wrong way. That being said though, this project has grown out of the scope of "fun personal toy" and is intended to be embraced by other developers. If those developers don't want to use the language, then that could be viewed as a fault of the language.

This entire system was designed by ONLY myself up to this point, so I've effectively had blinders on the entire time. I personally like the drastic simplicity of the language, but if it gets in the way of the majority of the users who want to work with the language, then at a very minimum, a conversation should be had about the pain points. Finding that balance between being appropriately hard-headed and willing to adopt features I may not have originally intended to adopt is a difficult line to balance on.

Thank you. Took a long... long time to get it to even this stage, and there's so much more left to do.