ZH version is available. Content is displayed in original English for accuracy.
I'm the creator of Mach (https://github.com/octalide/mach or https://machlang.org). Two days ago, we finally achieved full self hosting. I wanted to make a post here to show off the language since this is a big milestone for us.
## TL;DR about the language for those curious:
- There are no external dependencies anywhere in the pipeline. This includes LLVM, libc bindings, or anything of the sort (save for the historical bootstrap compiler, which requires any C compiler and has been phased out completely).
- Mach is extremely opinionated and very anti-magic. WYSIWYG is a core principal for the language. There are no hidden behaviors, implicit type conversions, or "automatic features". Simplicity and stripping away ambiguity are core principals that this language upholds.
- Performance currently lags behind C by about a factor of only 4x at the time of writing, almost entirely due to the lack of deep compiler optimizations like autovectorization, which have not been fully implemented yet. Eventually, Mach will be at least on par with C.
## Why did I build this?
I love low level systems languages like C, Zig, Go, and (sometimes) Rust, but I wanted something that actively discourages "cleverness" in favor of long-term maintainability and overall clarity. Mach is highly opinionated and explicitly demands verbosity in ways that other languages are afraid to. Computers aren't magic, and code you write should not pretend they are. This project initially started out as a learning opportunity for myself, but grew into a fully featured language as time went on. There is still a lot I have to learn, however, and I'm excited to be able to do so as this project continues to grow into the future.
## Why do I (the reader) care?
If you like C, you'll probably like Mach. Mach takes heavy inspiration from the "vibe" of writing C, but improves on much of the syntax, lacks quite a few footguns, "unhides" a lot of internal mechanisms, and has a FAR better dependency management system.
If you want to play around with a language that is fully capable of replacing C, and especially if you would like to contribute to its development, then PLEASE stop by and mess around.
## Where should I go to check it out?
The github repository has a link to our discord if you'd like to chat with myself or our few other regular users. My personal account has all of the tooling that exists as well as a few example repos if you feel inclined to try it out.
## Will this project by dead in X months?
I've been working on this in the background for over 2 years now. This is a long term project that I plan to maintain into the indefinite future, with or without a userbase. If you like the language at all, I highly encourage you to get involved in its development because it WILL be sticking around in some capacity forever.
I know this was a bit "rambly", but let me just say that it's been a great joy to work on this project and I would love any and ALL opinions and contributions, ESPECIALLY if you hate the language or find a problem that needs fixing. Let me know what you guys think!
Discussion (25 Comments)Read Original on HackerNews
As the developer, where do you land on meta-programming for the language? I applaud the straight up nature of ‘the battery will never be included’ and the reminder to consider the possibility of a feature being a library instead of a syntax or language feature. I certainly don’t think meta-programming is essential, but the ability can contribute to the ease of use for library code.
And I’ll ask now since it always comes up, where does Mach stand on ‘advanced’ type theory uses for ‘low-level’ programming? I noticed the admonition that safety is the developers job which is sure to bring some ‘heat’ from the memory-safety-is-table-stakes crowd, in light of that, where does Mach stand regarding ways to ensure ‘safety’?
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!
I think that your conception of cleverness is too wide basically. It's true that, in my opinion, any new programming language today should stop people from C-style "cleverness". But there are languages where the clever programs are actually the pretty ones. For example, the borrow-checker in Rust encourages good code design (and yet it still can be better). And most importantly, algebraic types constitute a radical improvement over classic C-style code. You may think that they hide what's happening, as they have a hidden tag and could be built from C structs and C unions. But after thinking a lot about it, thinking about the tag is actually not thinking about the program's behavior. There is a difference between the program you want to write, and what needs to happen on the machine to compute it. I could probably write a lot about the solution I found to reconcile both opinions, but my project is a lot newer so I can't redirect you to anything yet. But I think that by wanting a more grounded language, you are maybe dismissing too many ideas that would actually encourage programs to be clear and transparent while still not doing anything automatically with magic (and at the same time, would dismiss incorrect programs, that C can express but that machines cannot execute).
Btw, I understand that I am probably not the target of your language, so I won't expand much further unless you want.
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.
To those who criticize use of LLM in projects like yours, I demur - where there are productivity gains to be had, LLMs can make small niche FOSS projects like yours more viable and less drudgery.
I prefer a concise language btw:
This is more by way of saying let 1000 flowers bloom.(The main strength of Raku is its built in Grammars https://slangify.org)
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 :)
That said, it seems pretty damned impressive to me that mach is only four times slower than C, particularly since you've only worked on it for two years.
I like the syntax. The example code and a couple files in src I looked at were all easy to read.
Thanks for actually reading code :)
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
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.
It's incorrect. In many programming languages there is a clear separation between safe and unsafe code - via special unsafe blocks or something similar. Languages without such separation are always unsafe or (rarely) always safe.
So, I assume Mach is fully unsafe, like C is.
Is it yet another LLM-generated project with little human-written code?
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 :)