This wasn't GitHub's fault in any way.

Github personal access tokens are security footguns. This is an apparently old and forgotten image containing a token from 2023 and it the token gets you admin acces to their repos.

> virtually every other language used for game development was originally intended to solve other problems: ... JavaScript for enabling supply chain attacks, C++ for getting rid of your remaining toes

That's a good way to put it!

Incorrect. `become` does change drop order - https://play.rust-lang.org/?version=nightly&mode=debug&editi....

That's not implementing tail calls breaks things, that's bad design of implementing tail calls breaking things.

The whole idea of "let's change semantics to make it easier" is dumb.

If you want guaranteed tail calls, change your code until it works.

Measurement is for micro-optimizations, and it's definitely important. But you should also know the complexity.

Because complexity models that involve memory hierarchy are an active research area and are super complex. Also, "plain" complexity is still useful: despite the constant factor, at large N (and this is sometimes a real possibility) the complexity will still win. For example, despite binary search being less cache-friendly (it can be made more with some tricks but not the same), it still defeats linear search most of the time.

Moat of the time if you have at least several hundred elements. Benchmark it and see.

It is both amortized and average, because the map may need to grow. But the complexity without growing is average, not amortized (it's possible to build hash functions for which the probability will mean O(1) for all accesses, and hash functions which will be O(N) for all accesses).

Amortized is a bit different, though? It largely implies that there is a heavy cost periodically. Average just implies that it varies. Which, fair that "massive cost periodically" is compatible with that. Just seems to have a very different context, to me.

With hashtables, it was more that it was not guaranteed to be the minimal cost. Just, depending on statistics of the data that you feed to it, it shouldn't be the worst case.

Allegedly, there is Rust in macOS (but maybe not in iOS), so maybe it's true even if you're using Safari.

Why, when they have Swift for that role?

Rust is already used in production for embedded (although only here and there). Not all places are ready, but I don't believe it's a decade away anymore.

It really depends what you count as "used in production." I don't count "one Rust library crate linked into your Zephyr/FreeRTOS/whatever project." I have yet to see any production bare-metal codebase written exclusively in Rust, at least at the kind of scale I deal with.

If you're in the middle of a supply chain like I am, often times your code is actually a reference design that gets forked by an OEM, tweaked to their liking, and integrated into a product. If the OEMs don't know Rust, they aren't gonna like it if I start handing them Rust reference code. Spoiler alert: they don't know Rust!

It goes the other way, too. A huge part of my job is working with drivers from Microchip, or Infineon, or Nordic, or whoever. They won't give me drivers in Rust. I could LLM my way out of that problem, but now I fully own my drivers with no first-party support, which is a huge step backwards from the current state of the art.

This isn't Rust's fault, of course, but it means that there's a ton of inertia, and that magnifies the effects of the issues that are Rust's fault.

No, after this made some waves he or some other senior (I don't remember exactly) reported that this is not an official plan.

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.

There's an interop initiative by the Rust Foundation, there is a project goal to map the problem space, there was an effort to introduce an attribute (`#[rustc_splat]`) to allow calling overloaded functions, and there are various community-generated tools for more or less automated bindings generation.