Lisp software like QUILC (linked) and Python software like Qiskit.
They have the role of taking general quantum programs (usually called "quantum circuits"), and translating+optimizing them for a particular quantum computer architecture (i.e., one that might only have a small number of supported quantum operations).
It's analogous to a language like C having a compiler (written in Lisp or Python) for ARM and x86.
I hesitate to give quantitative estimates without citations, but to throw a bone, something like: <2 years for Lisp by a small team of 4 relative newcomers. >4 years for Python by a larger team of >10 expert people. The software still does not have feature or performance parity.
I'm saying that making it easy to experiment with different gameplay mechanics is far more important than making it the most efficient. Even more so in case of small studios.
They reward tenure and respecting the hierarchy. Wonder what kind of positive (from western pov) skills and behaviours are fostered in that environment.
Regarding hierarchy, I have an anecdote about India. A manager told me that western teams are more likely to challenge a ticket than Indian teams, who hesitate to do that and are more likely to power through. His theory is that the culture makes it disrespectful to question the upper hierarchy, given its caste system, and causes a clash with western culture.
His solution was to communicate much more actively with the Indian team, to try to squeeze more feedback that they would hesitate to give at first.
It doesn't "explain" it, he doesn't work for Apple nor know their true intentions. It's entirely his conjecture from the POV of a reverse-engineer. In any case, his conclusion certainly doesn't align with a "less access is better" mentality:
> Advocate for Apple to provide access to their calibration re-provisioning processes instead [...] Them not providing those tools sucks and is anti-repair.
By that rationale, Marcan might actually support iFixit's decision here.
I'm not sure what is his take on iFixit decision, but he does provide some good explanations why some things are the way they are. I don't expect that Apple will officially provide better info, so that is probably the best we have. At least I haven't seen anyone with intimate knowledge of apple hw and sw provide a better or contradicting information.
If Rust had gone with green threads as the core async strategy (I know it was a thing pre-1.0), that would be terrible. You're not understanding Rust's design goals. Rust's async model, while it has several major pain points at present, is still undoubtedly superior for what Rust was made for. It would be a shame to throw all that away. Go can go do it's own thing (it has, evidently).
reply