Conversion of legacy nontrivial C++ code bases into Rust (or anything else for that matter) feels like it should be one of the "Millenium problems" for AGI. That and full self driving - including the nuances of gesturing to a human about who's going to reverse in a single lane in a snowstorm.
But if 50% of code can be converted automatically to safe idiomatic Rust? Great. Doesn't sound too far fetched. But yes, there's certainly a long tail here.
> Conversion of legacy nontrivial C++ code bases into Rust (or anything else for that matter) feels like it should be one of the "Millenium problems" for AGI.
Whilst I have no doubt that LLMs will be useful here, I still have reservations about validation. I think experience tells us that test coverage is generally insufficient to ensure functional equivalence, and not all components are well specified.
The 10% excel sheets are exactly the problem. You can replace 90% or even 99% with either some online simpler office suite or none at all. But it will turn out there are business critical things running in 2003 format excel sheets with macros and if anything stops working then the organization stops working. The person who made these sheets and macros has retired 20 years ago and "updating it" would require making a dozen little applications to replace them which would be a huge task.
The simple/cheap answer I think is to just keep the power users and legacy systems on the tools they need/want. Because that's where the pain point is that cause these projects to fail. If you aim for 100% you'll end up with 0% eventually. If you aim for 90%, you can do it.
But Microsoft know this, and would make sure that a 90% migration saves you much less than a 100% migration. Which is why this is so rare still.
(I think the number is probably 99% not 90%, but the point is the same)
How many people in most government positions are using Excel?
SaaS and mobile has taken over many apps. We sell SaaS to business and govt clients where most end users are either on a browser or a mobile app. There is a Windows application (path dependent history) but it is almost vestigial for configuration/management.
of people with a laptop? Maybe half (Just a guess). But most of those are not using it for anything complex. But it doesn't matter, it's that 1% of excel users and their sheet that is the problem. You'll find where it is WHEN you try to phase out excel. Not before. The report will be "I can no longer run our weekly report thing because google sheets/liberoffice doesn't run the macro and now we can't update the schedule for the drivers and they're angry, please advise". The solution, invariably, is not to throw a contractor at the problem and write a web service for it. It's to just let that sheet keep working another decade and pay the excel license. It's much much cheaper. But it also means that the long tail of Excel stays.
The long tail of ms Excel does not get replaced easily. For 90% of customers and 90% of workflows you see either no use of a program, or use cases that can be replaced with anything.
But eventually you'll find the power users who do business critical stuff in excel sheets that you notice can't be done in any other way, and if you stop doing it then people aren't paid in time or whatever.
This doesn't mean it's a good idea to not try this. But Microsoft also aren't dumb. They know exactly how common this is, and what fraction this is. And they will make sure that it costs little more to keep the Microsoft products across the org, than it costs to keep them for specific users and deal with the mess that happens.
This could be said for other things than Excel, but Excel has been one of those moats for decades now.
But the general usage of Excel is so negligible in terms of using its actual features that it can be easily replaced.
In my experience, non-basic formulas are beyond 99% of people and they use it simply for adding stuff up in a grid. This is why Google Sheets is used in many places as a replacement (even if it balloons RAM usage when presented with a large sheet of data), simply because all of the wonderful features of Excel are unused.
The most complex operation some people do seems to be lookup tables.
Whatever is in those Excel sheets. In any nontrivial org, you'll find it if you try. We found users designing roof trusses in Excel with heavy vbscript macros...
> ...Excel has been one of those moats for decades now...
I think if we focus on "has been", and not consider something dire like "will always be"...then i see it as an opportunity (and opportunity for LibreOffice and others like it). Because i do agree that a small % of people do use/need advance features from excel...so if i were the European Union, then i would gather such data for advanced usage (which is best done when pilots are rolled out), and throw a little money at addressing that (by a little, i mean little for big governments, so talking like a few million, etc.). I'd throw some money at the devs who contribute to LibreOffice, openDesk, whatever...and specifically address whatever shotcomings might exist in the free and open source offerings. Maybe its not an overnight solution, but it would serve to produce 2 things:
1. You pay devs to address the issue...reducing or removing any gaps between excel and offerings like LibreOffice, etc.
2. The devs you threw money at will gain ever more experience addressing needs for this now more expanded marketplace...creating possibly some more jobs and/or opportunites for more local vendors to support these govs, and any businesses that follow suit in adopting such open source offerings...
...I think these create or expedite a marketplace...and one that is not controlled by the U.s. or any single dominant player. So, i think while it might be slow, its a good long-term approach.
It's a prototype. But yes, the seats are going to take the trend of "lighter seats" even further. For example, for such short flights it's probably worth not having tables in the seats.
BUT, where current aircraft are usually constrained on size, cramming as many passengers as possible into the cabin is the goal.
Here, space will be less of an issue than weight. So cabins can offer more room between seats minimalist seats.
I don't think it's the daily work commute being solved. More weekly meeting in Cleveland for someone who works in Chicago. Which today is a 5h one way drive and a hotel stay.
The problem with sandboxing is that the regular dev env (massive IDE:s, cloned megarepos, installed dependencies and so on) just won't sandbox very easily. I can't set up a "second machine" or an "isolated environment" to run claude cli in. At least not in the sense of a VM, physical hardware, container etc. Not sure what the best practices are for whitelisting tools/directories and so on, but so far the only useful mode I have found is just "allow everything and go to lunch". And it doesn't feel like I'm holding it right, but here we are.
> The problem with sandboxing is that the regular dev env (massive IDE:s, cloned megarepos, installed dependencies and so on) just won't sandbox very easily.
It's not that hard, actually. You don't need VMs. You usually don't need absolute protection, just reasonable protection against the agent doing something stupid. Here's what I usually use:
A docker environment. $HOME inside docker is private to the agent and persistent (i.e. it doesn't have access to your home directory). `/tmp` is always fresh. Only the current directory (i.e. your project directory) where you start the container sandbox is exposed. Everything else is ephemeral. You can't launch the agent by accident outside of the sandbox (because the `.claude` doesn't exist in your home). The agent can only screw up the directory in which you've launched it, and nothing else. Here's my version of it: https://github.com/koute/vibebox
It is generally worth making your dev environment easy enough to set up that installing it in a VM is not a particular hassle, even without the concerns about sandboxing. For me the biggest headache was windows licensing.
Golden VM image with differencing VHD/VHDX/delta disk. Build products can still get huge with debugging information, but debug info usually can compress 5:1 with fast compression (no entropy coder) if your VM's filesystem can support that.
But unless you want to also do all your "human" development inside a VM, how do you cooperate effectively with the agent(s)? I want to run my IDE directly on the hardware, not inside a VM.
So while the agents develop in a sandbox/VM, I still need to touch the same files, and see them in my IDE which is not in a VM. I suppose I could just _mount_ the same files (Documentation, git working copies etc) I work on as directories inside the VM, and then let it roam free in there, while I observe the same files on the host machine? Is this a common pattern?
I set up gitolite on a remote server with the agent only allowed to make non-destructive pushes to the repo outside of the VM in with an agent/ prefix on the branches. Let it work on stuff autonomously, then I review before merging outside the VM into the main branch.
I don't want them to have potential access to any of my logged in browser sessions etc., so don't want as much sharing as you are going for.
Hyper-V with GPU sharing on windows (game development) is actually nicer than developing outside of the VM because no matter what it doesn't slow the host system down by more than a fixed percent and Windows is terrible with things like compiles spawning lots of processes triggering massive slow down of browsers spawning processes etc. When compiling a big game engine things like ping.exe can start taking 5 seconds to start on something like a 16 core machine due to the process churn and some fundamental problem in windows even with defender off.
One tip for Hyper-V is use sunshine instead of Hyper-V manager for viewing the screen at full refresh rate, and I think I had to either turn Hardware-Accelerated GPU Scheduling on or off in the VM to prevent some hitches.
Mounting folders could be good for stuff you don't want filling up git, like render artifacts etc. if you need to work with them on the main host.
With the golden image and differential stuff I can run around 3 VMs on a 5090 with enough VRAM to run a big game engine well, but I usually just work in one due to the time to review code. Periodically compress everything with compact.exe, and limit engine work to one VM to avoid blowing up disk, bringing it over to the others through cutting a new base image after compressing the engine build artifacts (something like unreal engine puts out hundreds of gigs of .pdbs).
On pure linux you have many more options, and also might also be able to get away with just a limited user and separate X server, then you can just directly reference all of its files and can limit it from getting to yours, but it is a bit riskier. You could also do something like ZFS with much better deduplication and compression, or even FUSE to something like borg backup with true rsync style differential compression instead of block boundary based deltas (compresses slightly varying build artifacts really well, but slow and memory intensive).
How do you ensure it doesn’t include every non-human?
I’m not even asking about computation or algorithms. I straight up don’t think you can make a definition that isn’t a tautology or an approximation. Both of which are useful, but neither of which can fit a _proof_.
Every place on earth has some legal definition of who is human. The system I’m thinking of isn’t a technical/captcha one, it’s a human curated list of humans. Just an electronic ID. Those already exist but the challenge is making them (acceptably) privacy-preserving.
I want to take my existing national digital ID and use it online basically. BUT I don’t want the websites to know it’s me. Just that I’m human (or perhaps over a certain age). And I don’t want the ID issuer to know what site/service asked whether I’m a human or I’m 18 etc.
> Every place in earth has a legal definition of who is human.
I actually doubt that! And in places that do I doubt it’s perfection. Citizenship is mostly defined legally. Residency has a legal definition that may or may not track with reality. Most legal regimes I’m aware of (IANAL) define personhood; whether humanness is defined I’m less sure of. Things that are more nebulous and subjective…sometimes they’re defined, but necessarily subjectively so.
And that gets you into dangerous territory if you’re at the margins.
A fun example: how do you define “alive”? Does the person have to have been born? Are there conditions on that? Would they exclude some people we think of as alive? Does the person’s body need to be self-sufficient or can it rely on mechanical or other intervention? Is there a line? Is the person alive if their body is functioning but their brain is not? What about vice-versa? And even if the answers to all these questions are currently perfect, what happens if and when the definition shifts?
Being alive and human is messy business. And this is setting aside the discussion of making government issued records safely usable without leaking, which they already aren’t.
You're not wrong, but something can work well enough to still be useful despite falling short of the idea of a proof or any formal definition.
Let's say that 95% of individual humans can pass it and only 2% of bots. For someone maintaining a website, who has to decide between using this system and shutting down their site because of the increased costs, that may very well be good enough
That’s a pragmatic and understandable argument. And for an individual hobbyist site owner, that’s fine. Are we okay with excluding 1 person in 20 from the services of a midsized organization? What if they’re integral to the workplace? Or a major transport provider without differentiated competitors? What if the organization is a state government?
I don't mind apps, even apps that are basically just browsers showing a web site.
The biggest reason is that apps, at least on iOS, just behaves better. It might be that the auth persists longer or that there are notifications or whatever.
It's not without issues obviously. Most of the time the first thing I have to do is update the damn app just to order a burger or park my car or whatever it is I'm using it for. And it's dumb that we need to have a 150 meg download (per update...) for what's basically a bookmark.
But still, the better integration with my phone's native stuff like keychain etc usually means I'm more satisfied after using an app to do something, than using the _exact same web page_ in my mobile browser.
> Most of the time the first thing I have to do is update the damn app just to order a burger or park my car or whatever it is I'm using it for
It's interesting how different things bother people in different ways. Because when this happens to me, I want to throw my phone into the sun. It's a viscerally irritating experience that sticks with me for the rest of the day.
I have my essentials (browser, email, Signal) of course. But besides that, nearly all my apps fit into one of the following 3 categories: transit (airlines, rideshare, city bikes), finance (banks, brokerage), and...
baseball. MLB has put a shocking amount of effort into their apps. The ticketing experience is genuinely really good, so much better than any ticketmaster trash. All apps are trash, unless you're a baseball fan, in which case all but 2 apps are trash. I guess.
But if 50% of code can be converted automatically to safe idiomatic Rust? Great. Doesn't sound too far fetched. But yes, there's certainly a long tail here.
reply