bourneavent's comments

The problem is you end up paying More for what you want because what you want doesn't align with everyone else. These cars are massed produced, so anything deviating from the popular norm ends up becoming custom and costing more, even if the custom design is less complex then the popular design.

Given that everyone else wants those bells and whistles, ironically you get more by paying less which means logically more bells and whistles is the better deal.

A logical person would in turn want the cars with "too much stuff". That is unless you're willing to pay more for less stuff.

>For instance, I've got a raspberry pi hooked up to some solar panels handling some gardening stuff for me, it'll be just fine.

You can remote ssh into the pi with Vscode or a jetbrains IDE with a laptop that likely won't be fried either under your description.

Python can run on the rasperry pi. Even high level interfaces will remain. Additionally GUI support exists on a Pi.

>I promise, installing a Jetbrains product on a traffic controller (which is what I was thinking of re: the field trip) would be a tremendous amount of work.

Jetbrains isn't installed on a traffic controller. It's installed on your local machine. Both VSCode and jetbrains have something called "remote development" which allow you to develop on a remote machine as if it was local. It's similar to ssh and vim.

>Yes, and they're one geomagnetic storm away from being entirely useless. It might not be for everybody, but there's value in being able to work with a lean toolset.

A geomagnetic storm will render everything useless, I don't see how a vim user will be more protected then a vscode user.

>How is this any different from farm machinery 200 years ago or industrial automation 50 years ago? More production with far less people.

