One thing I miss from when I mained workstation-class Linux laptops is indeed just how tinkerable they were, in a way that didn't feel like a compromise because no other workstation-class laptop was smaller, and smaller laptops had limited performance. You could upgrade RAM and replace a HDD with an SSD, you could drop in a PCMCIA card, you could bring interchangeable batteries, etc.
I appreciate that Framework has not only brought that back but expanded on it further, but they've done it at a very different time in the market. Now that maintainability and customizability does come at a compromise to at least one of cost, bulk, or performance. That's not only the case when compared to the Neo, as far as I know it's also the case at the high end compared to a MacBook Pro.
They've set out to do something that would be difficult in any case, but they're also doing it against Apple's advantages of vertical integration and economy of scale. I'm sure I'm not the only person that can deeply respect that while still not feeling any interest in buying any of their available products.
> The Neo is an appliance. The Framework is a tool.
I get where you're coming from in principle, but I'm not sure to what audience this actually applies. If you just want a laptop that can run the software you use, both are adequate as tools. The Framework's greater flexibility only applies to making changes to the tool itself, which doesn't matter if you didn't need to change it to suit your purposes. (And I say that as someone who has built their own Linux & Windows PCs from parts since high school, because I know I'm not the target audience for a Neo)
It's like I consider my Dewalt power drill a very decent tool because it has exactly the modularity I need -- it even has interchangeable batteries -- and it wouldn't even occur to me to call it an outright appliance even if another power drill offered more customization for some niche use case. The Neo is an adequate tool for many people even if other tools do offer more customization or maintainability.
This would be a much stronger argument against using an iPad for productivity, because many people simply cannot run the software they need, or only at a significant expense to productivity and quality of life. I use iOS devices only as communication and media terminals, and even then I would struggle to call them appliances, they're still tools for their particular tasks.
It's even weirder than that sometimes. For example, Subnautica on Steam has a hard dependency on Steam (whether or not you would call this DRM), but the exact same version number of Subnautica on Epic Game Store only checks for a command line flag and can easily be archived out. Despite that, it's not for sale on GOG.
I think a big difference is that the less unsafe you want in your own code, the more you rely on crates to provide a safe abstraction for unsafe code in a centralized place where soundness holes are likely to be found.
Of course it was always understood that you could have bugs in C libraries and some of them may include memory unsafety, but the culture is very different when there's no explicit way to demarcate the parts of the code most deserving of scrutiny.
I was also worried about the plastic tongue, but I have never managed to break one. In contrast, I have managed to irreperably damage the exposed metal contacts on multiple Lightning cables. If you'd asked me which should be more durable, I would have predicted Lightning, but my experience has been the exact opposite and beyond any doubt.
To be fair, even state of the art of high-speed data cables are thick and relatively inflexible. I simply wouldn't want every cable to be a high-speed cable if that meant they were all chunky. I do agree that it should be clearer at a glance what you can expect from a port or cable.
Async ruined Rust for me, even though I write exactly the kind of highly concurrent servers to which it's supposed to be perfectly suited. It degrades API surfaces to the worst case :Send+Sync+'static because APIs have to be prepared to run on multithreaded executors, and this infects your other Rust types and APIs because each of these async edges is effectively a black hole for the borrow checker.
Don't get me started on how you need to move "blocking" work to separate thread pools, including any work that has the potential to take some CPU time, not even necessarily IO. I get it, but it's another significant papercut, and your tail latency can be destroyed if you missed even one CPU-bound algorithm.
These may have been the right choices for Rust specifically, but they impair quality of life way too much in the course of normal work. A few years ago, I had hope this would all trend down, but instead it seems to have asymptoted to a miserable plateau.
Like I said, if you prefer an integrated graphical UI, you can file feature requests against the one you prefer. What git itself does makes a lot of sense for the canonical CLI tool to do, though even then you can propose or prototype changes if you have ideas. This is how projects like jj started in the first place.
If that's the kind of UX you prefer, please consider filing a feature request against your git UI of choice. My point is that git itself already has the core capability, and how convenient it is to use usually depends on your editor. (e.g. in vim, dd to cut a line and p to paste it in a new position is a very quick way to reorder)
I only agree if you have a bounded dataset size that you know will never grow. If it can grow in future (and if you're not sure, you should assume it can), not only will many data structures and algorithms scale poorly along the way, but they will grow to dominate the bottleneck as well. By the time it no longer meets requirements and you get a trouble ticket, you're now under time pressure to develop, qualify, and deploy a new solution. You're much more likely to encounter regressions when doing this under time pressure.
If you've been monitoring properly, you buy yourself time before it becomes a problem as such, but in my experience most developers who don't anticipate load scaling also don't monitor properly.
I've seen a "senior software engineer with 20 years of industry experience" put code into production that ended up needing 30 minute timeouts for a HTTP response only 2 years after initial deployment. That is not a typo, 30 minutes. I had to take over and rewrite their "simple" code to stop the VP-level escalations our org received because of this engineering philosophy.
> Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants.
I get where he's coming from, but I've seen people get this very wrong in practice. They use an algorithm that's indeed faster for small n, which doesn't matter because anything was going to be fast enough for small n, meanwhile their algorithm is so slow for large n that it ends up becoming a production crisis just a year later. They prematurely optimized after all, but for an n that did not need optimization, while prematurely pessimizing for an n that ultimately did need optimization.
Yeah, I make it a habit to read the changelogs of every update to every direct dependency. I was anticipating this change for years, thanks for doing it!
My best professional relationships are between people who are confident enough to take direct feedback and appreciate it rather than resent it.
However, my worst professional relationships are with people who will rebuke your feedback whether you Crocker it or not. If you're direct, they'll say you should have been more diplomatic about it, but if you're diplomatic, they'll say you're being dishonest and should have been direct. There is no right way to approach it, these people will always find a way to criticize the delivery, and to delegitimize the feedback because of it.
This seems as good a thread as any to mention that the gzhttp package in klauspost/compress for Go now supports zstd on both server handlers and client transports. Strangely this was added in a patch version instead of a minor version despite both expanding the API surface and changing default behavior.
I think the big difference is that if you just want to optimize for some objective, it's usually very clear how to do that from Apple's options, so there's not much research to be done. It can still be challenging to choose what's the best value when it's your own money, but at least you know what you're getting, and the quality hasn't been a concern for years.
"Former Googlers" were probably used to using protobuf so they could get from a function call straight out to a struct of the right schema. It's one level of abstraction higher and near-universal in Google, especially in internal-to-internal communication edges.
I don't think it's a strong hiring signal if they weren't already familiar with APIs for (de)serialization in between, because if they're worth anything then they'll just pick that up from documentation and be done with it.