I think if people who like trucks didn't see videos of things like the bumper ripping off when towing or minor failures leading to whole vehicle shorts it might have done better. The people who want trucks want resilience and ability to self-service more than the average car buyer.

Cybertruck offroading attempts were also a hoot to watch. The whole vibe is that it is merely a truck-shaped Tesla EV that's terrible at most truck tasks. Sure, there's a market for mall-run trucks with pristine beds and never get any mud on them, but it's not a big one.

It actually wasn't the bumper that ripped off in that video, it was the entire rear subframe tearing in two.

If you're talking about the JerryRigEverything video, the negative interpretations represent a fundamental misunderstanding of physics. Pinning the front down removes the main real-world load-sharing path (vehicle rotation and suspension compliance) so the rear subframe is forced to absorb an unrealistically large bending moment that would normally be distributed across the whole vehicle. This created conditions which do not occur in real towing, and which give no insight into the actual towing limits of the vehicle.

All the test demonstrated is that you should not exceed the towing capacity of Cybertruck while its front subframe is pinned to the ground by a tractor.

I've never seen a JerryRigEverything video.

Ignoring how it works, there are a a solid handful of great features you get out of the box with Solid + Active Job that don't exist w/just using Sidekiq, even through the Active Job adapter.

As a former engineer at a YC startup from pre-A to post-B, I generally agree with much of this in a broad way if the startup is a technology first one with organic growth or hasn't really figured out product/market fit.

But I think some of the management and team stuff is much more complicated in B2B or B2B2C situations, regulated industries, or cases where there are substantial non-engineering employees, perhaps doing sales, onboarding, or things related to the "offline" world (if there are physical aspects to the business).

In particular, I don't think you can have a super flat eng structure run out of a few docs if eng needs to be working with one or more teams larger than the eng team itself unless there's some kind of separate interface to large outside teams.

If you end up with a significant sales team, account management team, support team, significant numbers of contractors, or other categories of workers because of the nature of the business, you will have to be more regimented about how things are structured. In companies that face this issue, it's often one of their major challenges and not avoidable compared to other kinds of startups - your sales team may have all kinds of ideas and some of them may even be good, and some may even want to sell them before you've built them. And if your sales team is 2x the size of product and engineering... it's not easy to run out of one document. (Note that I don't love or endorse this, but in certain kind of markets and products it seems like a bit of an unavoidable issue.)

Using layers with settings about which SDFs interact with which layers for operations seems interesting. Like put trees in a layer and then have an axe that can negatively deform the trees but not the ground layer or something. Or a predator layer that can absorb things in the prey layer. Haven't really thought through.

Just build more housing, the whole "let's make rules to avoid the easy and obvious solution" trend annoys me.

Utilizing vacant properties is easier and cheaper than building new ones, by a massive margin. We should do both, but ignoring perfectly good homes in desirable locations being used by nobody is silly.

If the goal is to reduce the number of vacant homes, then why not create a tax on those specifically. Corporate owned homes and vacant homes are not the same thing at all.

I mean converting vacant is fine, to me it's the same category basically - increasing housing supply.

I think people really underestimate how nice it is for the lenses to be smaller and not just for the camera to be.

I wonder if there's a marketing reason for not shrinking the lenses. A big lens screams "better" more than a smaller lens at a casual glance for the uninitiated user.

It's an engineering reason really, the entire reason why MFTs were so popular when they came out was because people were tired of lugging around their Full-Frame camera's zoom lens, and were sick of missing moments when using a prime lens.

The marketing gimmick for awhile was ultra-zooms which allow for smaller lenses via fixing distortion using DSP, but this degrades the image quality, and so never became a solution for RAW shooters.

I think it's directly related to sensor size and given the shape of lenses (cylinders) that means bigger sensors should probably have a non linear relationship to lens size.Though it is probably not quite that simple. In any case, bigger lenses allow for smaller f stops with a given focal length, and people really do love bokeh...

I doubt it. I don’t think anyone is spending $2k on Canon L-series (red ring) lenses based on the size. On the high end, photographers are pretty discerning about equipment’s capabilities. If they made my Canon EF 35mm f1.4L USM II half the size and weight I’d be thrilled.

The RF version of that lens is a bit lighter.

Bigger lenses tend to gather more light and that means better images in darker moments.

I have a GX-8 and I still like it...

That was my first guess TBH. Mostly because it seems like the kind of thing scientists writing Python would do.

Maybe they should read that article (that was on HN) from the other day and switch to using account numbers with no customer information since that'd be about the same difference anyway given this behavior.

I agree errors should be errors. Many things that are logged for other reasons should use a different label.

That said, the thing I've cone find being useful as a subcategory of error are errors due to data problems vs errors due to other issues.