1. No, I'm not reading your article on quantum.
2. Yes, all choices are bad. That's what "breaking" means.
3. I'm glad smart people are thinking about technical mitigations.
Since I'm taking a few weeks vacation, I've decided to seriously try to learn rust. My method in this case is to ask ChatGPT to guide me (but not write for me!) a library ("crate") that I've always wanted to write and never got around to.
Of course, I get a lot of feedback on appropriate rust styling, but some of it veers into things I feel are deeper constraints. In this case, I had an open function, which took a struct containing some flags, such as "writeable", "create if didn't exist".
It didn't like the fact that I asserted if you set create and didn't set writeable. Here is my response:
---
Re: assert!(). I dislike APIs which allow misuse. Callers of a library should not rely on such checks in the library, in fact the concept of adding an InvalidOptions error type is offensive. A recoverable error is strictly a worse api than an unignorable error. But a compile time error is better.
We should use an enum READONLY, WRITE_MUST_EXIST, WRITE_MAY_CREATE.
---
Of course, it's a waste of time for me to lecture it on style, but I can't help myself!!
Damn, right before I closed my laptop for the afternoon I had uncovered a weird bug, which git bisect says is triggered by a trivial commit.
But I really should record myself tracking it down, for my Intro to CLN Development series, so I am having to resist the urge to look at it tonight...
In preparation for onboarding new core lighting developers are preparing a series of videos. So I've been asking ChatGPT about CLN developer features, particularly with comparison with other projects people might be familiar with.
Of course, I compare myself with Linux, but it's interesting to see comparisons against other projects:
**Type-safety**:
OpenBSD High
Bitcoin Core High
Core Lightning Very high for C
Nginx Low
curl Moderate
MySQL Moderate
SQLite Moderate
CLN sits near the top among major C codebases for safety discipline.
**PR Submission**
Core Lightningβs PR flow is unusually strict, slow-moving, and review-heavy compared to most open-source C projects β closer to Bitcoin Core or OpenBSD than to typical GitHub projects.
---
Compared to βaverage OSSβ
Most projects:
Feature-oriented PRs
Informal review
Few required reviewers
Patch squashing common
Tests sometimes optional
Architectural discussion often post-merge
CLN:
Patch-first culture
Pre-merge architectural scrutiny
Extremely high reviewer expectations
Tests are mandatory
Clean, narrative commit history matters
