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.)
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.
It has to survive the trip there, be mostly autonomous, and most importantly operate in the low atmosphere and harsh environment of Mars. All things no off the shelf design will get you.
Not an expert, but some digging in on this indicates there is one species folks advice against (topical milkweed); otherwise the advice is a species native to your region.
In January I built a personal project on the web with Rust and had the positive experience I was hoping for. The efficiency of execution plus the cleanliness and memory safety of a modern language was the draw.
It took me a week of battling with the compiler to understand what I was doing, but afterwards it felt fairly natural.
My biggest hurdle was I went all in on async (the bikesheded, nightly feature). But a pet peeve of mine is that desktop apps were all async in the 90s and here we have webservers hoarding processes and threads, simply waiting on IO.
I quickly ran into the limits of Rust's async ecosystem. Hyper is an excellent library but there wasn't a webserver framework on top of it at the time. Now there is warp, so I intend to switch over to that from having rolled my own, but I hear some rumbling on reddit that it can lead to compiled size explosion, so gonna watch out for that.
For sql, I'm using mysql-async, but it seems like a single persons passion project. It's quite painful because even with the good libraries (serde) it feel broken to do so much hand writing of sql given the rich type information available in my structs. Everyone seems to use diesel but afaict it's incompatible with the async approach. This is my only real pain point right now.
The whole async ecosystem is still nightly and in flux all the time. Though, amazingly, it's worked quite well. It's clear the community has rallied behind it as most projects are on the bleeding edge. But hiccups happen such as mysql-async not yet supporting the new, nearly-stable version of futures.
Another pain point i've run into is there aren't great crypto libraries. Some very incomplete pure rust stuff. Some poorly documented wrappers of c stuff.
Finally, a third party web api I'm interfacing with doesn't have a rust library so I had to roll my own.
For other random needs I've been surprised by how often I find a great library. AWS libraries, for example, are surprisingly good.
My conclusion is that for web backends rust isn't plug-and-play yet (especially if you want to go all async). But it's pretty darn close.
And yeah, it's crazy fast. Like working in Modern C++ but with iron clad memory safety.
I've built plugins with VSTO (for Outlook) when I was at MS, but my memory is that it’s dependent on a plugin being distributed and not available for native use embedded into the excel workbooks.
You have to install Visual Studio, compile a plugin, register the plugin, and then from VBA you can call out to that COM interface if you'd like. Even if Excel users could overcome those hurdles, you still break the collaboration flow (i.e. just sharing an excel file).
Looking a little deeper, it looks like they're starting to support Javascript for the newer cross-platform add-in system (and also VSTO), but it looks like you still have to distribute your JS add-in via a web-service as opposed to being fully integrated into Excel and XLSM files.
The bit of just being able to share the XLSM file and users using Excel with no other installs or special network access, is really the make or break for me and non-professional programmer user scenarios I've seen.
I'd be over the moon to see one change to Excel. Native support for a language other than VBA. Perhaps the CLR. Perhaps Java/Typescript. Just something (optional) for programmers who want to use Excel and not want to deal with the garbage that VBA is.
Some workarounds exist, but afaik they require collaborators to also have the tool install, which is dead in the water.
I know MS has considered it, I'm still pretty surprised they've haven't followed through.
Have you tried Alpaca (https://alpaca.markets/)? As I understand their pitch they're an API based brokerage with free trades similar to Robinhood. Not my space / haven't tried them, be interesting to see if they meet your requirements.
I was momentarily outraged, until I found it on a map. The San Andreas fault runs _right_ through the center of the property. Makes me glad it's basically a garden now and not a housing development =)
Page 14 and beyond show a number of examples vs previous methods.
IIUC, their contribution is a masking normalization layer (the 'SPADE' layer [see pg 4]) that allows the network to preserve the structure of the input segmentation/mask, leading to results quite a bit nicer than previous ones.
About Code: The only way I've found that works is comments in the code itself (or docs generated from code annotations).
Processes: Playbooks and Automation. Playbooks - DropboxPaper/Google docs that anyone can edit with things like "How to Build and Push XYZ Component", "What to do when the XYZ Server stops responding". Automation - When feasible turn the most used playbooks (or pieces of them) into scripts/tools. Make them the default way of doing things; and any time a break is discovered, fix the tool instead of working around it. Remove outdated/unused tools, so it doesn't feel like a wasteland.
Knowledge on how we do things: You don't want to write docs about 'how to do XYZ'. It will quickly be out-of-date and it'll be horribly micromanagey. But if you and your team collaborative define and document your team values or project/codebase/module principles, I've found you can onboard people quickly and reduce communication. They key here is referencing to the documents when you make a decision guided by them, to keep the docs fresh in peoples minds. And to regularly update the docs.