florimondmanca

I see this answer is being downvoted; I’d be happy to discuss points of discord. I was definitely being radical on purpose — perhaps to highlight what seems to me as a blatant reality that our can’t go on forever (and that we can work towards remodeling so it doesn’t happen that way).

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. :)

This. Thank you for bringing this up. My take:

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.

Right! My “40 includes wind + gas” was confusing, and if that’s “40 on average”, my bad.

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.

I do recognize the value of renewables + gas as a transition strategy. :) And do appreciate what the UK has been doing there (using gas + renewables to eradicate coal).

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...)

> So even the company with a financial incentive to under-estimate the cost is saying that the electricity it produces will be at best as expensive as wind energy already is.

... 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.

Your introductory point about share of lobal emissions is something I think we as an industry don't really realize yet. So, to give some more precise numbers about that…

> 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)

[1]: https://www.atag.org/facts-figures.html

> it's is quite nice to use, at least compared to what I remember asyncio being like.

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...

Thoughts on this one [0]? :-)

[0]: https://github.com/encode/httpx/issues/752

I don't often comment on HN, but I feel like this time I have to step up.

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!

Python HTTPX co-maintainer here: AFAIK, Ruby's HTTPX did not inspire Python's HTTPX.

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...

[1]: https://github.com/encode/requests-async

On a side note, there has been work on an async HTTP client in a separate project conducted by the Encode organization here: https://github.com/encode/http3

Hi, thanks for your answer and interesting point of view!

To my defence, I wrote this post the very night I installed and fired up everything Vue-related. Having taken a step back now, it might sound a bit too theatrical. I've accomodated to the framework pretty quick, which either says a lot about Vue or that I have overreacted to the change in the first place.

I must return the note to you, though — do you, as a non-web developer I suppose, actually learn a new language everyday? I suppose you take Haskell from your experience but it may be an emblematic example only. The web development world (esp. frontend) has its own amount of newness (and hotness, to be frank) every so often. Not to play the "What kind of dev is the best" game here, just interested in discussing.

Also, I am genuinely interested in the usage of "web developer" vs. "software engineer". Why is it that you use a different term, e.g. why not "software developer"? As an engineering school student, web development is only part of my skills (and only its basics are taught in class, actually) and I see myself as a software engineer more than anything. Yet, you seem to exclude web development from software engineering. Am I just having the wrong definition?

Thanks