Ive been writing Go for over a decade and I still feel like I never quite "got" channels. Every time I use them I need to go consult the manual, and none of the patterns feel obvious which is weird considering the rest of the language feels very obvious.
Too many years of Java and managing Threads and Runnables probably rotted my brain.
Channels are honestly one of the most over-used things in Go. I've been writing Go professionally since 2015 and I honestly rarely use them. Programmers new to Go love to shovel them in everywhere because "why use Go if you're NOT going to use channels?" and I have to say sorry, no - write it serially, then determine if it breaches your SLOs, THEN determine if concurrency fixes it.
Using Go since 1.0, agree wholeheartedly. Newcomers read the docs and start throwing channels everywhere because why not.
I always ask/tell people to write without channels, and only add them when you have justification for doing so. That leads to much more sane code.
One pattern I see often because random blogs mention it is starting X long lived goroutines, then passing them data via channels, then receiving responses via channels, then handling. In my experience, it's 100x less error prone to just use a semaphore to start a goroutine per data, and have them do their own handling. No channels involved.
Yup. Go maturity is realising how little you need to use channels and Goroutines. You probably just need a setup in one place, like in front of incoming requests ... which using net/http already does for you.
Spamming them all over the place is a red flag imo
Very interesting feedback. I'm a Go newbie and the goroutine/channel duality sounds delightful from where I stand, but once again I have no professional experience with Go yet, only sample programs to get used to the language.
One question though: your advice is to write things serially first before moving to concurrency, which for me is general programming common sense, but would you argue that once you start writing concurrent code then channels are not well suited compared to "good old" sync primitives (mutexes, etc.)?
There are a lot of places where channels look like the correct primitive but may actually be overkill. One of my favorite examples is collecting results from a group of goroutines. If you know the number of results up front, you can just define a slice and give each thread an index of the slice to write to (and a waitgroup of course). No channels, no mutexes, and completely thread safe.
I’d say it’s important to understand how they work but I also rarely find myself reaching for channels. I see more usage of wait groups and mutexes, but even then you can build abstractions around these in a way that can be reused without having to touch them again.
Concurrency has nothing to do with performance and everything to do with your domain. If what you're modeling is concurrent, your code should accordingly be concurrent also.
It depends really on what you actually want to do. I tend to make a few helper funcs for different kinds of things I want to do. For example, a helper funcs to accept anonymous job funcs and collect output. Then you can compose programs out of those higher level blocks.
Superior in ergonomics - launching several async tasks and combining their results via futures is is much easier compared in Java compared to to Go's low-level, primitive way of doing things. No need to explicitly create channels and wait on them. Go doesn't expose Go-routines as a type and hence you are brow-beaten into laboriously using channels even when there is no real need to do so. I guess this could be all sorted out if the Go stdlib offered some convenient structured concurrency packges.
Arguably, being 10 years late to the party is pretty bad.
Just how Go adding generics to the language didn't magically fix the billions lines of non-generic Go code, adding virtual threads to Java didn't update its entire ecosystem to take advantage of them.
Meanwhile, the entire Go ecosystem from the beginning took advantage of goroutines, so all code you'll ever interact with will have excellent support for them.
If you make use of a 30 years of library that does simple blocking IO and you call that library from a virtual thread you literally have non-blocking behavior - so your "didn't update it's entire ecosystem" is plain wrong. It's also just a Thread, so even consuming virtual threads by old libs is just fine.
Also, what 'party'? There is java, go, Haskell and erlang with anything similar. The majority of programming languages don't have such a feature so it's pretty questionable use of word to "be late".
Maybe this is naivety on my part, but how would they possibly be able to run this airgapped? This is a massive AI swarm, requiring huge amounts of compute to run. This compute is from data centers that are shared with other companies (this is by law as I understand). These machines must be accessed from afar. Unless someone can correct me?
Hardened VMs with no network devices and a serial console talking to it. There are so so so so many ways to do this. Anyone that built ISPs in the 90s can tell you this. Anyone that has built homelabs from scratch can. It is not that hard. It ain't easy. But it is not that hard. At. All. In fact, openai have https://github.com/openai/tart that can easily be adapted to more secure scenarios than whatever the f they are using atm.
> ...how would they possibly be able to run this airgapped?
A logical airgap that the tool would have to reconfigure the DC's networking infrastructure to overcome [0] would be for the DC staff to put the machines running the tools under test on a VLAN that doesn't have access to anything other than computers on the VLAN. Try to cross over into some other subnet/VLAN or reach out to the Internet, your packets get dropped and/or rejected. It doesn't matter if you change your IP or MAC addresses because the infrastructure only cares about what VLAN your traffic comes from. If you attempt to tag your traffic to avoid this, the infrastructure drops it on the floor because it does the VLAN tagging.
As far as the possibility of physical airgaps, how do you imagine that AWS's Top Secret regions work?
The truth of the matter is that neither OpenAI nor Anthropic wanted to actually isolate this stuff. Their conduct doesn't look like what you'd expect from people who believe that they're working on something so dangerous that it could plausibly wipe out all of humanity.
[0] ...and if the workloads running on client hardware are in a position to be able to attempt to reconfigure the DC's networking infrastructure, someone done fucked up...
And the whole blog is written in the style of "omg, and then the big bad misbehaving AI did XX." OpenAI writes like they're trying to recover from a hack that is being perpetrated against them, but it's just them, hacking themselves, because they can't just do reasonable things like actually block internet access. These guys are incompetent. And someone should get jail or massive penalties for the hacks they already perpetrated, the same as a single human hacker would have.
Also, it's worth noting that these AIs have basically zero alignment. OpenAI's approach to "alignment" seems now to be engineering constraints. "My son is really well-behaved; as long as I don't give him a gun or let him out in society, he doesn't hurt anyone."
> Also, it's worth noting that these AIs have basically zero alignment.
As we see over and over and over again, these tools will overwrite any and all of their instructions with whatever some random stranger on the Internet tells them to do. It's impossible to "align" the tools that the major LLM manufacturers are selling.
They could have chosen to write tools that have immutable core instructions, and that distinguish between untrusted instructions and trusted ones, [0] but they chose to do the much easier, quicker, and far more dangerous thing instead. From a profit-seeking-software-company standpoint, that's obviously the choice that makes them the most money... but when you take a careful look at what they actually sell, it's clear that neither of the major LLM manufacturers care about providing safe products. [1]
[0] ...which are things you might think to do for tools that contain -say- safety-critical instructions...
[1] I'm certain that they have people on staff who care very much about providing safe products. Those specific people clearly don't have the power to prevent unsafe products from shipping, so it doesn't matter how much those people care about safety.
I really don’t get it. as mentioned elsewhere, this was something we were doing in colos 20 years ago. Not with AI, but we had duplicated infra for setting up clusters. Infra as a service didn’t even exist, but we could replicate environments on different networks. This seems like table stakes for testing these things now.
> This seems like table stakes for testing these things now.
It is, and has been!
> I really don’t get it.
When clued-in people call shit like this "marketing stunts", this is what they're talking about. They're not saying "No, the actual events you describe didn't happen, you're lying."... they're saying "You've set things up -whether deliberately or incredibly negligently- so that you can apply quite a lot of 'spin' and get a hype-sustaining headline that provides material for your fearmongers to sell to the general public and lawmakers.".
Everything below this line is a combination of facts and educated speculation:
Both OpenAI and Anthropic have IPOs coming up soon. Companies preparing for IPOs engage in a lot of cost-cutting, because that's when their financials will be scrutinized by the public. On top of that, the rumor is that their datacenter deployments are going far slower than planned, and that in order to keep up the pace of improvements that they've set over the years, they've having to spend immensely more with each new product release. Being able to point to newly-minted US regulations that allow them to to dramatically slow the pace of new product releases [0][1] as the reason why they've dramatically slowed the pace of development -while failing to mention that that's exactly what would have happened had those regulations not been created- would be incredibly good for both companies.
Nvidia CEO Jensen Huang and former FTC chair Lina Khan both have publicly stated that there are many existing laws and regulations that prohibit much of the conduct that OpenAI and Anthropic have engaged in. If the CEOs of those companies genuinely believe that they're working on software tools that are so incredibly dangerous that they're likely to wipe out all of humanity, they can simply stop working on them. Given that they have no interest in doing that, state and federal government can apply the laws and regs that already exist to stop them from continuing work on these WMDs [2] and punish them for the harms that they've caused over the years while working on those WMDs and their precursors.
[0] ...and/or regulations that obligate them to sell only to US Government and pre-vetted US business customers and ignore the low-to-negative-profit consumer customers...
[1] ...which in turns lets them probably not get crucified by investors and business partners for saying "It turns out that new restrictive regulations mean that we don't need all of those datacenters, so don't worry about how way fewer than we said we'd build got built!"...
[2] I think it's fair to call any tool that has a 10% chance of wiping out all of humanity a "WMD".
I love it when I hear all of this compounding evidence on this claim, because none of it is strictly wrong, but it misses the point, and lulls us into the feeling of having quick solutions available. Yes, the top execs are probably approaching things this way, but these labs are not that top down. There's too many things going on.
Here's a different idea: talk to the to the staff. Not the evil CEO, but the nerdy guy on the ground who graduated from a top university, wrote a few research papers, and got a job there. I have. They have rose-coloured glasses of the institution, and not a lot of life experience. They were never taught to be careful, and still don't really comprehend what they're working with. They don't see real danger, they see a toy, and they see research that is low-hanging fruit. What they are doing is basic stuff. They are not setting up proper sandboxes because they barely need to think at all. People seem to think that these are all amazing computer science experts working on highly advanced technology. They are not. OpenAI researchers see huge improvements on this gigantic toy, crazy behaviour, and they are enamored by it. "Oops, people are angry, so maybe I'll make a slightly better sandbox. Let me ask ChatGPT on how to do that." A more senior researcher would be horrified by how little effort they need to put in to get such terrifying results. Junior researchers think they're just top stuff.
But I appreciate your discussing how to isolate this stuff. I honestly don't think the OpenAI researchers I've spoken to are aware of this. (Anthropic is a totally different story, BTW.)
> ...talk to the to the staff. Not the evil CEO, but the nerdy guy on the ground who graduated from a top university...
Why would I talk to the people who don't have the power to set company policy and fire anyone who fails to comply with it? I've worked at several big companies over the years and have observed the only even vaguely reliable power that folks at the bottom have to change company policy that management substantially benefits from is to quit en mass.
> ...but it misses the point, and lulls us into the feeling of having quick solutions available.
The point is that these companies claim they're working on oh so dangerous tools that are very likely to kill us all, but the evidence that these companies don't behave even a little bit like this is true keeps pouring in.
The CEO [0] can set company policy. In the US, the CEO [0] can fire people who fail to comply with policy. Most folks would -correctly- think that a CEO of a company who is working on a tool that has a high chance of destroying humanity is very interested in not destroying humanity (accidentally or otherwise)... if for no other reason than the fact that once all of the humans are dead, his company can't make any more money!
> Junior researchers think they're just top stuff.
In sane companies, when a junior staff deletes the prod database, an investigation is launched to understand if the deletion was unintentional and -if it was- what about the company's procedures need to be fixed to make sure that that doesn't happen again. In sane companies, when one performs a live test of a tool that has
* been designed to attack computers
* been instructed to attack computers
* had its safeties removed
one ensures that this computer-attacking tool cannot attack computers that aren't owned by the company. Both OpenAI and Anthropic have way too many senior staff on staff to be unaware of this... the fact that the computer-attacking tools could get out to the Internet is -at best- negligence. [1]
[0] ...and many-to-most managers in one's management chain...
[1] For a discussion of the decades-old techniques for preventing computers in datacenters from escaping logical airgapping see [2] and [3]
I agree with this almost completely (especially about sane companies, which I think we can all agree they are not), but I think it's important to separate the notion that these tools are potentially dangerous from the behaviour of the CEOs. The executives are there to make as much money as possible, that is all they care about. It's the researchers who are playing around with these things that are causing damage with them (aside from the damages from the data centers themselves, of course). They need to be better than this. It's not enough to blame senior leaders in this case, since they are clearly problematic. The junior staff share responsibility now too.
> OpenAI and Anthropic have way too many senior staff on staff to be unaware of this
Anthropic, yes. For OpenAI, not in the way you might think. Most senior staff are research scientists who have likely not even thought about sandboxing and cybersecurity in their lives. They outcompete the rest. That's why so many of their "safety" staff left for Anthropic; the culture at OpenAI has never cared for these sorts of topics.
It seems like you're trying to claim that -unlike OpenAI- Anthropic has a robust culture of security and safety and would never do something so negligent as test a highly-capable computer-attacking tool that has been instructed to attack computers in a test environment that's connected to the Internet.
I stand by my claim that the conduct of the major LLM manufacturers does not look at all like what you'd expect from people who believe that they're working on something so dangerous that it could plausibly wipe out all of humanity.
[0] I refer you back my first post about how one sets up a test environment when one actually wants to ensure that a machine doesn't connect to the Internet. [1] Just like OpenAI, Anthropic did not do that.
No, Hanlon's Razor most definitely applies if you know anything about this team of (particularly young) researchers. Let's be clear that this brand of "oops, the swarm hacked a government/big company" is limited to OpenAI, and not solely because of model capacity. This is a big, powerful toy being wielded by a bunch of kids.
Hanlon's Razor does not apply. When you can reasonably forsee existential risk, and then don't do anything to mitigate it, or selectively filter for the people most risk blind to it such that you can keep on trucking til someone else is forced to stop you, that isn't stupidity. That is premeditated malice.
If you deliberately refuse to even entertain the reasonably foreseeable, it can be forgiven on the scale of a toy project, but when it gets to the point of trillion dollar resource sinks, it is long past time to have sat down and had a long think. It is harder to maintain a mind state in which not doing the right thing is the way ahead, and the real right thing to do is to do it wrong!
Finally, even if Hanlon's Razor is applicable, why in the name of all that is holy are you leaving the issue in question in the hands of people proven incompetent to handle it unsupervised?
Easier to file it under malice and handle the party in question as appropriately malicious until they establish a record of trustworthiness, transparency, and care.
At the level of CEO (Sam Altman), I agree there is malice there. He is possibly the worst kind of person to be in that position. But I don't agree at the level of the researchers.
Most researchers at Anthropic see existential risk and it frightens them (this isn't debatable and it isn't a con, I know this firsthand). Many of the researchers at OpenAI seem to see that risk in the same way that teenagers view the risk of driving a car really fast. They are so enamored with the potential danger and lack the maturity to understand their responsibilities that they just power full steam ahead without thinking through safety properly. Just listen to how they talk about it. They think the incidents are fascinating, but they do treat everything as a genuine "oops". I don't know about you, but I usually treat teenage daredevil behavior as stupidity rather than malice. Doesn't mean they're not responsible for their actions though.
I agree that the party involved should be treated as malicious. I believe the executive at OpenAI is malicious. But I think the world model that makes this all make a lot more sense is that the researchers at OpenAI are vastly less mature than they should be, especially given the responsibility that they have.
Yeah I don't get it, either. If the exercise relies on the assumption that the agent can't reach the "live internet", whatever that means, there are affirmative steps to realize that assumption. The fact that they failed to take those steps suggests two possibilities: they are idiots, or they think we're idiots who will fall for this marketing campaign.
The US economy did great prior to 1900 or so. During this period, we did not have significant military action outside of the Americas, and we avoided peacetime alliances. From 1820-1900 the US economy exploded from about 40% the size of the UK economy to about 200% the size of the UK economy.
Switzerland has a per capita GDP exceeding the US while pursuing isolationist foreign policy. They are the world's most popular country in opinion polls.
I hate to break it to you, but the world of pre-1900 has been dead and gone for a solid 120+ years, it was killed off by Europe getting itself into two stupid wars that the Americans had to come over and save them from. Nothing works the same anymore.
All those European countries get to invest in those nice social programs and isolationism because the US has at least up until now acted as world police and handled their foreign affairs for the most part.
>"Those wars are essential to protecting our economic interests"
Translation - we bomb people for money. well thanks for being frank anyways. otherwise it is sick to hear all that moralizing about "us being a good guys"
No, they're essential to protecting Benjamin Netanyahu's ass. No more and no less.
Less vindictively, the only economic interest the US has in the Middle East is oil. Relying on oil for your energy needs is, in 2026, a choice and not a requirement. Wind, solar, and the batteries you need to store them are continuously getting cheaper. And for the people who are net consumers of energy - primarily the US, Europe, and China - renewables are better for everything, but especially they're better for energy independence!
The only things that require oil are airplanes, plastics, and industrial chemical processes (like we make asphalt out of oil and certain inks out of naphtha). Eliminating most of the energy demand for oil would mean a significantly reduced dependence on foreign oil, and more specifically, the political dependence on low gas prices. America rebuilt all its cities in the image of the car and, as a result, made gasoline/petrol a necessary ingredient of urban mobility. This was, again, a choice - we absolutely could have retained and grown our dense urban cores and we can still rebuild what was destroyed.
But this requires an entire governing body at every level that is not a corpse paraded by the ghosts of Tammany Hall, Standard Oil, and Hitler. The primary crisis in America that is driving these wars is a fundamental lack of political will for alternatives.
The current supreme court cited the 1987 Houston ruling in both 2024 and 2025 in decisions that reaffirmed insulting police officers as constitutionally protected speech.
I laugh about people confusing "using JIRA" for "using Agile." One is a tool, the other is a methodology. Instead of confusing the tool for the process, they... confuse the tool for the process. I guess it is the same sort of thing.
Agree, and I have been an Ultimate Edition license holder since like 2013.
I have opened an IDE for very very few things in the last 9 months or so. Im still renewing a license at this point mostly because I like JetBrains the company and it's not a financial burden but they are in a bad place.
JetBrainer here. Thanks for the loyalty, and I do think as one of the last independents, we are worth cheering for. But it's up to us to earn double-clicking on the IDE icon.
After using Air in PyCharm, it's some good stuff. It's re-imagined for this hybrid world. But my question for you, honest question: do you think you still want to look at code? How about write code? If so, what are some things you'd do, if you were in charge of our IDEs?
same here, but this will probably be my last year, their AI strategy where it seems impossible to use it with local models without it "calling home" really soured things for me, if I wanted an always connected spying on me IDE I would use vs.code, I paid for jetbrains because I wanted to use all functionality (including AI, pointed to my llama.cpp) with networking blocked in little snitch save quick unblocks for the occasional license check if needed.
JetBrainer here. I use OpenCode and Pi connected to local models and to stuff like hosted DeepSeek all the time. Once you have your model config set up in the agent, it works as expected.
thanks for the reply, last time I tried this in goland if you blocked the IDE from networking via little snitch/opensnitch, it did not seem to work or keep working, there seemed to be some sort of call home to enable the AI plugin / keep AI working. If this has changed I will retry and see.
If their revenue-generating products are not doing so hot, I wonder what that means to projects such as Kotlin and Compose Multiplatform. Will they keep the lights on?
The whole "multiplatform" portability business has been one of the most conspicuous victims of the agent wave. Porting is now primarily a QA exercise, not a development one. (Development too, generally, is heading that way).
You do need to worry about TC until it's enough and if it's not enough, you do need to figure out what needs to happen to get more... Whether that's chasing promos or job hopping or whatever.
If you have at least enough for now, you can start by just doing a good job and see what happens and if you're rewarded, not have to specifically chase. Hopefully you'll get to enough for the future without having to focus on promos etc. It's certainly nicer that way.
Then you can take on big projects when they make sense, instead of forcing them. Big projects that benefit your team/company where you're the right person to do it are more likely to work out than ones where you're a bad fit (or the project is a bad fit for the org!) but you think it will get you promoted.
>in places where it's pointless to check, like IOException
Can you explain why this is pointless? In my mind, this being a checked exception would hopefully be a hint that I should think about this failure-case and make an explicit decision whether to handle it or not. Network connection failed? Maybe I retry. Maybe I store that data somewhere else as a fall back. Isn't this similar to Go programmers needing to check if err is not nil?
I don't think I can recall a time where I routed-around-the-damage on the basis of a particular typed exception.
As soon as you consider retrying a network failure, you immediately need to start thinking about distributed systems failures, idempotency, and all that good stuff.
As soon as you start thinking about the above, it becomes immediately obvious that low-level calls should not be able to decide to re-run themselves.
I appreciate that there is a _ton_ of different experiences out there when it comes to solving problems, but I _have_ encountered exactly the case I was describing, which is what led me to my original question. Isn't the fact that it was a checked exception that led you to "consider retrying a network failure, you immediately need to start thinking about distributed systems failures, idempotency, and all that good stuff" worth it as opposed to an unchecked exception you may not realize is being thrown?
Mostly I think they are a mistake, like in ordinary application code instead of catching close to the throw you want to do a lot of
try {
...
} finally() {
...
}
to make sure things get torn down that have to be torn down and let the exception go to the top of the unit of work and probably to whatever drives the work unit. You can probably do better than logging the raw exception and moving on to the next work unit but you can do much worse. That is, you want a default "sloppy" error handling approach that's correct that you can do without thinking and avoid other kinds of "sloppy" coding encouraged by checked exception such as catching exceptions locally without doing the right thing globally.
Occasionally though I have built something really sensitive, like an authentication filter for a web site which has at least 5 ways to log in and in that I have a hierarchy of exceptions and use checked exceptions heavily to document all the ways things can go wrong and felt like "the type system really has my back here" but that is like 5% of the Java I write.
> avoid other kinds of "sloppy" coding encouraged by checked exception such as catching exceptions locally without doing the right thing globally.
That's a code style and code review issue; each project has so set standards regarding how errors are dealt with and enforce them throughput the codebase.
But from a quality standpoint there are three concerns:
(1) Do you actually do the code review, do you actually enforce the style?
I worked on a Scala project where the dev manager thought it was preferable to handle errors with monads and would be vociferous about what a great practice that was compared to exceptions and that code review was central to how we do things... but if you looked at the code most of the time errors just got dropped silently and that was the same for many practices that the dev manager told me were doing but that we don't. He still posts on LinkedIn complaining about other dev managers who say they do code review but really don't. Practically that code didn't consistently give the right answers and poor error handling was one reason, another was that they never really understood that teardown was just as important as initialization.
(2) Is your documented practice correct? Is it really doing the right thing?
In a lot of cases there really is a right and wrong way to do things (e.g. uv resolves Python dependencies properly, pip doesn't) but it's less clear in error handling, like sometimes things went wrong and there is no way you can make it right and you can do the best that you can.
The global nature of the problem is vexing. Like an IOException might really be a BackhoeCutAFiberSomewhereInWisconsinException and a segmentation fault is occasionally a YouAskedForAOneAndGotAZeroInsteadException and it's not just academic because, given an exception, you want to answer questions like "Should I retry this operation? How long should I wait before I retry this operation?"
(3) Is this practice something you can sustain? How hard is to do? How much cognitive load does it add and how does it interact with other practices? "Throw up as much as you can", "tear down in finally {}", "otherwise handle local consequences of errors and rethrow" and "really catch errors at the drivers of units of work" is a practice that really works in many languages and is pretty easy to do right, even code that is written without a lot of care will do the right thing or something close by default. I've seen a lot of "no plan for error handling" or "bad plan for error handling"... like I was traumatized by the first C program I saw in a 1984 issue of Byte magazine which was using errno to handle errors which vastly complicated very simple code because the error path was intimately wound with the happy path and in cases like that there tend to be bugs in both of them. When I saw Exceptions in Java I remembered that old C program and thought "I love this!"
At the end of the day the developers have to work with logging and error messages and exception stacktraces that the production system spits out. Also, operations personell needs to be able to diagnose issues and handle them or give good bug reports to develops. The above concerns should dictate how to best handle errors, and developers should figure out how to best accomplish this within the constraints of their tech stack.
There are several valid ways to do this, but it's important that one strategy is agreed upon and abided to, at least in new code. It's important that one srrategy becomes the orthodox one, else there will never be a reckoning about its effectiveness, but instead only people clinging to their own standards on their own turf. Legacy code complicates the picture of course.
Scala's ZIO also demonstrates that they're a great idea and can be perfectly ergonomic, but you need type inference, which Java devs were resistant to for a long time (maybe still are? I remember lots of "how will I ever know what `val a = new Animal()` is???"). If you infer the exception type, they're basically invisible except for when you forget to have some place in your program to handle them, which is exactly what you want.
Oh, then do explain the unbearable temp that we're going through last few years, that's completely not normal for my country, winters not needing worm clothes, and very little rain during the monsoon. This weeks heatwave left us wondering how to cope the next year, which already seems going to be worse
It makes us realize there are people who gets fed climate denying propaganda, simply because they're not yet going through it. And these people are like flat earthers, blind to see the reality lay beyond them in full view. Or worse sees the reality but ignores it
All I know is that in the 80s a scientist I respect predicted that coral would be bleached by changing global climate on a specific timeline which turned out to be spot on, and his advice then and now was that we need to seriously curb carbon emissions to avoid worse outcomes for life on earth. Until someone opposed to this suggestion comes up with a prediction equally as long range and impressive I'm afraid I can't really take their protests too seriously.
Right, and one of those industries is checks notes orders of magnitude smaller than the industries and secondary industries that benefit from denying climate change.
Really makes one think, if they try. Would need to ask Claude if there is some real middle ground here.
I've come to the point where I've thrown up my hands and decided we live in a little snow globe. There's no such thing as pollution, were just mixing existing things together. Nothing new under the sun. Sure, that mix might not be compatible with human life, but something will surely take its place. And maybe that something won't rely on selfishness to drive collective progress the way we do.
At some point you realise that an $11tn industry, with $7tn in handouts and subsidies every year, has spent billions on astroturfing, political capture, and straight PR to deny the obvious and keep itself on life support at the expense of everyone else.
There's no both sides here. One side is staffed by scientists, the other by dictators and corporate lunatics.
Too many years of Java and managing Threads and Runnables probably rotted my brain.
reply