> Xi's already suggested making the Yuan a global reserve currency, and seeing as much debt they're holding, I'm a little worried they're able to make it happen if this is the US financial strategy.
I wonder why you’re worried. Regime’s change all the time. From a third party perspective, China is no better or worse than the US. Also, given how literally every country under the sun despises US now, this might just happen.
The way China manages it's currency is very different to how the US manages theirs.
China maintains strict controls on capital flows in/out. A reserve currency requires free convertibility. Holders need to move large sums instantly without permission. China has repeatedly tightened these controls during stress periods (2015-16 devaluation fears, for example).
Limited access to Chinese bond markets and equities for foreign institutions. Reserve currency status requires deep, liquid markets where central banks can park hundreds of billions. US Treasury market is $26T and extremely liquid. Chinese government bond market is smaller and less accessible.
Reserve currency issuer must run persistent current account deficits to supply the world with currency. China's economic model is built on export surpluses. They'd need to fundamentally restructure their economy.
This is PRC's fundamental disagreement. US reserve currency morphed into high liquid, high speculative instrument to fund unsustainable debt, hollowed out domestic industry (triffin)... but this is not by design. It's the result of emergency adaptations moving off gold, then people post rationalize the trinity musts (open capital, floating rates, independent central bank) is what makes reserve when it's unintended structural outcome from failed gold peg.
Now we see hints of end stage USD reserve behavior, debt snow balls and reserve controller will pull the our dollar, your problem card. This US doing current conniptions trying to either reduce USD strength or inflate away debt... costly instability. People forget, liquidity / storage only matters to sovereign buyers who needs reserve for utility... everyone else (now plurality) are private buyers who buy for returns. If we enter end of dollar cycle and USD reserve cost them money, then they go elsewhere
Elsewhere is what PRC wants to offer, HIGHLY CONTROLLED, BUT STABLE reserve pegged to PRC industrial chains, i.e. real economy instead of speculative financialization. This what recent yuan reserve talk is from (note it was old Xi speech republished in Qiushi), so the propose model isn't even in response to current USD conniptions but prediction on end life of US behavior when USD reserve goes from exorbitant privilege to just exorbitant.
It's precisely because logical outcome of current reserve "musts", i.e. triffin charity/global good that makes it ultimately a stupid arrangement where the system breaks when US/owner can't afford to maintain or develops bad habits (deficit spending). Hence, what PRC plans to offer in parallel: stable regulated reserves for "real economy" financial utility. Stable Yuan "bank" reserve can coexist with volatile USD "casino" reserve. Now of course this all heterodox theory, but we are seeing theory of USD reserve limits peaking it's head, and PRC not retarded enough to pickup triffin baton. IMO PRC fine with US dealing with triffin headache and IMO betting US will fuck global creditors when shit hits fan, i.e. they waiting for USD reserve to implode due to inherent contradictions, to show world precisely why yuan reserve not modelled to repeat same mistake.
1. No one sane trusts EU after RU sanctions either.
2. Euro share of SWIFT shrunk from ~40% to ~20% post URK war. Part of this technical (t2 reforms), i.e. actual reduction not as dramatic, but Euro as toxic as USD with even less leverage.
Meanwhile PRC went from single digit % cross border settlements 10 years ago to 50%+, plenty of the world trust PRC with their money, not just money but PRC alternative to SWIFT financial plumbing, CIPS. Meanwhile PRC also recycling it's surplus USD to lending... i.e. they're financing more than imf/worldbank/paris club right now. Another indicator that countries "trusts" PRC to manage monetary system, or rather they balancing from losing trust of west.
TBH trust is western mindless muh reserve orthodoxy nonesense. Ultimately PRC has much stronger reserve posture for the same reason US did... for 80+ years countries needed USD for US techstack and then petrodollar, aka modernity was locked behind USD, all the other muh reserve "needs" is downstream of that. Need > trust.
Ironically where trust actually comes in is whether PRC TRUSTS others. Qiushi suggests PRC stable reserve functions something like panda bond lending, where PRC lends liquidity to trusted VIP (real economy) players. Everyone else can keep gambling with USD reserve with high likelihood of debasement. It looks like PRC doesn't want be THE reserve, they want to be VIP reserve while THE (USD) reserve burns.
> 1. No one sane trusts EU after RU sanctions either.
The RU sanctions were implemented 'only' because RU invaded another country. If you don't plan on invading countries is there much to worry about?
To a certain extent if you 'just' want to participate in the world economy the EUR seems fine. If you're looking to start geopolitical drama with military actions, is there any currency of a major economy that would not be a risk? Major powers tend to want stability, which would allow them to stay major, so would frown upon anyone stirring the pot (besides, perhaps, another major power: see China with Russia against UA/EU).
Europe wasn't breaking sovereign immunity / sovereign bank seizures when historically fighting each other, current actions historically unprecedented. So the answer is war is not sufficient excuse for RoW. EU extra delulu because RU/UKR not even over direct EU/NATO territory i.e. EU breaking sovereign immunity over "peripheral" interests. Like EU seize/sanction US when? Point of sovereign immunity is provide some semblance of neutrality for rest of world to do their thing while drunks fight, neutrals still want to buy from the drunks, EU has made things both hard not neutral.
Settlement and reserve currencies are two very different things. The USD isn't great as a reserve currency but it is still better than all the other options.
Settlement is leading indicator / proxy of trust. The point is countries trust in PRC running financial pipes is increasing, because vs US/EU, PRC simply look more responsible.
USD treasury isn't great now AND trending towards bag holding catastrophic "our dollar your problem" depending on debasement velocity. Hence central banks ditching dollar for gold etc... it's still currently better than other options in the sense that no other options really exist except metals with no counter party risk. More this happens the more exorbitant and less privilege USD becomes, the worse it serves as reserve, the more opening for alternatives. This where PRC eventually comes in, i.e. recent reserve talk is for eventuality not hand off. In the meantime they are banking on USD being not great, and getting worse. Which increases rates -> increase debt finance / servicing cost. The system is getting worse for everyone, including US. Don't underestimate watching US debt servicing growing from 1T to 2T in a few years when US realizes exorbitant reserve currency without privilege is not worth maintaining. Waiting for US to recognize USD reserve isn't great for US is part of the transition.
Swift is a neat language, but it’s a hard sell for server-side software. The ecosystem is tiny, and there’s nothing you gain from using it instead of Go or Rust for infra / distsys.
Also, it works okay at best with VS Code, and you couldn’t pay me to use Xcode.
Kotlin tried doing similar things to gain adoption on the server side. But server-side programming is a crowded space, and people just don’t like writing distsys code in another JVM language. Swift’s story is a little better on that front.
If you want a quick-and-dirty language, Python and TypeScript do the job. For perf-sensitive, highly concurrent environments, Go is hard to compete against. A lot of ops tooling and infra code is written in Go. For systems programming and embedded code, Rust is a better choice.
So while it’s fun to think about what language X gives you in terms of syntax, in practice it’s rarely enough to pick a language like Swift for your next non-toy backend distsys work.
Also, Apple. Given their stance against free and open source software, I wouldn't be too thrilled to pick a language that works better in their walled garden.
This makes me think you haven't really tried it ever? Sure writing a hello world is something but, one of the best features of Swift on the server side is that it seamlessly interopts with anything C (and nowadays C++, though that is after my time).
I wrote an entire, well performing backend in Swift because I could just directly plug in to already existing libraries without having ot provide a whole bunch of "FFI" glue.
All the other languages you suggest is something that Swift excels at while staying performant (also none of those have an IDE like Xcode so idk why you even bring it up). Though for actual systems programming I don't think Rust can be beaten by Swift, simply because of its more explicit (and therefore confronting) nature.
We use server side Swift extensively since about 2016 for decent production load and it's easily one of the worst decisions I've ever made.
- C/C++ interop is great but if we wanted to use C/C++ libraries why use Swift at all? It's annoying to interop with them even if there is no FFI and still requires a lot of glue code for memory management etc…
- The stdlib (Foundation) is not identical on all platforms even today. This has been a major thorn as releases constantly have discrepancies and subtle bugs that are hard to diagnose and track down. Even Swift 6.1 broke non UTF-8 string encodings by just returning "nil" on Linux and took until Swift 6.2 to be fixed (nearly a year).
- The compile times are awful, with a large Swift codebase it takes us ~10-20 minutes to compile our backend Docker container and thus deployments to dev take that long and it's only going to keep getting longer as Apple seemingly has no interest in making the Swift toolchain much faster and Swift has a fatal flaw in it's design around bi-directional type inference that ensure it can never be compiled fast.
- Talent is impossible to find. Yes lots of people know Swift for iOS apps but nobody knows Swift for server code and a backend dev is a very different skillset than an app dev.
We chose it because it allowed us to share some domain code between our flagship iOS product and the server with a custom built sync engine but as our platform has grown it's just gotten harder and harder to justify keeping Swift on the server which is why we're actively migrating off it.
> - The stdlib (Foundation) is not identical on all platforms even today. This has been a major thorn as releases constantly have discrepancies and subtle bugs that are hard to diagnose and track down. Even Swift 6.1 broke non UTF-8 string encodings by just returning "nil" on Linux and took until Swift 6.2 to be fixed (nearly a year).
sad, I was doing server side around v4/5 and this was the biggest issue at the time for me (lots of stuff was not implemented and you only found out at runtime). that this is still a problem is very disappointing...
I have been using Swift Vapor for personal projects for awhile and it's great. I kind of regret it now on some projects since I use a lot of Go too and I miss the speed of compiling/testing when I'm using agentic coding (where my goal is to put the agent into virtuous loops leading to a success state) - it just takes longer in Swift.
In agentic workflows, Go’s fast compiler and simple syntax make things so much easier.
I no longer write Python or JavaScript, even for trivial scripts. Why suffer sluggish performance or tooling nightmares when choosing a typed language no longer costs much?
As for Swift, it’s a harder sell. The docs aren’t there. The libraries aren’t that great. Apple-ism scares away a ton of folks, and the alternatives create less friction.
The target group for server-side software are iOS and macOS developers that also need a server component, thus like the JS folks, they get to use the same programming lanugage.
"Oh, it's another tool in your repertoire like Bash" doesn't garner billions of dollars in investment. So they have to address it as the next electricity or the internet, when in its current form, it's much closer to a crypto grift than it is to electricity.
This resonates with me too. I’ve written some Rust and a lot of Go. I find Rust syntax distastefully ugly, and the sluggish compilation speed doesn’t bring me any joy.
On top of that, Go has pretty much replaced my Python usage for scripting since it’s cheap to generate code and let the compiler catch obvious issues. Iteration in Rust is a lot slower, even with LLMs.
I get fasterthanlime’s rant against Go, but none of those criticisms apply to me. I write distributed-systems code for work where Go absolutely shines. I need fast compilation, self-contained binaries, and easy concurrency support. Also, the garbage collector lets me ignore things I genuinely couldn’t care less about - stuff Rust is generally good at. So choosing Go instead of Rust was kinda easy.
Do you ever get tired of playing this “visibility,” “impact,” “promo politics” game and think, “I came into this industry because I like computers, not… whatever this is”?
I've been all the way up to CTO in a mid-size company (650ish people), and I've felt like this in every role I've had at different times. Some places more than others. Where I was CTO wasn't too bad but that came at the cost of me not touching code at the company for several years because, at that level, and in the kind of company it was, you just really can't - not without finding yourself becoming a blocker anyway.
But I've worked in a couple of larger organisations - one of them, probably 90k employees, although it wasn't a tech company - and these issues are rife there as well. To some extent, I think it's just big company behaviour, not specific only to big tech companies.
Yeah. I’m not saying software work needs to happen in a silo, but man, the politics at large companies - where a certain group of people are constantly trying to get "ahead" of everyone else by yapping and backstabbing - get really tiring after a few years.
Yeah, completely exhausting. I get quickly worn out by environments where performatism (if that's a word) is too highly valued.
For me, I tend to work at my best when I've got a clear remit, and space to operate freely within that remit with my team without having to constantly seek approval and validation.
Whereas the need to perform/show off/be visible in order to deal with every tiny issue - which I've absolutely seen in one or two organisations - is just... no. No. That might work for some people but it is absolutely no way to get the best out of me.
At most organizational sizes, the hard problems are that of coordinating people and not software. It’s a hard decision, but ultimately if you want to scale the size of your impact - you have to make these tradeoffs.
Some folks want to scale impact. Some want to be bespoke crafters. Both are okay, you just have to accept they are mutually exclusive.
I agree with this. Making languages geared toward human ergonomics probably won’t be a thing going forward.
Go is positioned really well here, and Steve Yegge wrote a piece on why. The language is fast, less bloated than Python/TS, and less dogmatic than Java/Kotlin. LLMs can go wham with Go and the compiler will catch most of the obvious bugs. Faster compilation means you can iterate through a process pretty quickly.
Also, if I need abstraction that’s hard to achieve in Go, then it better be zero-cost like Rust. I don’t write Python for anything these days. I mean, why bother with uv, pip, ty, mypy, ruff, black, and whatever else when the Go compiler and the standard tooling work better than that decrepit Python tooling? And it costs almost nothing to make my scripts faster too.
I don’t yet know how I feel about Rust since LLMs still aren’t super good with it, but with Go, agentic coding is far more pleasurable and safer than Python/TS.
Python (with Qt, pyside) is still great for desktop GUI applications. My current project is all LLM generated (but mostly me-verified) Rust, wrapped in a thin Python application for the GUI, TUI, CLI, and web interfaces. There's also a Kotlin wrapper for running it on Android.
Yeah, Python is nice to work with in many contexts for sure. I mostly meant that I don’t personally use it as much anymore, since Go can do everything I need, and faster.
Plus the JS/Python dependency ecosystem is tiring. Yeah, I know there’s uv now, but even then I don’t see much reason to suffer through that when opting for an actually type-safe language costs me almost nothing.
Dynamic languages won’t go anywhere, but Go/Rust will eat up a pretty big chunk of the pie.
It’s easy to forget that any artifact - painting, music, text, or software - that appeals to a large number of people is, by definition, an average on the spectrum of quality.
Popular music tends to be generic. Popular content is mostly brainrot these days. Popular software is often a bloated mess because most users’ lives don’t revolve around software. They use software to get something done and move on.
I never understood the appeal of “craft” in software. Early computer pioneers were extremely limited by the tech of their time, so the software they hacked together felt artsy and crafty. Modern software feels industrial because it is industrial - it’s built in software factories.
Industrial software engineers don’t get paid to do art. There are research groups that do moonshot experiments, and you can be part of that if it’s your thing. But lamenting the lack of craft in industrial software is kind of pointless. Imagine if we’d stopped at crafty, handmade auto engines and never mass-produced them at scale. We don’t lament “crafty engines” anymore. If you want that, go buy a supercar.
Point is: AI is just another tool in the toolbox. It’s like Bash, except calling it that won’t pull in billions of dollars in investment. So “visionaries” call it ghost in the machine, singularity, overlord, and whatnot. It produces mediocre work and saves time writing proletariat software that powers the world. Crafty code doesn’t pay the bills.
But I’m not saying we shouldn’t seek out fun in computing. We absolutely should. It’s just that criticizing AI for not being able to produce art is an old thing. The goalpost keeps shifting, and these tools keep crushing it.
I don’t use AI to produce craft, because I don’t really do craft in software - I have other hobbies for that. But I absolutely, proudly use it to generate mediocre code that touches millions of people’s lives in some way.
Turso is sqlite with a server client arch. I use them for stashing my llm usage logs all the time. Pretty neat. Plus I'm rooting for them to rewrite sqlite in Rust.
If it is in-process (as the article says), why do you describe it as client / server architecture? If it’s not in-process why compare it to SQLite instead of other client server databases like Postgres?
I wonder why you’re worried. Regime’s change all the time. From a third party perspective, China is no better or worse than the US. Also, given how literally every country under the sun despises US now, this might just happen.
reply