Rust is tier-1 language at Microsoft (rustfoundation.org)

nit: except in aviation

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.

LLMs are pretty bad at picking abstractions.

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.

Unlike Jai you can just download Odin and see for yourself, it has the particular things Bill prioritized (swizzling, a very particular way to do generic programming) and it doesn't have things which Bill feels are a mistake (most obviously package management, but also closures, first class user-defined types, macros, I could go on). The resulting perf isn't very good, and to me it "feels" clumsy to use.

One of the striking things in the Handmade languages is that they're so often wedded to LLVM and so in that respect they're much worse than C which of course isn't even wedded to modern architectural choices like 8-bit bytes, much less LLVM. Zig is the most free of this peculiar curse, which is ironic because years ago Bill called out Zig as unable to escape this, while insisting Odin would not require LLVM - the reverse of what actually transpired.

† In particular Bill thinks he's going to completely specify the language. Anyone who works on this problem for WG14 (C), WG21 (C++) or Rust knows that's basically a rabbit hole made entirely of more rabbit holes. I think Oracle's Java has a complete specification, and maybe TC39 has one for "Javascript" neither of those were uh, cheap or easy.

    > But I work in a space where C and C++ have been the only option for the last 30 years with absolutely no production-ready alternative.

Microsoft needs to choose for AOT Full Monty and leave the CLR behind.

I checked just now. A recent Delphi with a project open: 175-200MB. Water (our IDE, I work at RemObjects) about 300MB.

And that 90% could be an underestimate here.

I don’t have a problem with cars. But walking is still good for us.

Even LLMs use debuggers. I asked Claude to reverse engineer a closed source binary the other day. It used gdb to trace its behaviour. Didn’t even use ghidra.

I guess it depends on the bugs.

LLMs even INSIDE the (VS) debugger couldn't work out some of the more recent bugs I have been looking at. Never mind by statically looking at the code base.

Also I've been shadowbanned from a bunch of social media sites and had problems with payment systems, etc because Starlink confuses companies tracking user locations to geoips etc.

Won't even get into the apps that look downloaded and usable until you open them with no signal and they don't work before phoning home.

I've been meaning to go through ALL my apps and delete everything I don't use, I haven't installed a new app in years.

Then you have MacOS now that has the most "wtf" level permission prompts that make you think everything is phoning home or trying to access stuff on your network when it's just connecting bluetooth devices or something daily. I don't know how many games I've installed that now show up as having full screen or keyboard control permissions just to use input devices. I work on this stuff and can deduce what it's doing, especially after googling it, but "Stupidgame needs control of your system" is wild to someone who doesn't, I'm sure.

I've been wondering if it's almost nefarious that they want to get people used to allowing these seemingly system wide controls to be given to.. everything, by hiding the security-ok things behind a giant red flag warning.

Sorry went on a tangent. I miss specific permissions notifications I can trust.

edit: Oh, my "fix" for most of this is fakegps and mocking my android systemwide gps location to whatever, if you go through this.

"Keep calm and call clone" is a good strategy for getting things working. Don't prematurely optimize code until you know it's the bottleneck.

The point of these low/zero overhead languages like Rust is you're in an environment where memory management is ultra critical. The dotnet garbage collector does more than a good enough job for a weather app, likely a much better one than vibe coded .clone() Rust

Instead of oscillating between Rust and 1 GB webview apps just ... use the excellent managed language that exists on the operating system appropriate for GUI applications?

I have never written such Go, but as an experienced Rust programmer I can tell you Rust is not hard to write after learning it. Learning it can take more time than usual (although there is also contrary evidence, e.g. from Google) but after you're used to it, you're basically as proficient as in other languages, except some glitches (that can be expensive - rewriting your main structure, but are fortunately rare). Considering the effort involved in coding in such unnatural Go variant, I tend to believe it is far easier to code in Rust (including coding in Rust using this style, since it is more suited to it).

Of course, if you're just vibe coding everything, maybe it is easier because maybe the LLMs write such Go better that they write Rust. But if you're not, even if you're only reviewing the code, I believe it's easier to review Rust code than to review such Go code (and potentially than reviewing any Go code, but that is a different matter).

You'd get most of the benefits of Go and Rust.

If you have to iterate a lot the shape of your code... no, it is not any good at this...

> People did this a lot when rust was not as popular but there are plenty of very good rust programmers now who understand the language and can make programs that are significantly more performance for a marginal development cost.

Why isn't the game industry moving to it then? Bc it just cannot compete at volubility with C++, among other things. Yes, you can have skilled people, but the borrow checker is still there and that is an anti-change-me-fast fact of life. I think things like sending batches of info to the GPU in casted ways, alignment, etc. all go against safety naturally but this is fundamentally what needs to be done anyway when transfering data to the GPU, so adding a layer of safety for the sake of doing it to notice that your data-oriented pipeline has to suddenly change its shape would mean repeating work...

Namely, Rust is just not good at this. Rust is good if you can replicate a safe layer that is very reusable every time (when interacting with unsafe) or when you do not need unsafe at all or hardly, where you can take advantage of its safety fully.

Also, there are certain very tweaked data structures such as Boost.MultiIndex or linked lists with intrusive hooks and others that are not easy at all in Rust and they do have value in some situations. I had some of this in some telecommunication systems before.

One way is sure the native language + embedded scripting language combo but that's got the trap of impedance mismatch i.e. you spend all your time making engine not game then it overruns. But in any case having a way to iterate fast is a hidden productivity superpower, look at how many game studios have Live++ licences on their webpage;)

It notably doesn't have any plugins relevant in this scripting context. It only has themes/language syntax/servers, nothing about actual editing

Also worth noting that an event loop by itself doesn't give you serialization by itself, it can just allow you to gain concurrency without parallelism. You still need some form of serialization by way of something like actors (or async locks).