"The Immigration Reform and Control Act legalized most undocumented immigrants who had arrived in the country prior to January 1, 1982. The act altered U.S. immigration law by making it illegal to knowingly hire illegal immigrants, and establishing financial and other penalties for companies that employed illegal immigrants."

"By splitting the H-2 visa category created by the Immigration and Nationality Act of 1952, the 1986 law created the H-2A visa and H-2B visa categories, for temporary agricultural and non-agricultural workers, respectively."

"Despite the passage of the act, the population of undocumented immigrants rose from 5 million in 1986 to 11.1 million in 2013."

https://en.wikipedia.org/wiki/Immigration_Reform_and_Control...

Why have Danes turned against immigration?

...

In October the finance ministry, in its annual report on the issue, estimated that in 2018 immigrants from non-Western countries and their descendants drained from public finances a net 31bn kroner ($4.9bn), some 1.4% of GDP. Immigrants from Western countries, by contrast, contributed a net 7bn kroner (see chart). Data on immigration’s fiscal effects were what “changed the Social Democrats’ point of view”, says Torben Tranaes of the Danish Centre for Social Science Research.

Muslims are at the core of the issue. This year was the first time the ministry reported separately on the contributions by people from 24 Muslim countries. They account for 50% of the non-Westerners, but 77% of the drain. Alongside that worry are fears that Muslims bring notions about democracy and the role of women that Danes find threatening. Muslims are welcome, says Mr Tesfaye, but, “We can’t meet in the middle. It’s not half sharia and half the Danish constitution.”

...

https://archive.is/kXMi7

From Russ Cox this time: "Q. What language do you think Go is trying to displace? ... One of the surprises for me has been the variety of languages that new Go programmers used to use. When we launched, we were trying to explain Go to C++ programmers, but many of the programmers Go has attracted have come from more dynamic languages like Python or Ruby."

https://research.swtch.com/gotour

From Rob Pike himself: "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical."

However, the main design goal was to reduce build times at Google. This is why unused dependencies are a compile time error.

https://go.dev/talks/2012/splash.article#TOC_6.

I suppose Stuxnet could also count, where the initial infection depends on the human curiosity of plugging an unknown usb drive into an air gapped system.

Similarly, there's great demand for a typed layer on top of Javascript:

- Macromedia: (2000) ActionScript

- Google: (2006) GWT [Compiling Java to JS], and (2011) Dart

- Microsoft: (2012) Typescript

Let's take a made up example of a structural engineer designing a building. As another comment mentioned, in theory the design space here is enormous. Just the concrete mix can be endlessly optimized. But here there's a large monetary cost tradeoff that's obvious to everyone involved. Say an overenthusiastic junior proposes attempting to rediscover ancient Roman concrete mix for this project. Everyone from the other engineers to management can call that out as absurd.

In theory you can make the building out of anything. But in practice the economics of producing real world components only allows for a few choices in each stage of the design.

Meanwhile, software components are essentially free, especially if they're open source. Just clone the repo, hook up the code and you're done, right? So surprisingly often, the overenthusiastic junior can convince the whole company to build the new feature with some obscure framework that'll be unsupported in a few years. And no one can reliably call them out, because there's no easy, objective way to measure something like tech debt. (Another compounding problem is the rapid growth of the software field. Juniors are minted faster than they can be trained.)

To make the software example more concrete: there's an internal config language "blub" in one of the FAANGs that someone designed in two months. It looked simple, gained a lot of adoption quickly. Fast forward 5 years, and it turns out using blub was a big mistake. It scales terribly, the semantics were badly thought out and cause subtle bugs everywhere. But here's the kicker: there are now millions of lines of blub. Over the next decade, the company makes several very expensive attempts to replace blub and fails. Blub continues to underpin their production infra to this day.

So to sum up, I think maybe the core issue is not so much "3d space versus hyperbolic space". If you view the space as the tree of decisions you need to make to reach the goal, all engineers are working in hyperbolic space.

However, when designing real world things, economics rapidly culls the design tree. Buying materials requires cash up front. But in software it's often the opposite: you get the libraries "for free", and the unmeasurable tech debt accrues over time.