It’s pretty disgusting how much the SV zeitgeist had spent years talking about liberty from tyranny and less than a year into this admin so many people are totally in line.

This just feels so downstream of “the people I dislike are against this so I will be for it” logic. At least the libertarians had some form of principled reasoning … sometimes.

Sadly, this is the inevitable result of so-called "right Libertarianism" at the large scale. With its axiomatic framing, emphasis on individual freedom for yourself, and ignorant rejection of sticky market effects (ie computational complexity), its basically a recipe for power-hungry individuals to justify creating new authoritarian power structures with de facto governmental effects.

Sony still makes TV they get to sell to the highest bidder! They get to sell to Apple TV or Netflix.

Not recurring revenue but they have their thing set up

I think if you want to make this argument you can go look at the stats. Look at the relative cost of vehicles in the EU over the past 25 years, compare to the cost of vehicles in the US over the past 25 years.

Obviously the lack of difference there wouldn't prove much (if I had to bet I'd bet cars in the US have gotten way more expensive faster than in the EU, just from labor costs), but the lack of a major difference would complicate the theory that new regulations in the past 15 years have massively improved costs, absent a theory that some other thing the EU is doing but the US is not doing is also kicking in to similarly counteract that.

The numbers exist, this isn't in the abstract. Just a question of doing the legwork

Huh, but this is a terrible comparison.. the cars in both unions have been made the same, of course they cost similarly. In other words the US buyers partially pay for the R&D cost to keep to EU standards. And the US population also get the EU regulated-safety requirements (although only partially, since the US also allows Cybertrucks to drive around).

A comparison would be comparing a car that can ensure the survival of their passengers, proven with test crashes, vs e.g. Chinese-made cara for the local market that have terrible crumpling when crash-tested..

> the cars in both unions have been made the same, of course they cost similarly

I'm really not sure what you mean, many of the most popular cars in the EU aren't even sold in the US (Renault, Dacia, Opel, Peugeot/Citroën although they have taken quite a hit in the last few years) and they are generally cheaper than US cars.

And quite a few US cars aren't available in the EU either (although they can sometimes be imported privately, which bypasses the regulations somewhat) which is the very topic we're discussing.

As for Chinese cars, the recent ones are performing adequately in crash-tests.

A bit off-topic, but lots of the top ranked Euro NCAP crash tests have been chinese-built cars for a few years now. Their industry has evolved insanely fast, that perception of low standards is long gone.

they're going to compete on ad unit economics against a company whose entire bread and butter has been selling ads. All while increasing unit costs to provide their service (like all the AI companies seem to be doing by just having more and more planning layers)

If ChatGPT went away tomorrow everyone who wanted to would be fine just moving to one of the other random chatbots from one of the other providers. ChatGPT is the default name that people know, but I don't think that's the same as a moat. A moat would allow OpenAI to go really hard on pricing and ads, and I don't think they have that margin!

I understand not having a link to the primary source at the top of an article because you might be trying to write an explainer, but if you want to avoid confusing your readers but still do the right thing at the very least include a bunch of source links at the bottom of the article!

I know all the cynical reasons not to do it, but I feel like even the good faith objection has a pretty straightforward solution.

I think most tools in this space do the "infer a bunch of data and show it to the user for confirmation", which lowers the pain of a miss here.

This hints at the antithesis to this article

Doing a thing involves doing it, but it's very unlikely that doing a thing will involve exactly one atomic movement. So you have cutpoints at doing the thing.

So to do the thing you first have to decide to do the thing. You have to decide what the thing is, or at least have enough of a vision of the thing to take the first step at doing a thing that might look like the thing.

So "doing the thing" involves a lot of doing things that aren't the thing, but without which you won't get towards the thing.

In other words: sitting down and writing down what the thing is _can very well_ be part of doing the thing.

There's a sort of philosophical point too, about whether the thing is what you think it is. Plenty of people have had the "I thought this feature was going to do X, you thought it was going to do Y, and we all realised the mismatch very late in the process".

I think both visions of the world are valid, and things you can keep in your mind at the same time to deploy as needed.

To be honest I feel like "this code is easier to review and less likely to require rollbacks" is even more of a valuable take from this article, just in terms of "hey, don't you like it when things don't have to be rolled back?"

Security issues are like bad etc too, just we've heard the security spiel so many times at this point. I just think it's nicer to write most stuff in Rust.

Yes, Rust's strictness makes it a lot more maintainable. It is so much more common that changing the one thing you wanted to change results in a compiler error at every single other site you need to change, without having to look at other areas of the codebase at all, and all the tests pass on the first try.

> I suspect most joysticks sold today come with a USB-C to USB-C cable

while things can be charged with USB-C cables, the only thing I've ever received A C-to-C cable is... a USB-C wall charger. Granted I haven't gotten a USB-C iPhhone yet and I gotta imagine that one is C-to-C.

Generally lots of pack-in cables I've seen in the wild for charging devices continue to be USB-A-to-C. Switch 2 ports are USB-A, PS5 front port is USB-A... we're still getting there.

  getValue : (b : Bool) -> pickType b
  getValue True  = 42
  getValue False = "hello"

So given something like this, imagine something like the following:

  someBool = flipACoinToGetABool
  thingy = getValue someBool

You're already in trouble here right? what's the type of thingy?

So maybe you write:

  thingy: (pickType someBool) = getValue someBool

which is fine and great!

then you write:

  print (thingy + 3) -- thingy can be an int right?

But at this point thingy is of type "pickType someBool" while + is expecting Int. So it's up to you to restructure your code to prove to the type checker that someBool is in fact True.

For example:

   print ((if someBool then thingy else 5) + 3)

^ and here your code proves the fact! So in practice when you want to explore the results that are hidden behind the dependent types, you will need to have written code that unwraps it like this. But the whole point is the underpinning type theory means that you will be fine while doing it! You've proven that it'll be fine, so if you add thingy to 3 you'll have an integer.

I think of this stuff a bit like encryption password. You have this bundle of data, but to get in, you need to provide proof that what you're doing won't blow up. You'll need to write your code in a certain way to do it. But if you provide the right proof, then we're golden.