Rust doesn't have this behavior (sometimes called "life before main"). Code to initialize a static variable runs either at compile time, or lazily on first access, depending on which mechanism you use.
Yeah, I don't think that "precompute something at compile-time" is really comparable to "every import literally executes code as a script". Rust imports are actually about as far from this as I can imagine, because modules can circularly reference each other, which unless I'm misunderstanding would be an infinite loop in Python without manually breaking the chain with some form of conditional.
I'm actually kind of surprised to see comments like that one, because compile-time logic feels like the opposite end of the spectrum from what Python imports do, with "regular" code being compiled without any precomputation sitting somewhere in the middle. It seems like I didn't articulate my thoughts clearly enough though, since several people seemed to read what I was saying as being comparable.
IIUC the organizations that most strongly pushed for this feature are big companies with large codebases. These tend not to be the kinds of orgs that just casually pull in dependencies from PyPI on a whim; I think it more likely that the quantity of first-party code was so large that importing all of it on startup was causing problems.
I worked in a codebase like this. The load time was insane.
We would also constantly need to put imports in function heads to effectively lazy import due to the massive risk of circular imports. We also had dynamic imports so tracking the cycles was very difficult at times.
Ok, good to see that they checked that possibility. Looks like there was no situation in which the previous behavior could have been usable, so yeah, agreeing with the change then.
I think the argument being made is that they don't have any meaningful power over Meta's corporate decision-makers, even if they do have power over some other people.
Right, but if you control access to a market of millions of people, a lot of companies will do what you say (i.e. follow your laws) in order to retain access to that market, as well as protect their local employees from jail. I would say that counts as meaningful power.
The new development is that the old articles from when the site was active have been taken offline. Normally you would leave old content online even if you're no longer making more.
It wouldn't have been that hard to do that from Zig if they'd wanted to. They don't, because they want to do everything themselves so that it works exactly the way they want (except the core JS engine for which this is infeasible—though even that has custom patches). After all, there are already plenty of libraries on npm for those other parts of the stack and they do work in Bun.
I think part of it is that most of Rust sets a really high standard for polish and good design; developers new to the language are often quite impressed by its expressiveness and by the breadth of bug classes it protects you from, once you get over the initial learning curve. (Not always—some developers never grow to like it, either because it's a bad fit for their use case or because they happen to find its particular forms of ceremony especially off-putting—but the success cases are striking.)
And then you start using async, which is less polished and has more awkward design compromises and more footguns that you only find out about at runtime, and it's a bit of a disappointment by comparison, even if some of the problems aren't worse than what you find in competing languages. This is the vibe you get in the Oxide RFDs about things like futurelock, for example.
In fairness, the post specifically mentions Amazon and Cloudflare, which are using Rust largely for backend stuff (though also for lower-level systems-y stuff, and I think Go is also a favored backend language at Cloudflare). But yes, other large tech companies (Google and Meta come to mind) are using Rust primarily for the lower-level systems-y stuff, where Go isn't an option and the alternative to Rust is C++. These applications are also less likely to need async and so don't have to deal with that set of rough edges.
My suspicion is that the causation mostly goes the other way—LLMs write like that for the same reason that many humans do, namely, that it's a cheap trick for sounding smart with limited effort and cognitive capacity. (My guess would be that em-dash usage among human writers is down in the LLM era because people don't want to be accused of being LLMs, though I don't have any data on this.)
reply