bwilliams

I think that's a factor for sure, but is less important (generally) as the price gap increases. The Steam Deck also has a disadvantage in that only some of your existing library will be playable on the device.

There's definitely a price point for some where it will make sense to rebuild your library on the Switch vs pay the higher cost of a Deck.

I love my Steam Deck aside from the quality control issues I ran into, one of which required an RMA. It's really hard to justify $1000 for it when the Switch 2 is $450 (soon $500).

I do think there's a bright future for PC handhelds, especially when (not if) ARM processors can be utilized. I'm less sure about that if prices keep rising since that quickly becomes the difference between niche hobbyist device and mainstream gaming portable.

Same. It’s the best ebook experience I’ve had so far despite its size and I’ve tried a myriad of ereaders.

The only missing feature is a backlight for reading at night.

There's definitely a number of reasons, but I vividly remember _struggling_ with Ember data at the time. The framework itself was already complicated and the data management story felt immature and rigid in addition to complex. That definitely pushed me towards and a number of others towards backbone and eventually React.

You can have a modular monolith with multiple entrypoints that enable autoscaling of independent "deploys".

I had the same thought when reading the article too. I assumed (and hoped) it was for the sake of the article because there’s a stark difference between idiomatic code and performance focused code.

Living and working in a large code base that only focuses on “performance code” by default sounds very frustrating and time consuming.

Great article, memoization is pretty complex and full of trade-offs. We recognized a lot of these same pitfalls as we worked through making memoization a consistent and common pattern in our (very large, monolithic Rails) codebase via a `memoize def...` helper. The `false` and `null` pitfall is _surprisingly_ common, enough that it (and other pitfalls) warranted us writing our own memoization DSL.

We took the opposite approach of most libraries though (and a reason we rolled our own instead of pulling in an existing gem) by avoiding handling the complex edge cases that hide trade-offs:

1. Class methods can't be memoized.

2. Methods with arguments can't be memoized (so no LRU caches, weak refs, tracking arguments, handling default args, hash/deep object equality, etc)

The thought at the time was that those more complex scenarios deserve more thought than "prefix it with `memoize`". It's been a few years since we introduced the helper and after seeing it all throughout our codebase with no issues I'm even more confident this was the correct decision.

I haven't revisited it in a while, but I'd love to add some extra niceties to it, like hooking into `ActiveRecord`s `#reload`, although I dislike memoizing in models.

I’m not sure if it changed, but Crystal was limited to a single core which I imagine made it easier to choose Go over Crystal.

That and I’ve found that folks often aren’t very receptive to Ruby like syntaxes initially.

If we can’t have native macOS on the iPad this would be the next best thing. Imagine having Linux or macOS on the iPad that is treated like any other app (sans memory limits and etc.). You could have a full blown desktop at the ready when iPadOS isn’t up to the task.

The iPad could finally utilize the m1 processor to its fullest.

I think this may miss the point of the article, which is pointing out that you can get a lot of value for very little effort by using a timestamp instead of a boolean. I don't think it's intention is to replace a complete change history/audit log implementation, which would require a significant amount more time/effort to implement.