It is indeed the goal to have a language better than (or at least fixing some of the pain points of) ObjC, and to make it truly cross-platform and just as easy to grok. Coming from C, I think ObjC was pretty much at the sweet-spot for complexity vs flexibility - there’s only a few things you have to learn over and above C and you get so much from that little extra.
I’m already using it in one big project - and now this mentioned on HN has utterly failed [grin] I can put a link to https://blewit.net/ - the site isn’t really ready yet, another 6-8 weeks before launch, but if you want to see some of the WASM results, click on the sandbox link :)
On the server side of blewit, everything is in xc, no apache, no scripting, and it uses the same classes there as it does in the WASM client. Plenty of C libraries compiled in with #use and then just linked: TLS, redis, Postgres libpq, …
The compiler is mainly written with AI, but with a lot of supervision - those 6 months have been pretty much non-stop, with me being retired, and since I used to work for Apple for a couple of decades I have opinions on what the compiler should do (or not do) :)
It started off as a project to write a new language for the 6502, if you look at https://atari-xt.com/ you’ll see a striking similarity in the website style... I knew I’d want more than one back end (st and xl) so from the start there was this idea of an IR that was flexible enough to handle register-rich and register-poor architectures, then I thought it’d be kind of useful to be able to write and test code on the Mac without loading it into the FPGA, so it was scaling from 8-bit to 64-bit pretty much immediately, with different executable formats; once that ground was laid it wasn’t too hard to extend it to the current multiple platforms.
The optimiser is pretty thorough in terms of the classical operations. Where it still lacks is automatic vectorisation, clang vectorises code in lots of places you wouldn’t expect, but it also has a huge head-start over xc. Right now we’re sometimes on a par with a clang-compiled C program, but otherwise between 1.1x and 1.8x slower. There has been the occasional micro-benchmark where xc comes out faster :) I don’t actually have a benchmark suite, this is more informal testing during developmentof the optimiser and that’s something I should fix, not least because it’ll show where the next “bang for the buck” will be.
It’s worth mentioning that most of my optimisation tests have been pretty low-level, so the clang version is written in C to make it easier to understand the assembly for this mere human, and xc has a bit more overhead with its automatic reference counting code, so a better future test might be to compare vs ObjC.
Originally, I wrote up a 300 (or so) line spec for the language, and another spec for the IR, because it had to include automatic and transparent banked-memory use on the 6502 (so pointers were 3-bytes {bank, hi, lo}). Coming from using modern ObjC, I wanted ARC from the start, so that was built in, but it was only extended to blocks and callbacks (a callback is a ound function, an {object,method} or {nil,function} tuple) when we got onto the serious architecture support. It’s been “interesting” supporting a machine that doesn’t even support ‘mul’ alongside one that has vector simd :)
Overall, I’d say the AI has done maybe 80% of the work, possibly 85% if I’m being generous. There have certainly been times I’m in the code changing things because it’s easier to express the difference between what it first came up with, and what I actually want, in actual code rather than English. On the other hand, I’d never even have attempted such a large project on my own. I see the AI as a massive force-multiplier on what can be done. It doesn’t get tired, it prevaricates (“I don’t want to make such a large change without <insert nonsense>”) a lot less than humans, and it has alot of knowledge to draw on.
One other thing I guess I should mention is that there is also the beginnings of a cross-platform UI framework, which uses an AppKit-like binding (you get things like TableView, CollectionView, OutlineView etc, with datasource protocols and delegates) but binds to the native widgets to provide a native look/feel/interaction from the same AppKit-like source. The docs go through it in more detail.
This is only about 50% done, there’s a lot to finish off here. It helps that String in xc is native UTF8, but the binding part takes time. The fallback default is to draw the widget if there’s no binding, and until you pretty much 100% cover the native UI for a platform, it can look a bit jarring.
Alongside that, there’s a tool ‘RoCkS’ which is even younger (maybe 10% there) which is intended to be the equivalent of Interface Builder. RoCkS is spelt that way because of the original atari origins... the GUI designer for GEM was "RCS" - Resource Construction Kit :) You design your UI with drag/drop and springs/struts, then bind UI objects in various layouts {desktop, tablet, phone} in {portrait, landscape} to the same core codebase. All with drag/drop, just like in Interface builder. Then the same application code can use a ‘phone’ UI layout when you compile the iOS/Android version, and use a ‘desktop’ layout when you compile a Windows/Linux/Mac version etc.
At that point, I might re-announce on HN, because free and open-source cross-platform (and easy multi-platform) UI isn’t that common :)
Again, thanks for the interest :) At least I got 1 comment :)