Ruud van Asseldonk
ruudvanasseldonk.com · Personal blog · on HN since 2014
Ruud van Asseldonk, a software engineer, writes about Rust, type systems, build systems, abstraction, and configuration languages.
What HN saysHN links it for the YAML critique and the 'neither necessary nor sufficient' essay on garbage collection, and commenters also admire the site's design.
48HN people shared it
24linked it in comments
47stories submitted
2.4Kstory points
8 months agolast shared
2014people per year2026
Most-shared posts
- 1YAML document from hell (2023)16 people · 250 points · first shared 2023 · 142 comments on HN
- 2Zero Cost Abstractions5 people · 369 points · first shared 2016 · 110 comments on HN
- 3Abstraction, not syntax4 people · 105 points · first shared 2025 · 65 comments on HN
- 4Neither necessary nor sufficient4 people · 10 points · first shared 2015 · discussion on HN
- 5Build System Insights4 people · 8 points · first shared 2018 · discussion on HN
- 6Writing a path tracer in Rust, part 7: conclusion3 people · 12 points · first shared 2014 · discussion on HN
- 7Model facts, not your problem domain3 people · 9 points · first shared 2020 · 3 comments on HN
- 8A type system for RCL (2024)3 people · 5 points · first shared 2024 · discussion on HN
- 9On benchmarking: "measuring performance is hard" (2017)3 people · 5 points · first shared 2017 · discussion on HN
- 10A reasonable configuration language2 people · 141 points · first shared 2024 · 109 comments on HN
- 11Exceptional results: error handling in C# and Rust2 people · 85 points · first shared 2015 · 89 comments on HN
- 12Passphrase Entropy2 people · 1 points · first shared 2014 · discussion on HN
- 13A language for designing slides2 people · 1 points · first shared 2017 · discussion on HN
- 14Homepage2 people · first shared 2017
- 15Please put units in names1 people · 1.3K points · first shared 2022 · 594 comments on HN
What HN people wrote when they linked it
edem · 2017-02-06
[This] site is my favorite in this regard:
[This][https://ruudvanasseldonk.com/]
jerbear4328 · 2024-01-21
Seconding the sibling, YAML may look nice but it's absolutely full of awful confusing behavior. If you don't like JSON for human-written stuff, see TOML or the like. I think JSON is great for serialization, it's so simple, but I agree we need something more readable like TOML for human-written data.
https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell
ruuda · 2020-06-11
Hi Napolux,
It looks like your site is using a theme based on my website (https://ruudvanasseldonk.com/, source at https://github.com/ruuda/blog). That is fine — it is open source after all, licensed under the GPLv3. But I can’t find the source code for your site, and I can’t find any prominent notices saying that you modified my source. Could you please add those?
dpc_pw · 2019-05-15
I don't really understand why people would want a GC over deterministic destruction like in Rust. GC is [neither necessary
nor sufficient](https://ruudvanasseldonk.com/2015/10/06/neither-necessary-nor-sufficie… Ownership model in practice is much more convenient precisely because objects can act like resources and implement their cleanup logic, and the business logic can rely on it. It's a great improvement in any imperative PL.
I have (re-)implemented couple of real-life projects, and each time Rust was much better higher-level language than eg. Java, Python or JS. Borrow checker fights are non-issue in practice: just avoid references, pass messages as copies and when you have to share data use `Arc` and copy on write (or just add `Mutex`).
There's a reason why Rust is most loved PL for 4 years in a row. Once you try it, and get past initial adjustments (mosty: what owns what relationship) everything clicks, and I guarantee that you won't miss GC at all.
larkost · 2025-11-17
Yes, the features in YAML absolutely get in the way. The "Norway problem" for example ("no" translates to "False" in versions prior to YAML 1.2), but that is just the one more people ran into. Here is a nice overview of some of the problems:
https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell
I would argue that most, if not all, of those problems stem from too many features.
boobsbr · 2025-10-23
> YAML whitespace is cursed
YAML itself is cursed: https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell
freetonik · 2025-10-15
Related (from recent posts on HN): https://ruudvanasseldonk.com/2025/abstraction-not-syntax
I really like the idea of color representing scope and relatedness, rather than syntax.
lanstin · 2025-02-28
I think that prospect (of programmatically structurally editing markdown files) would have made everyone burst out in laughter in 2000; if you want to programmatically alter stuff, put it into sexp's or some other syntax. SGML. Apparently human readable but really a tricky format leads to this sort of thing: https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell
orphea · 2025-02-24
Many people explained it better than I ever could, so let me defer to them. TL;DR: YAML is an overcomplicated spec with too many footguns.
- https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell
- https://www.arp242.net/yaml-config.html
- https://noyaml.com/ (couldn't not mention this famous piece)
manuel_w · 2024-10-02
Which edge cases do you mean? Are you confusing it with YAML? I know YAML has some serious footguns [1]. In JSON I'm not aware of any.
[1] https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell
alexey-salmin · 2024-05-06
No, it's not fine at config. It's a bag of weird corner cases and incompatible revisions which you have to debug instead of doing your actual work.
Here's a good summary: https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell
js2 · 2024-02-04
The author mentions Jsonnet in the appendix[^1]:
> I never properly evaluated Jsonnet, but probably I should. Superficially it looks like one of the more mature formats, and in many ways it looks similar to RCL. Its has a page comparing itself against other configuration languages.
[^1]: https://ruudvanasseldonk.com/2024/a-reasonable-configuration-language#…
cryptos · 2023-11-09
I like the idea, but I don't like that this is one more system that should be configured with YAML! Why not something cleaner and more robust like TOML?
https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell
sophacles · 2022-08-01
Your "run-time" code with iterators vs with a hand made for loop tends to result in the same set of instructions. Often the iterator usage will also enable optimizations that make the loop faster.
* https://github.com/mike-barber/rust-zero-cost-abstractions
* https://carette.xyz/posts/zero_cost_abstraction/
* https://ruudvanasseldonk.com/2016/11/30/zero-cost-abstractions
jingwen · 2018-12-26
You may enjoy this article: https://ruudvanasseldonk.com/2018/09/03/build-system-insights
Ruud-v-A · 2017-10-28
While it does not solve your use case, others here might find it interesting: I built a domain-specific language for designing slides (https://github.com/ruuda/pris#readme). It is superficially similar to LaTeX/Beamer/TikZ, but it has first-class graphics that are reusable. More motivation in this blog post: https://ruudvanasseldonk.com/2017/04/27/a-language-for-designing-slide… It is still basic, but I have used it a few times to do slides nonetheless.
vvanders · 2016-12-28
Here's a good example, fresh off of the first result from Google:
https://ruudvanasseldonk.com/2016/11/30/zero-cost-abstractions
phaylon · 2015-05-12
Do you mean this[1] port? I can't remember one that had statistics on incremental builds during development, unfortunately.
[1] https://ruudvanasseldonk.com/2014/10/20/writing-a-path-tracer-in-rust-… (See "Performance")
zupa-hu · 2024-07-19
I enjoyed the thoughtful article.
It's interesting that type checking happens at runtime so there is no compile time, only runtime. It seems this would make it acceptable. But I wonder if the assumption will always hold.
The assumption:
> The program doesn’t even have any inputs: all parameters are “hard-coded” into it. [1]
Will that always hold? What about environment variables? If the language ever needs to handle parameters, this assumption breaks and thus compile time and runtime will be separated.
Other languages like Go would force you to insert type assertion which is the same thing just explicit. I forces you to "approve" what's happening, and that's a good thing.
There is the saying that every configuration language will eventually evolve into a full blown programming language. I guess it's all about the real world proving the underlying assumptions to be incorrect.
[1] - https://ruudvanasseldonk.com/2024/a-type-system-for-rcl-part-1-introdu…
armchairhacker · 2024-01-23
To me YAML seems like the CoffeeScript of JSON, and unlike CoffeeScript I don’t understand why people are still using it.
I guess XML and JSON are too verbose. But YAML is so far in the opposite direction, we get the same surprise conversions we’ve had in Excel (https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell). Why is “on” a boolean literal (of course so are “true”, “false”, as well as “yes”, “no”, “y”, “n”, “off”, and all capitalized and uppercase variants)? And people are actually using this in production software?
Then when you add templating it’s no longer readable and concise anyways. So, why? In JSON, you can add templating super easily by turning it into regular JavaScript: use global variables, functions and the like. I don’t understand how anyone could prefer YAML with an ugly templating DSL over that.
And if you really care about conciseness, there’s TOML. Are there any advantages of YAML over TOML?
nine_k · 2024-01-11
There are underpowered languages / tools, that can only solve a problem for which they are intended poorly. But not all limited tools are like that.
Say, eBPF is prominently not Turing-complete, which allows to guarantee that a eBPF program terminates, and even how soon. Still eBPF is hugely useful in its area.
Or, say, regular expressions are limited to regular languages; in particular, they famously [1] cannot process recursive structures, like trees. Still tools like grep / ag / rg are mightily useful.
Yes, I agree that YAML is underpowered for proper k8s configuration! But it's also too powerful for its own good in other aspects [2]. I wish Google used Dhall [3] or their own purely functional config language (FCL? I already forgot the name) instead of YAML; sadly, they did not.
[1]: https://stackoverflow.com/a/1732454/223424
[2]: https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell
[3]: https://dhall-lang.org/
captn3m0 · 2025-09-22
Some context, this was launched at IndiaFOSS[0] yesterday
25 minute talk at https://www.youtube.com/live/AUrPdOZNsX8?feature=shared&t=13962 (starts 3h:52)
The talk proposal is at https://fossunited.org/c/indiafoss/2025/cfp/arsnhack6n
And it primarily tries to avoid YAML horrors : https://noyaml.com/ and https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell.
[0]: https://fossunited.org/indiafoss/2025