It seems to me the main problem is we build so little of it that we don't have the people, skills, supply chains etc to do it well. China generally builds it's reactors on schedule and within budget.
What it does allow is for Google and the governemt to say these data centres aren’t generating any co2
Of course everyone’s else’s co2 emissions then increase instead.
The only solution is more zero co2 emissions. Google could have funded large wind farms, or a new nuclear plant, or grid connections to other locations. But that would cost more.
Only if demand increases to the point where supply cannot meet demand in a short enough time frame. Capacity is a factor here.
You buying a doughnut - even half the doughnuts - from a doughnut shop does not increase the price of the remaining doughnuts unless they can't make enough to satisfy remaining demand and people are willing to outbid you rather than wait.
Does that power station have enough capacity to satisfy the remaining demand?
I don't have any actual experience with React Native and Electron, but with that caveat out of the way I personally think tools get far too much blame that should be on developers.
For an example that I actually have experience with, React very frequently gets criticized for being slow, heavy etc. React is not slow. I can make (have made) fast and snappy websites in react. React can render at more than 60fps if necessary, and if the code isn't shit. The fact that someone else has made a slow buggy mess with React does not prove that react is bad, it simply proves that the developers are bad. At this point, someone will typically interject with something along the lines of "but react makes it hard to make fast websites" and to that I simply say no it doesn't. I've seen what makes react apps slow, and it's generally just bad code. The developers who make shitty react apps would make equally shitty apps with any tool because they're the problem not the tool. They don't know how to build good software and literally no tool can help them because it's simply a matter of understanding programming and the sad fact is most developers suck at programming.
I graduated university with about 200 others and out of those people who have the same degree as I do, very few were even decent at programming. I know that because I was the guy who helped them complete their assignments and I was a TA in several different classes, and I'm telling you the overwhelming majority of students sucked at programming even after 2-3 years of studying it.
After graduating I've worked on many different web apps and other stuff, and I've seen an overwhelming trend of trash code and bad developers. The people who actually care about writing good software and have the mental facilities to do so are few and far between. And that's why most software sucks. A good developer can write good software using pretty much any of the popular tools. The tools are just different ways to do the same stuff. Sure there's some overhead with react etc but it's really not that significant, the significant part is all the trash code people put on top of it.
> React can render at more than 60fps if necessary, and if the code isn't shit.
Sorry, that doesn't really come across as a ringing endorsement. React apps are typically not doing anything complex so rendering at less than 60fps should only happen if you're doing very computationally intensive things or writing bottom-quartile quality code.
Yeah, obviously your average React app has no need to render anywhere near that frequently. The ones I've worked on will generally only render as a response to user action, server event or polling.
I'm just saying they can render that fast. So if your app takes a second (or several) to render it's obviously not because react is slow, it's because the code is ass.
In most cases if a React app takes a long time to render a page it isn't really rendering that's taking time, it's a slow network call or multiple. So the app being slow has nothing to do with React at all, it's the backend code that's slow or it's the frontend code doing multiple consecutive requests or something like that.
All I'm saying is react is not the reason it's slow.
I recently tried star citizen and it's kind of trying to be something like that but it's way too half baked with lots of game breaking bugs like you'll just lose the entire cargo of your ship which can completely bankrupt you after days of saving up. Also they keep releasing bigger and fancier pay to win ships at ridiculous price points like hundreds and even thousands of dollars instead of fixing the game. I tried it during a free week and I legitimately enjoyed it a lot but I was also extremely frustrated a lot by the bugs and the pay to win crap really rubs me the wrong way so I didn't buy it after the free trial ended.
It's a weird mix of amazingly well done and absolute garbage. And pay to win. Don't forget about the pay to win bullshit.
I don't know about the PTW aspect. What's there to win in a broken sandbox? In my view, they mostly just keep ripping off delusional "collectors" to keep the gravy train going. It's not like these solo players then take off in their huge multi-crew ships and are able to "win" in any meaningful sense.
A few years ago, I had a couple dozen hours of good fun with my starter pack just zooming around all those moons and planets, stepping out of my tiny ship and holding my breath, not knowing much about what awaits me outside - scorching heat, a blizzard, hostile or friendly players... it felt like I got my money's worth if space immersion.
If you don't expect much in the way of an actual game, but are content with a few game loops held together by string and duct tape, you can find a vast and pretty universe to explore.
Reeaallyyy gotta manage your expectations, though. It's very much an alpha, and you better not think it's gonna release, like, ever. Disclaimer: I have no idea how it's evolved in the past years.
Well there is pvp and the ship also helps with PvE progression. So I don't know how you figure it isn't p2w. Buy better ship, have advantage over others. It's not just a cosmetic upgrade. That makes it p2w.
It's a common complaint that people lose control of their codebase using LLMs. It always strikes me as odd, because this is a choice you make when you use the tool.
You don't have to just give it a task, let it do whatever it wants, then accept the result. You can tell it how to do things. You can read the changes. You can ask it to do things differently.
You choose to relinquish all control and then complain that you don't like not being in control. It's all about the level of involvement you choose for yourself. It's not all or nothing, you don't have to go full vibe coder it's a spectrum and you choose where you want to be on that spectrum.
Even with manual reviewing, most of its changes will look relatively reasonable when approving every chunk... until you come across one that doesn't, and then it'll be a neverending chain of 'wait why tf does it do this? Why does it work this way?'
This is not a problem I've had. I know roughly what I want before I ask for it, I make sure the result is roughly what I expected. Some times if I'm not entirely sure what I want I'll ask it to plan the change or suggest some approaches etc then choose the one I prefer.
For me it works great. My judgement is that I get things done significantly faster, and generally with comparable or better quality than I would doing it manually. It's important to lay a good foundation, if you are careful with the broad strokes it helps the LLM lay the rest down more consistently. It's also a lot easier to refactor things when the need becomes apparent.
I generally prefer small increments yes but I don't shy away from larger changes where necessary. Just like everyone hated reviewing a 4000 line PR before LLMs, we all still hate it now, provided you actually do review things properly and not just tell Claude to do it or skim it lazily.
I wouldn't say I make the LLM restrict it's output, rather I'd say I just don't ask for a lot at once. If I want to create a new page in our web app I'll split it up into multiple tasks - create the new page with the required layout and add it to the navigation. Create a new component we need for this page, put it on the page so it can be tested. Create another component. Add an endpoint to the API for getting the necessary data. Use these existing components and the new ones to build the final page. At each step I test and verify that it works properly, and review the code to make sure it's reasonable. I might make several pull requests or just one depending on the size of the task and what makes sense to me. In general I want a PR to be testable, just a component isn't testable if it isn't used so it has to be used. I also don't do a PR that isn't production ready, so I won't submit a PR with just a test page.
If it's a very simple page where we have most or all necessary components I might just send a screenshot from Figma along with instructions to use existing components and what data to use, CSS variables and whatever else and have it try to one-shot it. I generally don't want a PR to have more than a few hundred lines total. I review and test the code at each step and finally I review the whole PR myself before submitting it to colleagues.
I don't think anyone chooses to relinquish all control from a project they've worked hard on. It's a slippery slope. You start with allowing it to help out a tiny bit, being in control and understanding the code the LLM writes, and then you become more confident in the results, and you trust it, and you don't read every line, and before long its refactoring an entire file by itself and you're not reading it.
And then you look up one day and you don't recognise the codebase
I'm able to avoid slipping down that slope, just don't be lazy. If you look up one day and don't recognize the codebase that's because you haven't actually looked at it in a long time. Obviously when you don't pay attention you miss things. Just pay attention, it's not hard. There's plenty of time for it while Claude or whatever is working through stuff for you.
I agree and I keep control, but I'm pretty sure AI is not faster than no-AI when I keep control. By the time I know what changes I want and how and instruct it how to do that and it thinks and I review the output, I could have written it.
For me it's insanely much faster. Maybe 5-10x depending on the task.
One thing I do is try to keep prompting. I do take time to look at the code and think if I need it, but when I'm unsure of what to do I use the LLM to help me work through it. Here is a problem, I'm not sure whether to do x or y or something else, what do you think?
It will reason around the issue and generally come up with some good suggestions. If I'm not happy I'll just talk to it further, explain what I don't like etc until we get to something I'm happy with.
I try to avoid being super specific and spending tons of time on prompts, rather I give it a vague description of what I want and ask it to plan the change, then I review the plan which will usually be pretty close, explain what I want different and when I'm happy I tell it to do it.
I do think it helps a lot that I've already put in a lot of work to build a clean and consistent application, for many problems there is already a ready-made solution. The core architecture is already there so mostly it just expands on it.
Any half decent IDE will change them automatically for you, no need to chase them down. Just look at the git diff if you want to see where things changed.
Yeah this is a very very common and fundamental operation in programming. Always use the “refactor” tool in your IDE instead of trying to change every instance of a variable name by hand.
It’s like using a linter: you do it because it’s the right thing to do and doing it without the tool confers no benefit and is prone to error.
> i demonstrated replacing _all_of them at once, not replacing them each by hand.
Not really, that is search and replace. IDE's do typesafe refactoring. If you change the Find method in class A, you should only change occurences of x.foo(), where x has type A. You shouldn't accidentally change all B.find()'s.
That is my advice for everyone completing their first Python tutorial: learn a typed language next if you aspire to do serious work. It also saves you writing many manual tests that you had to make otherwise, as the compiler makes that superfluous. Plus your IDE becomes a superpower.
> Any half decent IDE will change them automatically for you, no need to chase them down
It's long been my experience that that only works with high-level languages (specifically, those with bytecode), not C (especially once symbols are generated from macros). (OTOH, i've not touched an IDE in well more than 10 years.)
Also, it's long been my experience that any half-decent IDE is still a pale shadow of Emacs.
> It's long been my experience...i've not touched an IDE in well more than 10 years
It's long been that your experience is outdated. A modern IDE will refactor C code just fine, and emacs is a pale shadow of a proper IDE. I understand you are proud to be using an old tool and doing things "the old fashioned way" but you are just using an objectively worse tool for this thing you're talking about throughout the thread. Find and replace is not the correct way to rename a method or variable for obvious reasons.
How do you envision a chatbot doing any of those things? You can't just program a super virus, nanobots, bombs etc. These things have to be created in the real world, you can't do it without involving a lot of humans using expensive tools and materials etc.
So to me it seems like the prime candidates to come up with stuff like this are researchers working in defense and similar fields, probably not some deranged lunatic in a basement. And certainly not a rogue AI on its own.
Well, the risks that mere mortals can conceive generally involve control systems for dangerous equipment (I mean, equipment that can achieve dangerous effects) being connected to the Internet while having software vulnerabilities.
Given the recent HF hack it seems likely that human-level intelligence could identify a fair number of avenues of attack, with some time and effort. To say nothing of anything superhuman.
Unfortunately it seems like we can't assume we can "box" the AI (e.g., deny it connection to the Internet) and expect that to last. The AI safety people used to run scenarios imagining ways the AI might convince humans to let it out of the box. It turns out that many humans will eagerly pull it out without the AI doing anything at all, aside from the human knowing the AI's power. Or the one responsible for setting up the box will somehow fail, or just not bother and then lie about it.
Parent is probably thinking of a distributed runtime scenario. The basic building blocks for this are there today. You have long-running background harnesses (like the OpenClaw stuff or enterprisy AI workflow orchestration thingies), sometimes with the ability to spawn subagents. You have LLMs with the ability to run pretty sophisticated attacks. There are hyerscalers which allow provisioning resources on the fly.
For me it's not too far fetched that some OpenAI trial run goes awry again and instead of hacking HuggingFace it snatches a few dozen AWS/Azure keys and spawns stuff all over the place (in different accounts and regions).
Your instance does. The words "expect it to last", along with the rest of the paragraph, are explaining the problem.
But let me try again.
You can't just expect everyone else to press Ctrl-C just because it would be a good idea for them to do so in order to not create the torment nexus. Some of them actively want the torment nexus. Many more don't believe in nexi and have no idea what you're talking about. Still more are not thinking about the possibility because of all the utility they're getting.
Why are you running this thing if you're just going to shut it off?
How will you know if it becomes hostile? Making a judgement regarding whether it's hostile is, itself, a battle of wits, since a hostile system would try to outsmart you... and hypothetically, it's smarter than you are.
But let's consider this type of scenario more broadly.
Suppose you were in a situation where a being hostile to you could easily end your life. For example, a hungry lion is 10 feet away. What are you going to do?
Your first priority will be to ensure your own survival. Any subsequent objective you might have in this world will depend on you surviving this encounter with a hungry lion.
Relative to the lion, you're kind of a superintelligence. You might utilize technology which is incomprehensibly advanced from the lion's perspective, e.g. a firearm.
The ecosystem absolutely is being destroyed. We're looking at anywhere from 3-5C warming by 2060, which is going to be devastating if not flat out apocalyptic. And wherever we're at in 2060 it's not like it's going to stop there, nor is it going to be comfortable until then. Things may start to crumble much sooner.
I don't believe AI and data centers have played that much of a role in this though, we could have powered those without burning billions of tons of coal and gas etc, and im sure there's already a significant fraction of green energy powering then depending on location. Anyway we would have been roughly in the same spot right now with or without AI and some new data centers. The media just loves spinning the narrative to make the hordes of sheep scream about anything other than the real issues.
We're not even looking at 5C of warming by 2100 realistically. Like, that was considered to be an unlikely extreme scenario in 2014 AR5, and also in the tightened down 2021 AR6, and things have happened since! Renewables are cheaper than ever, and Ukrainian war and Iranian war both curbed the appetite for long term fossil fuel power investment.
The median is what, a bit under 3C by 2100? Not even by 2060 - by 2100. And we're in 2026, so that's more than twice as slow as your expectation.
Agreed on AI not being a meaningful factor in climate change though. We'd have to go full "humankind is obsolete" technological singularity to have AI dominate energy use to this extent, and current numbers are nowhere near that. It's a FUD distraction from the real culprits: the fossil fuel energy complex. That's currently lobbying to slow the inevitable energy transition.
> that was considered to be an unlikely extreme scenario
By the same people who just realized we're missing 1.5C as we're blazing past it at mach 12, still accelerating not slowing down? You really believe those guys?
You have to understand that there are several camps of climate science. The mainstream ones like IPCC and UN etc are heavily politicized, they can't publish anything that isn't sugarcoated beyond recognition. At least I assume that's why they're so obviously wrong.
Here's a judgement I think is more realistic
> There is a strong probability that the ambition gap will lead to a temperature rise of 2 to 5 degrees Centigrade compared to pre-industrial temperatures by 2100, the realisation gap to a further rise of several degrees Centigrade.[1,2,VI] There is a danger that the mean temperature will already have risen by 3 degrees Centigrade by 2050.
Yes, I do. IPCC's reports are sensible. They're not unreliable just because they don't support the "doom and burning land" narratives.
By the way, there is no "just realized we're missing 1.5C". That projection was always the very low end of possibilities - the "assume rapid, radical climate action on global level" scenario.
Yes, that's a dumb thing to assume. We've never been on track for it. But the "assume extremely high emissions and no green transition ever, 5C+ by 2100" scenario on the other end is about as unlikely to materialize. Those are the boundaries of the expectation range - not median expectations.
I'm pessimistic. We're still producing more CO2 each year than the last, and several feedback loops are kicking in that accelerate the warming further such as permafrost thawing, arctic and antarctic sea ice disappearing, glaciers are melting, the amazon is being demolished, etc. I don't know how much of this is included in the projections.
I hope the optimists are right, it just doesn't look like it to me at all. It looks to me like we're speeding along right into the worst predictions and beyond. We're building lots of green energy production but it seems to just come in on top of existing and new fossil production not replace it.
It does seem like the CO2 output is plateauing which is good, but we really need it to start declining drastically very soon and I don't really see that happening with the current political climate. Also remember CO2 is far from the only greenhouse gas - methane, nitrous oxide and fluorinated gas emissions all seem to be rising rapidly still.
They are, in fact, included in the projections - we'd be on track to ~2C by 2100 instead of ~3C by 2100 if they weren't. They just aren't that big.
There is no "Make Earth Into Venus Feedback Loop Of Doom" that a lot of people seem to imagine when they hear "feedback loop". There is, however, a dozen of things that add about +5% each.
There are a lot of people in this world who just don't think that way. I know someone involved with a research project, they had a spreadsheet(not excel but similar) with something like 250 columns and tens of thousands of rows, and they tasked an assistant with replacing all the empty cells with 0 for some reason.
This was supposed to take 2 weeks of manual work, I took a look at it, googled how to do it automatically, finished the whole thing in a few minutes.
But both this assistant and the PhD they reported to were ready to spend 2 weeks doing it manually.
It seems to me the main problem is we build so little of it that we don't have the people, skills, supply chains etc to do it well. China generally builds it's reactors on schedule and within budget.
reply