I believe BuildKit solves the dependency graph problem. Docker has shipped with it since 18.09. It is opt-in for now so you have to use e.g. `DOCKER_BUILDKIT=1 docker build ...`.
I have great respect for Rich Hickey and I recently saw a cool talk about a financial startup using Clojure in production [1]. I have kept track of the language for some time but have never had the chance to use it in any serious capacity.
They do not just show ads. They also display content.
Existing in a filter bubble has a strong effect on your perception. Perception has a direct influence on your actions. Couple this with interfaces which are purposefully addicting ("high user engagement" is a euphemism), and you can very directly influence behavior.
The pervasiveness of smartphones means that these apps are only a few clicks away for virtually the entire world population. And worse, once these apps are installed on your phone, they relentlessly pull you back in with and endless stream of notifications.
It is not only Facebook. Applications like Reddit, YouTube, Instagram, Twitter, and TikTok all follow the same basic patterns.
It is not an overly dramatic description. If anything the public has been frightfully unaware of the influence that these companies can exert on the world. I am glad that this film has brought these issues into the spotlight.
There was a huge discussion shortly after Julia 1.0 was released regarding scoping [1]. Beginners intuitively think of scoping in a manner different from the way scoping should work in production projects. There was a lot of tension between seasoned programmers and educators (who had to constantly interact with beginners).
The community exhausted the entire design space (along with some full-blown prototypes). Eventually, the core Julia team chose to use more forgiving scoping in the REPL (virtually always the first point of contact for beginners), while actual projects enforced stricter scoping rules.
My key take-away is to consider how the language interacts with its ecosystem, not just how it should ideally operate in isolation. I have found the Julia team to be consistent in this pursuit. If the first point of contact is intractable for beginners, the project is dead on arrival. A technical tool should be tailored for experts, but you don't want to kill adoption along the way. Engineering is tradeoffs.
"Language agnosticism" is an ideal I have never been able to attain. Sure, I can hack together a solution on the first week of learning a language. But, am I able to write elegant, idiomatic, efficient code during the first few months? No way.
A language is not just the basic control flow operations, but includes package management, performance gotchas, correctness gotchas, standard library, library ecosystem, data representation, etc. Then there are details and edge cases that you just don't hit without months or years of hard work with a language.
My experience tells me to take choose a reasonably robust language, then stick to that language until you have an overwhelmingly compelling reason to switch.
People seem to focus on the volume of cars. But traffic is not just a matter of volume but of friction between cars. Reducing the friction (naively) appears to be a simpler problem. You wouldn't even need full self driving, only enough tech for cars to merge/switch lanes without slowing down.
Not requiring a central point of control is an additional benefit. The reduction of traffic would be an "emergent" behavior.
https://github.com/moby/buildkit