> bubbles are notoriously unpredictable and generally don't happen when they are loudly and widely proclaimed to happen any minute now.
Is that true? It seemed to me that the most common opinion before the recent Chinese real estate crash was that it was a bubble; architect friends of mine who worked in China said the government had no doubt prices were unreasonably high; the thing they remained hopeful about is whether a soft landing was possible. Similarly it seems like it was by no means an uncommon opinion in the Japanese asset bubble, NFTs, beanie babies, and even the dotcom boom that this is (to use Greenspan’s phrase leading up to the dotcom bubble) “irrational exuberance”.
I also think its hard to know when it will pop. The Chinese real state bubble you are quoting is indeed a very good example. Everyone knew the prices were super high but no one really knew when it would blow. The state had a problem and they knew they had to stop it eventually. After/during the covid pandemic the state decided to start a slogan "houses are for living not for speculating" and they started to set redlines for leveraging and developing. If you know how financing works in china you know many of it flows through the state and related companies and financial structures. Then also when one of the biggest developers in the country blew up they left it to blow instead of buying it. They essentially popped it with policy.
So many would say the saw it coming but the truth is only people with inside info really knew when it would happen for sure.
Same happens today. Capital is being heavily allocated towards AI inference and infra because of the promised productivity. Nobody knows if its early or late and also nobody knows how will the state react to a possible bubble exploding. Some people would say maybe AI is too big to fall already and its better if we save it when it falls. Some people would say its better to let it blow up but again nobody knows what will truly happen until we get there.
Thomas Aquinas believed cruelty to animals was wrong not because animals have souls (and with that all the standard moral rights), but because it can teach us cruelty to other humans.
It’s still helpful to eg fold different phases in Nix, and different derivation output.
I work on garnix.io, which is exactly a Nix-based CI alternative for GitHub, and we had to build a lot of these small things to make the experience better.
We also do something similar at garnix, but when enabling incremental builds. Instead of just skipping the build stage, we also “normalize” the eval into just the store path, and skipping it the second time around.
Mentioned in passing in https://garnix.io/blog/incremental-builds. This is even more significant because in this case you might otherwise be eval-ing several layers of flakes.
You might be too deeply scarred to come close to it, but we just wrote a blog post about deploying NixOS servers without installing nix locally or provisioning work here that feels relevant: https://garnix.io/blog/hosting-nixos
if anyone is afraid of this happening to them, I'd recommend the deterministic nix installer. it has an atomic installation process where each step is reversible with the uninstaller. This is uniquely a macos issue since the setup is a bit different to other OS's in terms of creating a read only filesystem for the nix store, but the determinate installer was built to fix any worries of that happening.
can vouch for the detsys installer, and anecdotally, the resulting nix install seems more resilient across os updates. on a similar note, nix-darwin is a must-have. the typical nix-env stuff you see in introductions to nix on non-nixos systems really sells it short, as it feels like just another package manager to keep track of. by contrast, nix-darwin brings the centralised configuration.nix approach, which makes it way harder to hose your environment.
I looked at the docs, and it seems promising but I’d like to do something like: `garn add --dev git@2.3` and have git added at the given version as a dev tool. With config-as-code, is it possible?
It’s to allow interpolation of packages and environments. But in practice we don’t use it that often, so we were thinking of switching the main function to using just a second string argument. (In other words, I agree.)
import * as garn from "https://garn.io/ts/v0.0.14/mod.ts";
import * as pkgs from "https://garn.io/ts/v0.0.14/nixpkgs.ts";
export const main: garn.Executable = garn.shell`${pkgs.jq}/bin/jq --version`;
Put that in a 'garn.ts' file and run 'garn run main' and you should see the version of 'jq' that you can get from our 'nixpkgs' module.
But yeah, I completely agree with the sentiment here. This is a rather cumbersome syntax to support a use-case that we don't even have examples for. So clearly the normal usage shouldn't force you to use template strings.
