People extracting value from labor to enrich themselves at the expense of society and then using those riches to further corrupt society, to the point where a few dudes own most of the country does not align with my politics.
That's why I'm a socialist and I would invite anyone who thinks things might not be going in the right direction to consider that as well.
The only reasonable argument I can think of is that the fantastic wealth accumulated at the top was substantially driven by the $37 trillion of debt the USA finds itself in. And it needs to be clawed back somehow.
It's actually much simpler than that. We need to pay down the debt, and because the rich have most of the money they are going to need to do most of the paying down whether or not they directly are responsible for it or benefited from it. It's simple math. But what does this have to do with a wealth tax? The entire concept is stupid. Income an capital gains rates can be increased.
Well... that's a valid reason. Why should I work with tool B when I prefer tool A ?
> I also do not see much reason to do more than emit JSON on the server side.
That's the "SPA over API" mindset we need to reconsider. A lot (and I mean A LOT) of projects are way easier to produce and maintain with server-side rendered views.
You still need clear separation between frontend and backend (react server components notwithstanding), so nothing's stopping you from using Python on the backend if you prefer it.
Django with DRF or django-ninja works really nice for that use case.
> And as the departing plane goes faster, doesn't the lift take stress off the runway?
Only for a short period between rotation and liftoff. Most of the takeoff roll is spent building up horizontal speed; the pilot doesn't command the aircraft to pitch up before it's ready to lift off.
You are half-right. Actually pilots push the stick forward to force the plane to stay on the ground until it reaches takeoff speed. If the plane would rotate naturally because od the air passing under the wings it would generate a lot of drag.
It's the same principle as walking on snow in normal shoes vs. snow shoes. Taking off is normal shoes, a lot of pressure concentrated at the very first part of the runway. Landing is snow shoes because it's distributed across more of the physical surface, and the plane weighs a lot less when it lands anyway.
Planes all start their take off from basically the same position and stress the whole runway, slowly lowering as lift increases, but at their highest weight.
And this is because pilots are trained to keep their nose gear on the centerline, and there are relatively few aircraft types in use which receive the "heavy" after their flight number over ATC. So wheels are going to roll over the exact same tracks repeatedly.
> pilots are trained to keep their nose gear on the centerline
Funily I was learning to fly at a grass strip and we were told to vary our positioning left and right on the runway for exactly this reason. In practice it meant that as we were taxiing to the runway my instructor would tell me “Today we are taking off left/right of center to avoid damaging the grass too much.”
I also like (old) .ini / TOML for small (bootstrap) config files / data exchange blobs a human might touch.
+
Re: PostgreSQL 'unfit' conversations.
I'd like some clearer examples of the desired transactions which don't fit well. After thinking about them in the background a bit I've started to suspect it might be an algorithmic / approach issue obscured by storage patterns that happen to be enabled by some other platforms which work 'at scale' supported by hardware (to a given point).
As an example of a pattern that might not perform well under PostgreSQL, something like lock-heavy multiple updates for flushing a transaction atomically. E.G. Bank Transaction Clearance like tasks. If every single double-entry booking requires it's own atomic transaction that clearly won't scale well in an ACID system. Rather the smaller grains of sand should be combined into a sandstone block / window of transactions which are processed at the same time and applied during the same overall update. The most obvious approach to this would be to switch from a no-intermediate values 'apply deduction and increment atomically' action to a versioned view of the global data state PLUS a 'pending transactions to apply' log / table (either/both can be sharded). At a given moment the transactions can be reconciled, for performance a cache for 'dirty' accounts can store the non-contested value of available balance.
Are you saying that Scott Adams was right and, say, white people _should_ avoid black people? Or are you saying that we shouldn't remember how awful people were once they die?
reply