tonygrue

You could make a list of all the metadata and pass it through a LLM to determine the quantity. You’ll need some sanity checking but if you prompt it with some examples it will do well. (Done something very similar myself.)

I share all your concerns. I considered mentioning them but figured I should keep my reply focused on idea of freeing people up isn’t inherently bad.

In particular zero sum resources like land ownership will be an increased challenge.

And our governments have been slow to respond to things like climate change and we could be slow to respond here.

My thoughts are a few:

There is a lot of undone labor in the world. In developing countries the middle class has drivers, cooks, housekeepers. That’s only possible due to inequality. With automation we can all get that.

These people with tons of help by and large live fulfilled lives. You find fulfillment in family, friendships, and non necessary creation (art, research, etc); whatever makes you happy.

But most of all, the Industrial Revolution made people think we’d all be idle and nothing can be further from those predictions. Many more people, and many more jobs, and most of the world still lives in relative poverty and various forms of insecurity and unmet material and labor needs.

Finally there are a lot of problems we have (thousands of health conditions, the environment, autocrats) that will prob take centuries to tackle even with ai, robotics, and being freed up from menial labor.

There is an argument that if you need in process multithreading you should use a different language. But a lot of people need to use python because everything else they’re doing is in python.

There are quite a few common cases where in process multi threading is useful. The main ones are where you have large inputs or large outputs to the work units. In process is nice because you can move the input or output state to the work units instead of having to copy it.

One very common case is almost all gui applications. Where you want to be able to do all work on background threads and just move data back and forth from the coordinating ui thread. JavaScript’s lack of support here, outside of a native language compiled into emscripten, is one reason web apps are so hard to make jankless. The copies of data across web workers or python processes are quite expensive as far as things go.

Once a week or so, I run into a high compute python scenario where the existing forms of multiprocessing fail me. Large shared inputs and or don’t want the multiprocess overhead; but GIL slows everything down.

For me the point of thinking like this is to remain centered and not freak out. I see some people who feel like ‘everything is going downhill and this is the worse time ever’ and that’s just not very grounded.

The benefit is that you can be optimistic that the hard work we’re putting in, more likely than not, might continue the progress. Even if there are blips along the way.

I’ve used ImGui with success. I specially was also using webgpu so I used the glfw+webgpu backends. I had to fix a few issues in both halfs of the backend and there remain some little interaction bugs (mostly because browsers capture some keychords and mouse actions and you have to work around a number of them).

ImGui makes a specific design choice and isn’t amazingly documented. I don’t think it’s a good choice for larger scale apps. But good for tools or UIs in games, etc.

Accessibility is a nightmare with pretty much anything skipping browser layout of course.

In my first job, management purposely prohibited developers from using really powerful machines because we needed to make the software faster. The problem was it was hard to make the software faster because it was so slow to run, measure, and verify changes.

Those managers were eventually all let go and one of the first things new management did was buy us the most powerful machines they could find and institute performance regression tests that rachetted down. Each change could only keep the existing performance or make it faster. And changes that made it faster set the new watermark. Regressions required management approval.

After performance having been unimproved for a year, it was largely resolved in 6 months.

Since then I’ve been a believer that you give your developers nearly the fastest platform money can buy but then have automated, gatekeeping tests for your lowest target platform, with spot checking to make sure your tests reflect actual user experienced performance on that platform.

As an engineer who loves the moonshots it breaks my heart. The core problem however is that from a dispassionate investor viewpoint, the uber for Y companies are more understandable and are perceived to deliver larger results more quickly in aggregate. Even accounting for these public failures. And since the dispassionate investor really only cares about return (regardless of what most say) they don’t invest in long term, capital intensive, unproven business. There seems to be an opportunity for entrepreneurs who can market the moonshots better to investors and hire the people to execute on them. But those two skills are very rarely in the same person.

As the article alludes, lack of a build your own, flexible yet affordable desktop option seems to be a pretty deadly aspect.

Pretty much Mac owners are on laptops. Even in the PC world few laptops can power VR. Those that do tend to be bulky for cooling and have nVidia GPUs; both things which MacBooks seem unwilling to have.

Having a extensible desktop at 1k that supports nVidia would probably go a long way.