The economy will for sure eventually get into some sort of equilibrium again. Things will become normal sort of like how the giant wealth inequality gap is super normal right now (likely caused by the same automation you're describing).

But there is so much different now then before. Additionally the velocity in which this replacement is occuring is much higher then industrial automation. Given the differences we cannot fully know the outcome.

It's easy and convenient to allude to examples in the past to predict the future, but that is not a data driven or logical conclusion. We don't know what will happen, and to ignore the possibility of a bad outcome is folly.

My wild guess is that there will be a temporary period of destabilization and this temporary period could last between one to two decades all the way to several generations. By then all the "problems" will be normalized; sort of like how the wealth inequality gap has been normalized and how it's basically become normal to see tons and tons of homeless people living in RVs in the bay area.

These studies aren't done wholistically and only done from a business perspective. That's why these studies are garbage they fail to account for the feedback effect.

Employers pay money to workers so that workers in turn can buy products from employers.

These studies only account for how much money Employers save when they get rid of workers and pay less money to workers.

Well when you get rid of workers or pay them less there's less money going around for workers to buy things from employers. These studies fail to account for this feedback.

It's the tragedy of the commons. If one company utilizes generative AI to reduce labor costs that company benefits. If all companies collectively do this, then everyone loses. It's the aggregate behavior of all companies acting in their own interest that ultimately causes them all to act against their own interests.

It doesn't have code completion. You can install it as a feature, but vim itself doesn't have that feature. There needs to be a law for someone either flat out lying or not knowing what they're talking about because godwin's law doesn't apply here.

Additionally installing these features on vim is a nightmare for various reasons. It can be done, and I've done it, but the experience is not as good as the more clunkier GUI IDEs. I'm all for a TUI IDE if the experience was as automated or seamless as jetbrains or M$, but such a app doesn't exist yet.

>Sometimes it's faster to fix the code where the bug is, rather than trying to recreate it in your cushy dev environment

Sometimes, but with single powerful IDE solutions from companies like jetbrains, setting up a "cushy" environment is barely any work.

>Sometimes that means driving somewhere and working through at 9600 baud over an RS-232 cable. Do this a couple times and you'll find that vi is quite usable--you just have to want it to be.

Of course if your network connections completely fail you have to use the serial console to fix it. There's no going around that. But the majority of developers don't even need to do this or don't even know what you're talking about as they only interact with cloud services nowadays.

Additionally a "cushy" environment doesn't preclude you from using serial console or using vim to do edits everywhere. VI in this sense is barely useable, it's basically the baseline necessity. You need it when all else fails. But it's not good to have it as your daily driver.

Except I'm sure that book fails to mention many examples where the long tail worked and instead focuses on where the long tail failed and biases it's own story around that.

Jetbrains suite of IDEs are basically long tails and they have huge utility in many areas that exceed other editors.

It's barely useable. I rely a lot on code completion, search capabilities and syntax checking while I code. It just saves a lot of time from having to execute the compiler and wait for it to check everything.

With good "plugins" or "features" all of these things happen async.

That's because they call you "Daddy" in the bedroom.

There's actually sort of a real reason for this. In the traditional monogamous or even polygamous relationship throughout human history it's usually the Male taking care of the female. Women when seeking a relationship are sort of searching for a caretaker that has sort of father like qualities of having enough resources to take care of them, taking a dominant role... etc.

The relationship most similar to it is father and daughter I can sort of see why the linguistics have sort of merged.

Obviously, in the last century, things have changed and the etiquette of relationship dynamics need to be spoken of in a way that's more egalitarian.

But you can't completely deny millions of years of human anthropological behavior. If men usually played more dominant/caretaker roles in relationships in the majority of civilizations, then along that timescale certain behaviors become a bit ingrained biologically through natural selection. It's not surprising to see these attributes creep into language.

This language is unconventional for business even in the 90s. Additionally men wouldn't talk this way in front of women in Any time.

The difference now is it's less culturally accepted to talk like this even in casual situations even when just among men.

Plenty women objectify men by wealth and status and they refer to men this way even publicly. The cultural change is mostly one sided, skewed more towards not offending women.

For example, referring to men as Hunks or Chads is just not offensive at all. In fact it's a compliment. I feel it's almost entitlement if a girl gets offended by being called a babe.

The world needs something like a web3 reddit.

You know what's an interesting problem? Decentralizing moderation. HN does it sort of but the masses are really stupid and biased.

Maybe an ML based personal moderator. Based off of comments you vote down or up.

I mean I could say C++ is just python with memory management macros.

We're getting into the domain of opinion here. I would say TS is different enough such that it's two different languages.

Programming with type checking and programming with plain JS is really different. A programmer without experience in types (ie plain JS) won't be able to pick up types that that quickly on average. Things like enums, Generics, sum types, product types, recursive types, really change the game by restricting what functions can do.

>He might be right on some fronts,

JS was designed in a week. He's completely right, it's just poorly designed. Javascript will always be around because of technical debt and habit. But that doesn't change the fact that Douglas is right.

Also nobody really uses javascript anymore. It's completely insane. We compile Typescript into javascript then run javascript. That should tell you something about javascript.

>Do you mean on a hardware level? Because otherwise, hell no.

I mean in the context of async await. The smallest primitive that is properly async is an IO function.

>For every single researcher, there are 10 other graduates and staff who would be willing to do their job for a fraction of the cost.

This is what unions are supposed to fix. If the researcher and 10 graduates are under a union the company has to literally pick the best one, not the cheapest one because the union guarantees reasonable pay.

Software engineers should do this. We got complacent with the high pay but we were never really in control. Recent layoffs would be less likely to happen were it not for unions.

>How does "func EatADonut() async {}" aka "eating a donut is an inherently async action" even make sense to people?

You have to think of it from a higher level.

Nobody knows if eatdonut is strictly async but everyone knows all IO calls are async. So something like socket.send would be async, this is obvious.

Then anything that calls socket.send would then in turn become async itself. The async sort of spreads around like a virus. Any function that uses other async functions gets polluted with the async marker.

So in this sense, you should think of it like this. If eatADonut is async it means it touches IO. It sends data somewhere else to some other thing. It also means it's not unit testable.

In a nut shell This is the intuition you should have about async:

   Async Tells You about the properties of eatADonut. eatADonut doesn't tell you anything about whether or not it's async.

This is largely identical to how the IO monad works in Haskell. Unless you want all your logic polluted with the IO monadic wrapper or the async marker you have to learn to segregate your functions into async functions and non-async functions.

Under this intuition, EatADonut, by good design principles should NOT be async. This is what it should be:

    fn eatAdonut() -> ResultOfEatADonut
    async fn sendDataToIO(data: Data) -> ()

    async parentCaller() -> () {
       let data = eatAdonut();
       sendDataToIO(data.serialize()).await;
       ()
    }

The async marker forces you to organize your code in this way, You have to do this unless you want all your functions to be polluted by the async marker. This is the proper way to organize code Anyway, as it allows your code to be unit testable. Async calls are, in general, not unit testable because the functions are not pure. So if you look at what I did above, I segregated eatAdonut Away from IO and made part of the logic of the overall code testable via unit tests.

IO calls should be very general and small functions while your other functions should be pure and unit testable. This is the overall intuition you should have about async.

Believe it or not, this specific aspect of async is actually an improvement over golang style concurrency. Not an overall improvement, it's still debatable which style is better, but I'm saying the async marker is actually a feature that other styles of implementing concurrency don't offer.

Basically, async encodes the concept of IO and function purity into the type system. It allows the type checker and You to tell which functions touch IO and which functions are pure and unit testable.

People think unit testability is some kind of marginal benefit because you can cover testing with integration tests which are basically tests that happen across IO. It's more than that. The ultimate dream of programming something as if it's a bunch of modular lego blocks that you can elegantly place together is most fully realized with pure functions. Async enables more of this style of modularity in Rust (but not without some cost which is why it's debatable whether or not it's better than go style concurrency).

The title seems obvious. I mean guns, and nuclear bombs and bio weapons don't kill people. People kill people. But this is something we all already know.

I don't think we'll ever have a problem of accidentally trusting all our nuclear launch codes to an LLM.