Alex Kladov (matklad), a Rust and rust-analyzer developer, writes about Rust, Zig, parsing, tooling, and software architecture.
Commenters recommend it as a good blog and cite posts arguing Rust's noisy syntax comes from its semantics and describing what Zig comptime won't do.
I can tell you a bit about my own experience, as I've I used Rust for two years, but have now transitioned to Zig. I started working on a modular synthesis engine, and I realized that Javascript wouldn't give me the granular control I needed. So I decided to use Rust. This was my first foray into low level programming, so learning Rust first was great because I internalized their ownership rules. However, I started to realize that Rust was doing quite a bit of stuff behind my back, like freeing objects when dropped, or making allocations when I inserted an item. This is a big no-no for realtime programming, and Rust didn't help me understand what was happening. It was then that I read matklad's blog post on rust hard mode, https://matklad.github.io/2022/10/06/hard-mode-rust.html. I looked at some of his other blog posts too, and saw Zig. So Zig had been in the back of my mind for a while, when I decided to port a Tcl interpreter to Zig. I've been about 7 months in now making my own interpreter, and it's been a delightful language. Yes, I've had my share of memory leaks and double frees, but the debugging trace lets me capture a stack track at each reference count increment and decrement, so I'm able to hunt them down pretty well. I'm also hyper aware of memory layout and allocation failure, because allocation is fallible in Zig. The error union handling makes it pretty easy to propagate OOM though, so it's not hard to make code that's resilient to OOM. If I had tried to make…
You might this blog post interesting, which argues that it's Rust semantics and not syntax that results in the noisiness, i.e.: it's intrinsic complexity:
https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html
I found it reasonably convincing. For what it's worth, I found Rust's syntax quite daunting at first (coming from Python as well), but it only took a few months of continuous use to get used to it. I think "Perl-esque" is an overstatement.
It has some upsides over Python as well, notably that the lack of significant whitespace means inserting a small change and letting the autoformatter deal with syntax changes is quite easy, whereas in Python I occasionally have to faff with indentation before Black/Ruff will let me autoformat.
I appreciate that for teaching, the trade-offs go in the other direction.
I was a Magit user for most of a decade and I deeply missed it when I first switched to jj. I still think something like it would be a huge boon for the community and I hope one comes to fruition eventually, but in an editor-agnostic form like matklad suggests here:
https://matklad.github.io/2024/12/13/majjit-lsp.html
With that yearning in mind, jjui is the jj TUI I like best so far having tried them all. It's snappy, has useful and intuitive keybinds and presents them well, and good stability so far. Doesn't quite seem to like it if I resize the surrounding zellij/terminal pane while it's open though.
Lazyjj was a little laggy and crash-prone for me on all of the same repos, and jj-fzf is a tragic pile of bash so I can't recommend ever using that.
This one looks good to me. https://matklad.github.io/. Coincidentally the author has recently posted about CSS for blogs https://matklad.github.io/2026/06/04/css-unavoidable-bad-parts.html.
I have my own blog, but I'm unhappy with its design as well; therefore I'm not sharing it. Nevertheless, I find particularly challenging two things:
1. Make tables readable from a smartphone. There are a few tricks which allow you to make a responsive table. However, those tricks implies that you use <ul> or <div> instead of <table> which defeats the point of having a table.
2. I had an article where I needed to put a tiny mind map. Eventually I put it as a picture, because the solutions to draw a mind map with JavaScript made the page as twice as heavy.
>The first sentence is literally, “An introductory post about complexity theory” but then goes on to assume we know about complexity theory.
I think the confusion is that the author is using "an introductory post" as a synonym for "my first post". In this meaning, "introductory"=="opening/initial/first".
He didn't mean "introductory" as in ExplainLikeIAm5 tutorial from basic principles.
The "this is my first post" interpretation makes more sense when you see that all his previous blog posts were not about NP complexity : https://matklad.github.io/
This first introductory post about NP complexity also implies a planned series of future followup posts.
> Despite the invalid example, the point still stands. Put arbitrary Rust against Python or Typescript and you'll see it immediately.
Eh, I don't think that is fair, Rust even at best of times will have concepts like lifetime/references that Python and TS can just ignore and are thus "simpler".
A much better comparison would be something like https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html.
> and do away with snake_case.
That's seem counterproductive - according to: http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf.
I.e. you would do with most readable part of syntax.