Wrote up a practical introduction to SIMD using a real example from Ghostty. SIMD has a reputation for being complex, but the common case follows a simple, repeatable shape and shouldn’t be scary! Everyone should know at least this much. https://t.co/yVcAycaq8P
Ghostty and libghostty are now on Zig 0.16! This was done by a [paid!] contributor. Through this process, the Ghostty non-profit also paid for hours to contribute over a dozen patches upstream to the translate-c and arocc projects which help the entire ecosystem. Amazing work.
Zig 0.16 came out awhile ago, but in reality it wasn't a focus of the project to upgrade until the past few weeks. It did take a few weeks to upgrade, but the primary complexity was due to C translation/integration and not Zig itself.
Zig 0.16 switched C translation from clang to the translate-c/arocc projects which are faster and a much smaller dependency.
Ghostty is a very complex C user, consuming Apple headers (e.g. blocks), Windows headers, GTK headers, SIMD intrinsic headers, and more. This stressed these upstreams and we had to fix a number of issues to get through.
This was high quality and good work though and I'm happy to see it help the ecosystem. translate-c and arocc are just excellent standalone projects even if you're not interested in Zig. They're way easier to embed than clang and solve that problem well.
Upstream patches:
* translate-c: https://t.co/jxEeVYsHpu
* arocc: https://t.co/16QetK5g4I
Since the @bunjavascript folks recently wrote about their experience moving from Zig to Rust, it seemed like a good time to write about our experience rewriting @roc_lang from Rust to Zig!
https://t.co/JkPboqnGTn
Once we have completed our review for security vulnerabilities, we will make the entire codebase of 𝕏 open source, with no exceptions.
Moreover, we will invite third party reviewers to examine the system that is running to confirm that the open source code is what is running.
Trust through total transparency is the only thing that should be believed.
One habit I see a lot, and have to push back on, is taking a tool's shortcomings and reselling them as a "puzzle game" which is "fun" to solve.
Take vim. I constantly see people praise it not for what actually makes it good, but by taking the things it's bad at and turning them into a puzzle to have "fun" solving.
I've had people tell me how "fun" it was to build a macro to handle some one-off text-refactoring problem. But when I looked at what they were doing and how long it took, my honest reaction was: I could have done that in Sublime in a minute with multiple cursors, or just written a quick script.
To be clear, I'm not saying text editors don't matter to your workflow. I'm questioning the near-religious devotion people have to a tool because it gives them a "hacker vibe"—which is basically the whole appeal for newcomers to vim or emacs.
That's what I mean by "invisible tools". When you're proficient with your editor of choice—whatever it is—it disappears into the background. But the moment it can't handle something easily, it stops being invisible. What baffles me is that so many people treat that friction—the effort of working around a tool's limitations—as the "fun" part, and then advertise it as evidence that the tool is great.
I know plenty of things wrong with my own editor of choice: Sublime. I don't dress those flaws up as fun little puzzles to solve. I just get annoyed that it lacks the tools I actually need, forcing me to write a plugin or reach for a separate program to write to transform text the way I want.
If people find vim, emacs, or whatever genuinely good and productive, I'm not going to criticize them for using it. People are most comfortable with what they know. But that same familiarity blinds them to their tools' flaws, and leads them to celebrate those flaws, flaunting them as games.
Another example in this same vein is when people advocate for terminal apps over GUIs. If you're stuck in a terminal all day, then I completely get the obvious advantage, but most programmers aren't stuck in a terminal all day.
From those people, one of the criticisms of GUI apps tends to be: "I can't navigate them with the keyboard alone".
Okay? That doesn't make GUI apps inherently bad. It just means the GUIs people build aren't good enough to be keyboard-navigable. There's nothing inherently impossible about making a GUI work with a keyboard, rather it's just that most people never bother, because they don't realize how much more productive keyboard navigation is than reaching for the mouse.
And this is a common mistake: people look at the current state of a category of tools and assume its current limitations are inherent, when really no one has put in the work to make those tools better.
A good tool is and ought to be invisible—striving to make such tools.
there are a lot of benchmarks that suggest 5.6 sol is the best model in the world right now, but the most reliable way to tell is that elon is obsessed with me again
Based Andrew Kelley.
Zig VS Rust is irrelevant here. I will always support real engineering with real thought behind it, over slop produced by tired computer programmers - no matter how technologically impressive the slop machine is.
fun fact nobody asked for: at 11:15 UTC today the sun shines on 99% of the world's population simultaneously. 8 billion people, one sunbeam. anyway good morning