_peeley

I was also pleasantly surprised to see a `uaf.edu` link on the front page of HN, and even more so when I saw it was written by Dr. Lawlor. His course on x86 assembly is easily one of the best classes I took in college.

Sure, I read that in TFA too. My point is that if USB transfers of Kindle eBooks are being sunsetted, I would estimate that Send to Kindle's days are also numbered.

Thank you!

Very exciting! I'm particularly pleased to see the invisible encryption stuff mentioned.

One of the biggest pain points I had when setting up a self-hosted Matrix instance and getting all my devices signed in was the crypto stuff. At least in the client I use, Element, I was bombarded with tons of popups with vague "Upgrade your encryption!" prompts upon logging in the first time. The copywriting on the "Security & Privacy" page was less than helpful in illuminating what I was actually "upgrading" or setting up, since specific technical terms (e.g. recovery key/security phrase/security key) were all used more or less interchangeably. If that kind of confusion can be reduced or swept under the rug for end-users, it'd be a huge improvement on user experience.

Interesting post. I've used Laravel for a few years now for work and personal projects, and I've really enjoyed it. I tried to test out Rails to explore other MVC web frameworks, and I just couldn't vibe with it. I think the major areas in which I was incompatible with Rails were:

- Lack of dependency injection/inversion of control. I find it interesting the author lists this as an advantage. With Rails, I was always a little anxious not knowing where things were defined or being implemented.

- Validation happens on models, not requests. With Laravel, I really appreciate being able to validate pretty much any data coming into the application regardless of whether or not it ends up in the database. With Rails, I tried to look for something similar to FormRequest and its validation rules, but I couldn't find many solutions. I think it might just be one of those things that's not the "Rails way".

- Perhaps more of a Ruby issue than a Rails issue, but the dynamism of the language - especially in its type system - was a bit of a drawback for me. I really appreciate PHP 8 and newer versions of Laravel for their support in type hinting and static analysis; being able to mouseover anything and know pretty confidently what I'm working with is a huge boon in my productivity.

I definitely agree with the author on a lot of the Laravel tooling stuff. I've learned to just kind of ignore most of the offerings outside of the core framework. I'm sure it's all great, but there's always a bit of churn in Laravel as the author mentioned so I'd rather save myself the future heartbreak.

Ah, I think you're referencing the sidenotes. Sometimes the website doesn't render properly on mobile (I've tried getting click-to-expand working, but it's tricky), so try reading in desktop mode.

Regarding sidenote #1, I actually very deliberately did not mention the language or company ;) Here's the full text of the sidenote, if you're still unable to get it rendering:

> I'm not going to name the language itself, because this post would just turn into a flame war over that language specifically, and I definitely don't want to cast shade on any language/community in particular. I'm also kind of hoping that the most annoying people read this and think, "Ah, of course he's talking about that language over there! This criticism obviously doesn't apply to my perfect and favorite language!" Regardless, I feel that the thesis and content of this post applies pretty evenly to most functional programming languages.