florimondmanca
Joined 8 years ago
Joined 8 years ago
Instead, I see downvotes and the parent comment received a straw man argument. I wouldn’t be surprised if I was being seen as an « integrist », except trust me — I’m not. Please, let’s discuss and not fight against one another. I know HN is much better suited to that than some other platforms. :)
Thermo-industrial consumer societies don’t need to change. Rather, as you said, we need a system change. We need to swap our current model for something else. The outcome should (and will) be different from a thermo-industrial society — it will be another society altogether. What sort exactly I don’t know yet. But « a systemic problem can only be approached by systemic solutions » seems like a reasonable assumption to make. :)
If we don’t do it ourselves, then the currently overstretched Earth system will just regulate itself, causing pain and suffering. COVID might just be an appetizer of what lies ahead if we don’t realize old ways (more technology, keep the economy growing at all costs, etc, ie things that demand more or too energy or impede resiliency) are very likely to fail the test.
I like how you mentioned the Club of Rome’s report because it was an early work that goes beyond the scope of IPCC (whose role is limited to climate change, which to be clear has a ton of merits in its own right) and presents the problem for what it is: a systemic problem that is riddled with feedback loops and that has deep ties with the roots of our society model as it developed over the 20th century.
I don’t like the idea of a systemic change. It’s uncomfortable, and at first it sounds ludicrous. But if we’re serious and dig into the topic with a critical eye towards our own mental models, that’s a conclusion we reach very soon.
My point was to address the idea that nuclear is too costly as a long term solution, which I think (?) OP was using that cost/MWh comparison to intent.
FTR though, I do appreciate that gas + renewables can be a nice transition strategy (like the UK seems to have done to eradicate coal).
> There is no 30/70 split as you imagined.
It seems you understood I was talking about a 30/70 split in cost. That is not what I said: I was talking about a 30/70 split in usage.
But FTR, even in the sense I intended, you’re right, the number 30/70 is wrong, or at least it can only be valid under specific conditions that I’m not really able to quantify (electricity mix, coverage of demand, etc), and I hadn’t thought it through a lot.
My comment was addressing the pre-conceived idea that nuclear is too costly to be a long term solution. (Which I’m actually not sure the original comment meant, heh...)
... And be low-carbon (~10gCO2/kWh). Whereas the £40/MWh estimate for wind included gas power generation, which is at 400gCO2/kWh. Given how wind has a typical load factor of 20-30% max in Western Europe, you’d be using gas at best 70% of the time, meaning an average carbon intensity perhaps around 300gCO2/kWh.
So for the same price (or even double that as a first step - nuclear costs decrease radically with lower risks perceived by investors), nuclear gets you > 30x less carbon in the atmosphere than wind+gas. That is not insignificant.
> they're only used on such days, then the cost per Joule is even worse.
Nuclear isn’t like gas: it is fixed-costs infrastructure, meaning that the more you use it, cheaper it gets. So you want to use it as much as possible. (French nuclear plants oscillate between 75% and 90% load depending on maintenance schedules.) So on a windy day, nuclear load won’t typically change too much, but rather gas and coal usage will go down to let wind electricity match up with demand. This means nuclear gets you less emissions even in that case.
> data centers contribute 3% of global greenhouse emissions
Not true according to my research [0] — more like _Tech in general_ contributes ~4% of global GHG emissions. Within that, datacenters only represent ~20%. (The rest is 15% for networks, 20% for consumer devices consumption, and the remaining 45% for manufacturing of equipment.)
And also:
> (same amount as the entire airline indistry).
Air traffic accounts for ~2% of global GHG emissions [1], so Tech is actually twice as bad as air traffic there. Other ways to put it is: as much as all trucks on the planet, and 4x emissions of a country like France.
[0]: https://theshiftproject.org/wp-content/uploads/2018/11/Rappo... (FR) (p18, p20)
Yes, I agree. Fairly recently there's been anyio [0], which brings ideas from trio to other async libraries, in particular asyncio. E.g. it has equivalent of trio nurseries (what anyio calls "task groups") for implementing structured concurrency ideas in asyncio environments (saving you from headaches due to having to deal with tasks manually). Very neat way to use trio ideas when stuck on asyncio (e.g. for web apps). :)
anyio was also discussed in the latest Python Bytes episode [1].
[0]: https://github.com/agronholm/anyio
[1]: https://pythonbytes.fm/episodes/show/197/structured-concurre...
Having worked and developed with it extensively for over a year now, ASGI is one of the most elegant and well-designed interfaces I've seen.
Just wanted to address this:
> async generators exist for a good reason.
While the idea of using async generators might sound attractive at first, there's so much more to ASGI than exchanging messages in both directions.
Even on that aspect, I'd be interested in knowing how you'd achieve bidirectional communication async generators. How would the ASGI server call into the application and handle messages coming both ways? Surely, it can't just `async for message in agen: ...`, as that would only replicate the `send()` ASGI callback — what about `receive()`?
Besides, how would middleware look? Would it be as simple as wrapping `receive()` and `send()` into whichever other callable adds the functionality your middleware needs?
And you probably wouldn't be able to support all the possible syntactical implementations allowed by the notion of a Python callable: functions, classes, callable class instances.
So, yeah, I think ASGI is a beast.
Also, I wholeheartedly congratulate the Django team for pushing the standard out there and driving the Python async web ecosystem forward. You rock!
Eg. the name came from a totally unrelated discussion, and research did not yield results about Ruby's counterpart back then [0].
In fact, Python HTTPX started with requests-async [1], which was then spun up into httpcore, which was then renamed to http3, and finally HTTPX.
Still very funny to me that these two projects (Python HTTPX and Ruby HTTPX) have so much in common: HTTP/2 support, API compatibility with the current de-facto HTTP library of the language, etc.
[0]: https://github.com/python-http/discussions/issues/1#issuecom...