I used to be excited about these, but after a year or so of having to drive near them in Midtown Atlanta I would get incredible dopamine out of watching them crushed for scrap.
They cause traffic obstructions during rush hour every single day. Blocking entire lanes of traffic to pick up Uber customers.
That’s not even the minimum wage in the United States. Most of these folks get paid $15+ per hour, but that being said of course I think it’s going to be way less than $5 an hour if you have a robot do it.
The workers are salaried. They’re getting paid for 8 hours of work irrespective of how long each task takes.
The physical LLM space (atleast Figure 3, Unitree, Gemini robotics etc) are doing on device processing and not over an API. So it costs what electricity costs.
Even the most powerful frontier models on SOTA hardware are not fast enough for starcraft, which generally involves multiple informed decisions per second at peak moments.
You can train a specialized model for this, but a frontier model is ill-fitting.
anything that can run those applications should be able to run a progressbar, but as I have learned it updated the progress bar based on bytes received and not based on time.
The semantic difference between an agent "going rogue", and a script that generates random valid curl requests is essentially pointless in the eyes of the law and responsibility.
From a technical standpoint, the difference is scale and intent, but ultimately people and/or and organization are culpable for the output.
Again, this isn't always how it works either. For example if a set of extraordinary conditions occur you can have little to no liability in many cases. It is way more complex than you're making it out to be.
I don’t know what your “again” is about - you haven’t been speaking to me here, but no, it’s quite simple and every major court case in the US has ruled as I described based on existing law.
Sure, usually the program can be changed to avoid the issue, but the key here is that the Rust compiler is wrong and needs to be fixed. Once fixed, the actual program fix also falls in place, as it cannot be compiled anymore.
I don't find that anyone made a claim that the program could not be fixed. Why are you suggesting to find a proof of this?
The point of course was not that what you can do, but what you should do. All cases of safe Rust compiler producing unsound code should be fixed, but the same argument is more difficult to make for C++.
Sometimes should might be different of what you must. For example, if your program exhibits unsound behavior in safe Rust (or C++) code, it's probably a lot more practical to just change the program so that it doesn't, instead of updating the compiler, unless you happen to be a Rust compiler developer. But, at the same time, you should file an issue about it.
You can of course find C++ compiler bugs as well, although I expect that to be quite rare nowadays. But the typical case is that if a C++ program exhibits unsound behavior, there is no reasonable compiler fix for it.
Then there's of course Fil-C! This improves the situation greatly by converting most interesting cases of unsound behavior into runtime errors. It seems not everyone is happy with the runtime costs of making this happen, though. And you must compile everything with Fil-C. It doesn't work with Windows or MacOS either.
Your shoulds and musts are nice and all but you said that in these situations, the rust compiler needs to be fixed when the C++ program can be adjusted.
I simply cannot imagine a situation where you can’t find an alternate solution to a problem with the compiler. Even if the compiler would optimize your intended solution away, you can write an asm! macro.
It sounds to me like you have simply decided that one language cannot do what the other can because you personally would not do it, which is very silly.
If this is not the case then I restate my request for an example, for the third time - an example would prove the point you are not making through explanation.
The original comment I replied to, in which you claimed that the difference between a safe Rust and C++ program with unsound behavior is that the C++ program needs to be fixed, but for the Rust program, the compiler needs to be fixed.
As I see it, in either case, the program can be fixed, or the compiler can be fixed. The only difference as I see it is that the C++ spec does not expect the compiler to be fixed.
I would say as stated there were two ways to read the claim:
- either that the claims are paired as you say (the second one implying that the program cannot be fixed),
- or that the claims are completely distinct, that simply state the desirable state of things.
Using the second interpretation, the corollaries would be:
- there is (typically) no reasonable fix for the C++ compiler that would address the UB. Therefore to fix the UB all C++ programs exhibiting the same need to be fixed, which is hard, as the compiler will keep accepting them.
- once the Rust compiler is fixed, then all safe Rust programs exploiting the bug must now be fixed, or the compiler will reject them.
What I would sign under would be the second interpretation, not the first one. But I intentionally also selected the particular ambiguous form due to the cutesy, albeit misleading, symmetry of the statements.
This is about an issue in the type checker, which would lead to unsoundness also in a C++ program. And also in Rust most causes of runtime failures are actually things that happen in `unsafe` blocks.
Yes, we're discussing though in safe (non-unsafe/normal) Rust here. There is no safe C++, everything in C++ is unsafe by default. Even more unsafe than Rust unsafe, because Rust unsafe still does a lot of the safety measures of normal Rust, but allows only a handful extra things and doesn't disable the borrow checker:
But getting back to the point, the C++ compiler doesn't have a borrow checker, so it can't have a bug in it. So it's on you, as the developer, to take care of all unsoundness.
While in Rust an issue is now filed, and with the fix, every future Rust program gets the fix.
I still like writing web applications in PHP for many of the same reasons listed here - modern PHP anyways.
I shy away from frameworks unless I am building something that I expect a large team to work on, or I specifically need multiple complex features that don't make sense to maintain.
I've written a few applications for my own personal use or targeted at friends/family recently that have no third party dependencies other than Bootstrap, which I still like more than tailwind for anything that doesn't need to look like a marketing page.
Given that we have had journalists prosecuted under criminal hacking statutes for discovering personal information in the rendered HTML of a web page, or publicly available attachments on a WordPress installation, I find the suggestion that intent is required to be dubious.
As someone who does think linguistically, I often end up at odds with people who are expecting me to imply things in my text, when my text is written specifically to convey exactly what I mean and nothing further.
I learned about it in high school, and that was 80s/90s but not by name per se. I took the ASVAB and there were questions like "fold a piece of paper in half twice, punch holes in a pattern, and then pick which image would be the result when the paper is unfolded" that I thought were ridiculously easy. I was told that they were difficult for people that cannot form mental images and these help test that ability.
> While the loss of mental imagery following brain lesions was first described more than a century ago, the key cerebral areas involved remain elusive. Here we report neuropsychological data from an architect (PL518) who lost his ability for visual imagery following a bilateral posterior cerebral artery (PCA) stroke. We compare his profile to three other patients with bilateral PCA stroke and another architect with a large PCA lesion confined to the right hemisphere. We also compare structural images of their lesions, aiming to delineate cerebral areas selectively lesioned in acquired aphantasia. When comparing the neuropsychological profile and structural magnetic resonance imaging (MRI) for the aphantasic architect PL518 to patients with either a comparable background (an architect) or bilateral PCA lesions, we find: (1) there is a large overlap of cognitive deficits between patients, with the very notable exception of aphantasia which only occurs in PL518, and (2) there is large overlap of the patients’ lesions. The only areas of selective lesion in PL518 is a small patch in the left fusiform gyrus as well as part of the right lingual gyrus. We suggest that these areas, and perhaps in particular the region in the left fusiform gyrus, play an important role in the cerebral network involved in visual imagery.
They cause traffic obstructions during rush hour every single day. Blocking entire lanes of traffic to pick up Uber customers.