The title does not imply it's comprehensive. If anything, a title like that suggests that it's only scratching the surface. If I read an article like "Haskell for C# Developers" I would not expect to be an expert in Haskell at the end. I would expect to have enough intuition to begin actually learning the language properly

For what it's worth, I love the semantics of many indentation based languages (F# for example) but really dislike editing them. Visually scanning is much easier with braces (imo) and it's much easier to navigate braced languages when using a vim-like editor

For somebody unable to empathize with the "braces are easier to scan" part, could yiu explain why?

I find it easy to see if things are on the same indentation. I find it much harder to visually scan for opening and closing braces unless syntax highliting makes them scream at me or they are accompanied by ...indentation.

I suspect this is a "what you are used to" and have trained yourself to look out for over many years of code reading.

The article addresses both of these pretty clearly. Semantic versioning gets borked with reverts and the automatic changelog is targeting the wrong audience

My apologies, I missed this on first read due to the indentation style. That said, I don't agree on the commentary.

Why on Earth are people not writing commit messages for their reverts? They should have semantic commit messages just the same as any other commit.

Unless the point is that they're not following per-commit CD, and if you commit then revert that commit before a release was made. That sounds like a process failure. Which of course, process isn't infallible, and neither is the automated version management. If you screw up, use an escape hatch — just like reverting a commit that had previously gone through code review and been merged.

Re: change log generation. The article says change logs shouldn't have commit messages. I agree. Many tools (e.g. Changesets https://github.com/changesets/changesets) use the semantic commit type to sort change log entries, but require you to write those user facing change log entries separately.

The article is wrong about reverts (in my opinion). If a breaking change is introduced, and then removed, the removal should also most likely be considered a breaking change (both the addition and removal are changing your API). So it is correct that a major version bump should occur when reverting. Once a package has been published, the ship has sailed.

The issue is that if there was no release in between, or only a beta or similar, you now have two breaking changes indicated by the commits, although in sum there is none since the last official release.

That's true, but depends on your workflow and release strategy.

If you are releasing upon every push to main/master (following what semantic release and conventional commits provides you in terms of automation), then it makes sense to perform major version bumps for the reverts.

If you have a manual release strategy, then it might not make sense to use these tools in the way they have been designed.

If you have actual dependents in a SemVer fashion, then this isn’t useful for those still on the prior version. What you’d rather do is decrement the major version again because it’s compatible with the prior version again. Those dependents who already upgraded to the interim version have to consider another breaking change regardless.

And if you don’t have these kinds of dependents, then the versioning scheme isn’t important anyway.

release-please[0] allows you to do a manual version override in a commit, which would allow you to decrement the major version upon reverting a breaking change

I think that could be simplified, so the tool can tell that a commit is reverting a breaking change and thus the version should be decremented, but at least there's an escape hatch.

[0]: https://github.com/googleapis/release-please

Thank goodness. It's been impossible to talk about Coq to people who don't already know what it is.

This was my first thought. I'd like to see it running at like 10x or more to better grasp the change over time

I think you're missing the part where interacting with strangers is also working the general socialization muscle. If you find yourself being more social in general, and give yourself the time to recharge, then you'll be better equipped to engage with those closest to you. You may even get lucky and add someone else to that circle

Yeah that's actualy part of my issue with this - socializing isn't super easy for me. It takes energy. Instead of "practicing" this muscle, I can simply use this skill on the people I'm supposed to use it on anyway - family, colleagues, friends etc. Instead of trying to get the person next to me waiting for the bus to talk to me I can call my best friend who I hadn't talked to in a month or more. I see no point in practicing with complete strangers. But you know what, I'm 41, about to turn 42, perhaps my priorities aren't the same as young people still building their personalities. There could be real value in being less shy and not fearing rejection so much; however I would say - find a good venue. I don't think New York subway is the bests place to start practicing this...

Very cool article. To really drill it home, I would have loved to see how the query plan changes. It _looks_ like it should Just Work(tm) but my brain refuses to believe that it's able to use those new indexes so flawlessly

I've tried off and on to actually use Matrix. I was a bit of a loud supporter in the early days. Unfortunately, it looks like it still hasn't grown past the fundamental issues I was having then. It might be time to try something else

What issues did you have / still have?

When I started using Matrix, Riot.im did not get notifications in time, or was a battery hog. And Synapse took up a lot of memory, with occasional slowdowns. But then, circa 2022, Synapse improved and Element seems to have worked well and was consistent and reliable on all platforms.

That's exactly the sorts of issues I was having. That and it somehow kept losing my encryption information so I'd lose access to all of my messages or something similarly ridiculous

This is exactly the kind of negativity that only appears on the internet and that this study sort of shined a light on. Would you really tell this person to their face that their art sucks just because it isn't good for you?

Part of the goals of making it so tiny, as far as I understand it, is that a normal person could reasonably implement the entire thing from server to client. Going full HTTPS and HTML is a bit of a lift for a single person in a short period of time