Err, no. If someone is at fault, it is definitely the company (OpenAI) not the employee in this case.
Just think, isn't the whole point of a company, of incorporating, is that the liability shifts from the employee to the firm?
It is 100% fair to hold the company responsible, and doubly so when the questionable thing the employee is doing is something that A) benefits the company, and B) is on company time (aand with company resources.) I know you weren't making a legal-minutia point but even the high level principles involved are and should be the opposite of what you suggest.
Companies may want to have their cake and eat it too (have employees do their dirty work but then push the blame on the employee) but that's not how it works and it's generally not a society you'd want to live in the more we head in that direction.
That's the difference between a profession and a job. If you work in a professional field, other people in the field will judge you by the standards of the profession.
Academic research is structured around people working under their own name and taking personal responsibility. Most people are employed, but employers are not directly involved in the research. Some people have more traditional jobs, but others will still judge them by the norms of the field. You can't use administrative loopholes to escape moral responsibility.
Employees can't have their cake and eat it too either. If you claim credit, you claim responsibility. If you claim that your employer is responsible, you claim that you had a supporting role and that you didn't make any intellectual contributions towards the result.
Someone in that industry can perhaps speak to it, but I have two cents of perspective...
I have helped a young person with gamedev interests try to learn rust (on Windows). They've learned some rust, but the graphics+Windows libraries and primitives to work with are not very good nor straightforward, even with AI assistance. Besides weakness in the gaming/rendering domain, there seemed to be some very real versioning/dependency hell that also didn't help.
It's massively easier to make progress on even just a 2D game with something like GDScript-based Godot (or Unity or...).
It seems like you're comparing "start from scratch in rust" to "start with an existing game engine in some other language". That's not really a fair comparison. there are popular game engines in rust (although i think they're mostly smaller/more niche then something like unity or godot), bevy comes to mind.
Those interested in this may find the following articles of interest:
Microsoft goals [edit: err, Microsoft hiring manager vision-casting goal ] to convert 1 billion lines of code to rust by 2030 via automated tooling enabling "1 engineer, 1 month, 1 million lines of code":
https://thenewstack.io/microsofts-bold-goal-replace-1b-lines...
It's less one guy's plan and more one Microsoft Research team's research goal to investigate technologies that might enable that in a few years. So probably more institutional support than just some guy, but less actually planning on succeeding in the full ambitious goal.
Sorry, by "official support" I mean that there is support within MSR to investigate these tools as a research project, no that there is a plan to actually do the conversion.
A headwind makes it harder to advance in the direction you're going. I think you might have meant to say "there is a strong tailwind towards memory safety".
Also in aviation, but with caveats; you want to take off and land with a headwind, because the headwind gives a greater airspeed which means greater lift.
This is true for takeoffs but not for landings. You want to land with a headwind because this means that for the same airspeed you have a lower groundspeed, i.e. when you actually touch down you're going slower on the runway than if you touched down at the same airspeed but with a tailwind.
No. Your calculated landing speed doesn't change depending on the winds, so you'll always be touching down at roughly the same airspeed for the same aircraft type, weight, and flap setting. Touching down with a headwind just means you don't need to use the brakes as hard.
It's beneficial on takeoff because headwind already factors into your airspeed before you even start rolling, which gives you more lift for the same groundspeed yes, enabling you to rotate sooner than you otherwise would.
The recommendation is qualified for typical apps that do not have extreme performance or scale requirements. They use Java for many, many things.
C++ is still indicated for systems that are optimizing for performance and scalability characteristics, since it intrinsically requires a lot of "unsafe" constructs.
> C++ is still indicated for systems that are optimizing for performance
The only evidence I've seen for this is that people with a vested interest in my believing this keep saying it is true. That's the exact same evidence I have for Trump having triumphed in Iran. Do better if you want me to believe you.
> since it intrinsically requires a lot of "unsafe" constructs.
This is an excellent reason to choose Rust. The whole point of Rust's technology is to enable you to encapsulate the tricky difficult part of the problem so that people don't blow their foot off working on the mundane parts of the software. And the truth is there are always mundane parts of the software.
I'm feeling generous so I'll add more here: Vec<T> illustrates how this works. This is a growable array type, C++ has std::vector<T> for much the same concept. But inside Vec<T> this encapsulation is used heavily so that there's a RawVec<T>, which doesn't care about knowing how many things are in the growable array, only about its capacity, then a RawVecInner which doesn't even care what things we're keeping in the array, it's just an appropriately large container for whatever it is, that RawVec<T> remembers what T is if that becomes important - and then a Cap which doesn't even contain things, it's just in charge of being able to represent the capacity correctly while having the same shape as "just" an integer but not always necessarily working like one.
Vec<T> is entirely safe to use, very pleasant, no danger. But internally it's extremely sophisticated, hence the layers of different types encapsulating different pieces of the problem to make a growable array type with excellent performance.
Tangent: your comment would have been stronger without the politics.
Btw, Rust ain't the only vector here. With an LLM at your side, you can also write your performance and safety critical parts in Lean and prove them correct.
Lean can compile to some pretty fast code. (Though it needs a bit more engineering work around eg SIMD to get really fast.)
I do think though, it is in the best interests for all compiled languages to eventually bootstrap themselves, instead of depending on either C or C++ for their implementation.
Either that, or we really need to keep improving C and C++ safety story, if they are to stay around on those language runtimes, or compiler backends.
I heard that unsafe rust is then unsafer than c++. I haven't learned rust yet, and I get that it's a tradeoff because the rest of the system can still be relied on. But how true is that first statement?
Rust allows much more aggressive optimization of the reference types than C++. If you have a &T, the compiler can assume that it will not change over the entire lifetime of the reference, and reorder things even past things that a C++ compiler would never reorder across. This can easily bite you badly if you have the mental model of C/C++ pointers and step into unsafe land. There is a separate warning for:
unsafe {
mem::transmute::<&T, &mut T>(t) //takes a &T, returns a &mut T
}
in the compiler because this is something that a lot of people think might be safe (I'm running single-threaded, everything would be so much simpler if I just mutated this bit while no-one's looking), but is in fact pretty much always UB of the nasal demons type. But there are more ways to step on this problem than the most apparent way, and the compiler is not able to protect you from all of them.
To be clear, just declaring a block to be unsafe does not immediately do anything in Rust, it just allows a set of primitives that are not normally available, so it is possible to use unsafe judiciously without immediately stepping into a million landmines. You just have to be careful and ideally read the docs and the nomicon page for the operations you do, especially if they are very long.
It's not helpful to think of it as "unsafer" but I think the way I'd explain this goes as follows:
Rust has some stricter and more complicated rules even than a language like C++. Just as in C++ you absolutely must obey these rules at all times. However, in Safe Rust the tooling will ensure that following those rules is never your problem. You don't even need to know what the rules are, just like you don't need to know why a plane works let alone how to fly it to get on a jetliner and fly across the country for $$$.
In unsafe Rust, it is your job as programmer to understand and obey these rules because the "unsafe super powers" you can use only in these blocks cannot be checked by the tooling, it can help sometimes but you can't rely on it. Writing ten lines of correct unsafe Rust is thus probably significantly harder than writing ten lines of C++. But the Rust programmer knows when they need to be at their sharpest, they need proper review by somebody paying attention, they need to slow down and think it through, versus the rest of the safe Rust where it's less scary, in C++ every line you write might be a fatal problem.
Basically, walking a tight rope is harder than everyday walking, but you know when you're on a tight rope, you've trained for it, everybody is focused on your safety - so actually maybe that's not a problem, lot of people get injured just walking about every day.
It's harder to write unsafe code in Rust. That doesn't make it "unsafer". What I mean is this, if you want to write unsafe code in Rust the C++ way, your entire program has to have unsafe markers everywhere. It's just as unsafe as C++ at that point.
But if you want to write unsafe code in Rust the Rust way, you run into a requirement that didn't exist in C or C++: The abstraction around the unsafe code must be safe for you to drop the unsafe marker. This created a unique category of abstractions that no other language has, so if you are working on unsafe code in Rust you are often a pioneer doing something never done before.
> This is an excellent reason to choose Rust. The whole point of Rust's technology is to enable you to encapsulate the tricky difficult part of the problem so that people don't blow their foot off working on the mundane parts of the software. And the truth is there are always mundane parts of the software.
The problem is that it actually sucks for dealing with the encapsulated parts. The reason everyone loves Rust is because they can just import a package where somebody else did the hard part for them and not worry their pretty little brains about a thing, getting high performance with minimal concern. That is a valid advantage, and that does make more mundane usage of the language safer. But it does not make the unsafe parts safer. There is every reason for having unsafe-oriented languages with ergonomics that actually make working with unsafe code more reliable too. The annoying thing about Rust is that 90% of its users are religious dogmatists who insist that Rust is the only valid language rather than accepting different languages can have different advantages, and moreover that 90% is basically the 90% who are benefitting from Rust while not being the ones who have to write unsafe code themselves.
The autovectorizer works quite well in llvm with all the aliasing guarantees rust gives it. Especially now fastmath hit so wide types aren't necessary anymore. I don't need unsafe or crates that use unsafe to beat the performance of c++. If you are doing something very specific with niche intrinsics llvm can't use, then maybe I'd have to use unsafe. But I don't run into that. Rust is faster for the same reasons it avoids UB. Also the Kool aid comes in multiple flavors!
If that is the benchmark Erlang is way better. Java has weird delay time when JVM goes into garbage collection mode. You can finely tune it, but if you work at embedded STM32 level with serial connections where hard realtime and hardcore deterministic executions, Java is nowhere near what Rust and C++ can do. The main reason is the JVM. Different languages have different niche. Some hardcore Rust and C/C++ niche, I dont see Java can touch.
Java can and has been used for real-time systems, but it does not look like the Java that you would come across in normal programs. Obviously, RTOS have specific requirements, which usually rule out GCs and other runtimes, where even "regular" Rust would not work. The discussion here however was for (long running) backend systems running on regular hardware. ZGC is able to achieve sub-ms pauses.
This is so untrue I still don't know how anyone can even claim this. When I run tests in Rust, the biggest portion of the time is spent compiling the test (lets say 3-4 seconds), then the tests conclude practically instantly, in less than half a second.
Meanwhile when I run tests on my JVM projects it can take 30 seconds just to start and the test execution is extremely slow too.
Even if you do manage to match the performance after warmup, you still have the issue that keeping the class files in RAM plus the JIT compilation state will cost more memory than simply running AOT compiled code. You simply cannot write processes that use a single digit MiB amount of memory on a JVM and getting down to 2 digits is theoretically possible but requires significant effort.
Once you get into the micro optimizations like the lack of mutable aliasing in Rust, there is significantly more potential for auto vectorization.
What you mean by "real world systems" is probably defined in such a narrow way that all the weaknesses of Java programs don't count anymore.
> This is so untrue I still don't know how anyone can even claim this.
Because it's referring to long running processes, AKA the kind of things where hot paths can be JITted into faster native code than is possible from static compilation because the JIT has information about the real-world usage patterns.
> Meanwhile when I run tests on my JVM projects it can take 30 seconds just to start
That strongly implies you're using some sort of framework that's doing a _lot_ of initialization. That's not JVM startup time, don't be intellectually dishonest here.
> You simply cannot write processes that use a single digit MiB amount of memory on a JVM and getting down to 2 digits is theoretically possible but requires significant effort.
Again, the main use case for Java is long running server processes. No one cares if the binary is 1, 10, or 100MB or if it consumes 2, 3, or 4x the memory as long as the throughput is there. And Java has a long track record of delivering very good performance in those contexts, coupled with an extremely rich and mature library/tooling ecosystem.
I think this used to be true more than it is now. Memory has been relatively expensive in cloud environments for a while (often 2x the price of an ec2 node for an equivalent with 2x RAM) and DRAM shortages aren't helping.
For the most part yeah but does depend on scale. For Java there are lower cost migration pathways like native compilation anyway if that does become your concern
It's not untrue, there are people who have observed this, and for a long time now. AOT compilers assume a closed world system, whereas JIT are able to perform runtime optimizations that AOT can't.
By real world systems, I mean long running real server-side systems that run things that you use day to day by large corporations serving millions of users.
Are you able to share some of the tests you are running, and which frameworks are you using? Now with project leyden and similar efforts, start up time has been cut drastically.
There is no way they can re-write everything in Rust by 2030. No way. Even new projects are modern C++ at MSFT. Some teams are creating their Rust/C++ binding but that's a very small fraction.
It would be possible for me to give a more nuanced take, but the upshot is: none of that shit is going to work 100%.
One may get local maxima like an unsafe bonanza, or something that introduces a custom runtime memory management discipline at the cost of performance etc. Fully equivalent C++ to Rust in full generality is mainly wishful thinking. Of course that does not mean one should not try it.
Oh, I 100% agree. The question is how much you can reduce the effort of the port/migration, and in particular the validation effort.
I've worked on projects where the core bits of code were "90%" converted by some automated tool, and in my view the overall benefit to the project timeline was probably only 20-30% because of the Amdahl's-law-type overheads of validation and bits of code not supported by the automation/conversion process. Nice, but no silver bullet.
Non-idiomatic porting also isn't super-helpful if the resulting code isn't maintainable.
As I pointed out in a sibling comment, the plan isn't for it to work. This is a job posting for a researcher at MSR to investigate what it might look like someday.
LLMs are unusually good at Rust; it's an optimization target. And the constraints provided by "successfully compile with the Rust compiler" make it work well for agent iteration.
(I have mixed feelings about that, but empirically it holds true.)
Yes, I found these agents to be better at producing acceptable Rust than at producing acceptable Python code.
In addition to the Rust compiler, you can also tell them to make clippy happy. Both in normal mode or if you are feeling nitpicky, you can also tell them to make clippy::pedantic happy.
FWIW, I wouldn't recommend turning on all of `clippy::pedantic` as a unit. It's a category of lints, but some of them have much more value than others, and turning them all on may make your experience of Rust feel unpleasant and nitpicky.
Can you give an example where an LLM produced low quality Python code? Python is such a simple language. This seems hard to imagine. Plus, the amount of open source Python that LLMs can be trained upon is enormous.
Most people it's good at syntax and the error messages give you a good loop. But the domains rust actually makes sense in tend to be quite punishing on slop both culturally and technically.
To add to this, I find that the delta between the amount of code and pain you get with good and bad abstractions is substantially higher in rust than other languages. It's alright to muddle through in Python or TS, but with Rust bad abstractions are punishing.
Hey now, sure, Microsoft Bob didn't get us ordinary users a "partner that helps you by making it easier", but it DID help MS Bob product owner Melinda French get a "partner that helps you by getting 10+ billion dollars" in the end, amiright?
<joking>
Maybe IBM is signalling it is likewise hoping for 10 billion dollars while also realizing the (AI) partner might not end up being that helpful either??
Ugh. This analysis starts off a little interesting with its observation that "intelligence", as analyzed historically, tends to be about solving bounded-context problems (with a known right answer) rather than open-ended problems (D&D called this "wisdom", right?)
But it is lacking so, so, so much in explaining why smart people aren't happier or evaluating the premises of the question.
If my teenager gave me this analysis and question, I'd give them 8 more avenues to explore, none of which the article addresses:
1) Is intelligence Kahneman's "type 1 thinking" or "type 2"? Do people (including you) act on their thinking or their emotions? (Can/do you think smart + act dumb and end up happy?)
2) What does being happy have to do with having autonomy and control and purpose? (Existentialism)
3) What does happiness have to do with contentment and the scope of what one wants to control, ie ambition? Attachment? (Buddhism)
4) What does happiness have to do with one's overall outlook of being pessimistic or optimistic?
5) Is there some deeper insight why a widespread religious tradition such as the Judeo-Christian one has a creation story where where "knowledge of good and evil" is inherently problematic?
6) What does happiness have to do with dopamine and the timing or frequency of solving problems of small vs large size? What degree of problems need to be present for an intelligent problem-solver to be happy vs, say, bored, (example: Marvin the "brain the size of a planet" android in Hitchhiker's Guide to the Galaxy, bored and depressed?)
7) What is the connection between happiness and benevolence, giving vs receiving? Relationships? Why?
8) Why does a socio-economic system based on money-maxxing intended to obtain happiness lead to oversupply which leads to demand-generation/creation/marketing which leads to unhappiness? And similarly leads to conflict and resulting unhappiness? Is there an inherent ying/yang dynamic to intelligence and happiness on a personal or socioeconomic systems level?
I do agree with the author that it's a question worth re-evaluating in an age of "Artificial Intelligence" promises.
It's a blog post. Unless you're reading Gwern or something, you shouldn't expect a really deep comprehensive take on an issue this ill-defined. I mean what does happiness mean? Its hard enough to get people to agree on that.
Regarding the "expensive overhead of boxed types", do we just need more work at the hardware ISA level (with pointer tagging or NaN-boxing) and we need the hardware to be aware of those bits and handle them safely/properly via some minor extensions to RISC-V or Intel/AMD/Apple ISAs?
Or do we have to have completely new forms of hardware datatypes?
Last time I went to donate blood, I read all the fine print they asked me to sign, and I was giving them the right to sequence my DNA (!)
The tech taking my blood had no idea; nobody else had ever read it.
I did complain and ask the blood donation org to make sequencing opt-in and my message was "passed on to leadership" but with no followup from "leadership."
Just think, isn't the whole point of a company, of incorporating, is that the liability shifts from the employee to the firm?
It is 100% fair to hold the company responsible, and doubly so when the questionable thing the employee is doing is something that A) benefits the company, and B) is on company time (aand with company resources.) I know you weren't making a legal-minutia point but even the high level principles involved are and should be the opposite of what you suggest.
Companies may want to have their cake and eat it too (have employees do their dirty work but then push the blame on the employee) but that's not how it works and it's generally not a society you'd want to live in the more we head in that direction.
reply