Theres no need for any data-hazard checks in your code, the compiler will do it for you. If you want an analogy, where "ARC" freed programmers from having to manually manage memory, this is "ARC for algorithms", freeing you from having to care where the code runs.
It measures the computing environment at runtime not compile-time, and its opportunistic, so it will schedule work on the most-efficient worker at any given time - be that single-CPU, multiple-threads on the CPU, SIMD or similar hardware, GPU, multiple GPUs, or across a network via an installed daemon.
Here's some results for single-threaded CPU:
xc cf arm64 (M3 Max) x86-64 (AMD Ryzen 9 9955HX)
------------ -------------- ---------------------------
Objective-C 1.45× faster 1.24× faster
C++ (clang) 1.12× faster 1.04× slower
C++ (GCC) 1.12× faster 1.13× faster
Swift 1.44× faster 1.43× faster
benchmark 1 thread N threads GPU all auto GPU vs N threads
---------- -------- --------- --- --- ---- ----------------
mandelbrot 164 13.5 1.3 1.2 1.0 10.1× faster
md5 1349 108 4.9 5.5 4.8 22× faster
md5_mask 1064 85.2 4.1 4.3 4.1 21× faster
nbody 17.7 1.8 609 µs 1.3 1.3 3.0× faster
perlin 89.9 7.7 1.2 1.2 1.2 6.4× faster
saxpy 1.4 1.1 3.9 5.2 1.1 3.6× slower
The language itself is fairly modern (classes, protocols for interfaces, blocks for closures, callbacks, exceptions) and each platform is a cross-compiler for each other platform, so I have a binary on my iPhone which was created, compiled, and signed with my dev-certificate all on a linux box. Works great :)
At this point, it's mostly for fun, educational purposes and an attempt to build the smallest, but generally useful language with a good balance of dynamic performance, native code compilation, self hosting and a language that is both easy to learn and easy to understand it's design and implementation.
I call it Mu (µ) lang. You can find it at https://mu-lang.dev
Essentially µ is a language that has a dual runtime, Interpreter + Native code.
I've also experimented with building a full UNIX(ish) OS and Kernel in Mu itself. So that means, about ~2k Assembly, the rest in Mu. It's at about a 80/20 (Mu/Asm) and works fairly well!
So yes, Claude is able to write in Mu quite well -- But this isn't surprising, because I believe large language models sort of settle on the structure and patterns of languages and generalizes fairly well. So this kind of didn't surprise me at all.
If you have a pok around the site, you'll see why. Mu is deliberately very small and minimal. I've also chosen not to implement floating point arithmetic, because I wanted to see if I could get Mu programs to run on micro controllers one day, which many of them don't have FPU(s) -- especially the smaller ones.
Additionally, I’ve been really fascinated by the idea of a language that makes LLM observation and rewrites at runtime possible. There is an interface to get profile data and replace functions at runtime based on the analysis of an LLM.
Lastly, I’ve always wanted a language that could model more of the external environment and make those easier/safer to interact with. I think of libraries like Kysely as an example of making that easier. It’s a really cool time to be playing around with these.
—-
I poked around at this idea myself and it is a great idea to try and probably a security nightmare to implement. It also isn’t far off from what the JVM does anyway and would probably not work as well.
I actively use it for most programming, these days (command-line only), and use it every year during Advent of Code.
Today, with AI and LLVM, creating a language is probably an easier task, but I still think it's smarter to do what I did. Any language you create will necessarily be mediocre and full of bugs. Don't reinvent the wheel.