While Linux isn't a panacea, the OS does matter as Linux provides tools for security scanners like Crowdstrike to operate entirely in userspace, with just a sandboxed eBPF program performing the filtering and blocking within the kernel. And yes, CrowdStrike supports this mode of operation, which I'll be advocating we switch over to on Monday. So yeah, for this specific issue, Linux provides a specific feature that would have prevented this issue.
extern "C" {
fn abs(input: i32) -> i32;
}
fn main() {
unsafe {
println!("Absolute value of -3 according to C: {}", abs(-3));
}
}
Now, if you have a complex library and don't want to write all of the declarations by hand, you can use a tool like bindgen to automatically generate those extern declarations from a C header file: https://github.com/rust-lang/rust-bindgen
There's an argument to be made that something like bindgen could be included in Rust, not requiring a third party dependency and setting up build.rs to invoke it, but that's not really the issue at hand in this article.
The issue is not the low-level bindings, but higher level wrappers that are more idiomatic in Rust. There's no way you're going to be able to have a general tool that can automatically do that from arbitrary C code.
Passing integers around is easy, sharing structs or strings and context pointers for use in callbacks crossing the language barrier etc is typically much harder.
(Nitpick: I don’t think it technically is correct to call this “The C representation”, as strict layout in C depends on the C compiler/ABI. I wouldn’t trust this to be good enough for serializing data between 32-bit and 64-bit systems, for example. For calling code on the same system, it’s good enough, though)
It's on par with C++, too. In C++ you need an `extern "C"`, because C++ linkage isn't guaranteed to be the same as C linkage. You can get away with wrapping that around it in a preprocessor conditional, but that's not all that much easier than Rust's bindgen.
A lot of C to C++ interop is actually done wrong without knowing it. Throwing a C++ static function as a callback into a C function usually works, but it's not technically correct because the linkage isn't guaranteed to be the same without an extern "C". In practice, it usually is the same, but this is implementation-defined, and C++ could use a different calling convention from C (e.g. cdecl vs fastcall vs stdcall. The Borland C++ compiler uses fastcall by default for C++ functions, which will make them illegal callbacks for C functions).
The major difference between Objective-C and C++'s C interop and other languages is the lack of the preprocessor. Macros will just work because they use the same preprocessor. That's really not easy to paper over in other languages that can't speak the C preprocessor.
> In C++ you need an `extern "C"`, because C++ linkage isn't guaranteed to be the same as C linkage.
`extern "C"` has nothing to do with linkage, all it does is disable namemangling, so you get the same symbol name as with a C compiler.
> Throwing a C++ static function as a callback into a C function usually works, but it's not technically correct because the linkage isn't guaranteed to be the same without an extern "C".
Again, linkage is not relevant here. Your C++ callbacks don't have to be declared as extern "C" either, because the symbol name doesn't matter. As you noted correctly, the calling conventions must match, but in practice this only matters on x86 Windows. (One notable example is passing callbacks to Win32 API functions, which use `stdcall` by default.) Fortunately, x86_64 and ARM did away with this madness and only have a single calling convention (per platform).
> `extern "C"` has nothing to do with linkage, all it does is disable namemangling, so you get the same symbol name as with a C compiler.
extern "C" also ensures that the C calling convention is used, which is relevant for callbacks. It's not just name mangling. This is the reason that extern "C" static functions exist. You can actually overload a C++ function by extern "C" vs extern "C++", and it will dispatch it appropriately based on whether the passed in function is declared with C or C++ linkage.
> In C++, when used with a string, extern specifies that the linkage conventions of another language are being used for the declarator(s). C functions and data can be accessed only if they're previously declared as having C linkage. However, they must be defined in a separately compiled translation unit.
> extern "C" also ensures that the C calling convention is used, which is relevant for callbacks. It's not just name mangling.
I stand corrected. I didn't know that `extern "C"` enforces the C calling convention.
However, on modern platforms this doesn't really matter because, as I said, there is only a single calling convention (per platform). And I'm pretty sure that future platforms will keep it that way. Fortunately, if you try to pass a C++ callback of the wrong calling convention, you get a compiler error.
> If you're passing a callback to a C function from C++, it's wrong unless the callback is declared extern "C".
That's certainly not true because `extern "C"` is not the only way to specify the calling convention. In fact, you might need a different calling convention! As I mentioned, on x86 the Windows API uses stdcall for all API functions and callbacks, so `extern "C"` would be wrong. If you look at the Microsoft examples, you will see that they declare the callbacks as WINAPI (without `extern "C"`): https://learn.microsoft.com/en-us/windows/win32/procthread/c...
So I stand by my point that in practice you don't need `extern "C"` for passing C++ callbacks to C functions. You can pass a lambda function just fine, and when it doesn't work the compiler will tell you.
* cdecl is a platform specific calling convention. There is no standard C ABI. cdecl is a wintel thing, not the standard C calling convention. On Linux, this is the System V ABI for instance. On Windows ARM, it's also not cdecl.
* Specifying calling convention at all is a compiler specific extension. There is no standard way of specifying a C calling convention without `extern`.
So specifying cdecl gets you the right calling convention on some platforms and ties your code to some specific compilers. The only portable way to specify C linkage in a C++ program is extern "C". You will always get the right ABI for your platform and it will work on every compiler.
> So I stand by my point that in practice you don't need `extern "C"` for passing C++ callbacks to C functions. You can pass a lambda function just fine, and when it doesn't work the compiler will tell you.
The compiler will very often not tell you. It will complain if the lambda can't be coerced to a function pointer (because it's a closure) or if the argument or return types are wrong. An incorrect ABI will usually be accepted and will just do the wrong thing or crash at runtime. The C++ standard says that language linkage is part of a function's type, but very few compilers actually support this.
Your position works sometimes for some compilers and some platforms. I assert that it's better to use standard C++ features and just work everywhere.
> * Specifying calling convention at all is a compiler specific extension.
Yes, because the calling conventions themselves are platform/compiler specific.
> There is no standard way of specifying a C calling convention without `extern`.
Well, on modern platforms you don't need to because there is only a single calling convention that is shared between C and C++. For legacy platforms with multiple calling conventions, you need compiler specific extensions by definition.
> The only portable way to specify C linkage in a C++ program is extern "C". You will always get the right ABI for your platform and it will work on every compiler.
Again, on platforms with several calling conventions `extern "C"` absolutely won't give you the appropriate calling convention all the time. See again my Win32 API example.
> The compiler will very often not tell you
> An incorrect ABI will usually be accepted and will just do the wrong thing or crash at runtime.
That's absolutely not my experience! Functions with different calling conventions have different types, so a C++ compiler must reject such code. See https://godbolt.org/z/6EnncE5v5. (Note that for the lambda case MSVC is smart enough to automatically add __stdcall whereas MinGW refuses to compile. The free function is rejected by both compilers.)
Can you show me an actual example where a C++ compiler silently accepts a function with the wrong calling convention?
> Your position works sometimes for some compilers and some platforms.
It has always worked for me so far and I write software for many different platforms.
Ah, yeah, you're right. I was spacing the fact that C as well as C++ can have multiple calling convention. I blame early morning brain.
As far as the wrong calling convention goes, I'm basing it on the fact that an extern "C++" function can be passed as a callback where an extern "C" is demanded. Even if they're the same calling convention, that should fail, but it doesn't. Looks like it doesn't fail at runtime, which is a small comfort, but given the different permissiveness of different compilers, it still makes me very nervous to pass a C++ function as a C callback and just hope that it works, given that it isn't guaranteed in the standard.
> Even if they're the same calling convention, that should fail, but it doesn't.
It's an interesting question. According to the standard, functions with different language linkage are indeed considered different types. As a consequence, <cstdlib> should declare two overloads for qsort() that only differ in the type of the sort function. However, modern compilers don't seem to care:
"The only modern compiler that differentiates function types with "C" and "C++" language linkages is Oracle Studio, others do not permit overloads that are only different in language linkage, including the overload sets required by the C++ standard"
In practice, extern "C" does two things (as you correctly pointed out):
1. disable name mangling - This only affects the symbol name and is not relevant for callback functions
2. enforce the (default) C calling convention - On all (modern) platforms I know, C and C++ have the same default calling convention for free functions.
This means that from the view of a C++ compiler, pointers to `foo()` and `extern "C" foo()` have the exact same type.
Anyway, no need to be nervous. Even if the compiler treated these as different types, you would get a compiler error because C++ disallows implicit casts between different pointer types.
As long as I can't silently get wrong behavior or runtime crashes, I'm happy enough. Is it guaranteed that an incorrect calling convention will always cause a compiler error? I wasn't aware the calling convention was considered part of the pointer type.
Anyway, thanks for engaging with me so earnestly. I guess I had some assumptions about calling conventions that needed to be straightened out, which is important, as I'm doing work in this territory right now.
> Is it guaranteed that an incorrect calling convention will always cause a compiler error?
A standard-conforming C++ compiler must not allow implicit pointer casts, so yes!
> I wasn't aware the calling convention was considered part of the pointer type.
Some well-designed C APIs define a macro for the calling convention that they add to all API functions and function pointer declarations. The user can then use the same macro when supplying their callbacks, which guarantees that the calling conventions match. (On modern platforms, the macro would be typically empty.)
Now imagine a hundred or two functions, structures and callbacks, some of them exposed only as CPP macros over internal implementation. PJSIP low level API is one example.
They quickly become unwieldy on non-trivial APIs, with hundreds of definitions across dozens of files and with macros to boot. Naturally people would still get the job done but it's beyond simple.
I have used it successfully against header files for Win32 COM interfaces generated from IDL which include major parts of the infamous "windows.h". Almost every type is a macro.
Not types, functions. Where the macro is essentially a forward declaration but the implementation is deep inside the code and is not exposed via headers.
It works when using multiple languages that share the same writing system (the Latin alphabet). It means that you have a single keyboard, but the words that swipe or auto complete are from more than one language; generally the predictive nature means that when you switch languages it's pretty good at predicting future words are from the same language.
It also means things like you get all the diacritics from all of the languages when you long press.
I was studying French, while also working with several Polish people, so I set my keyboard to simultaneously English, French, and Polish, and then I was able to do French lessons without switching, and also able to write my Polish coworkers names easily.
If the LLM hallucinates a Python package, someone else might notice that and sneak in a malicious version of that hallucinated package.
Or if it hallucinates a method name, it might be in a code path that goes untested. How often are people using these tools to also write comprehensive test suites?
Like I said, you have to put the work in if you're going to use these tools effectively. I write a LOT of tests both with and without the help of LLMs. I try hard never to leave any code path from an LLM (or from code I write myself) untested - always manually and usually through automated tests too.
If you don't do that, the chances LLM-generated code will introduce weird bugs are high. But the chances you yourself (or your coworkers) will introduce weird bugs are high as well - QA, code reviews and testing are important no matter what helped write the code.
Pumped hydro is great, but only in certain areas where you already have the elevation gain available.
Compressed air storage is another one that's pretty good, but it's only particularly good if you can store it in underground caverns or unused mines, so it's also geography dependent.
For longer term storage, producing hydrogen can be a good one.
And batteries are actually fast becoming competitive with some of these options from the other end, generally better for shorter term storage but getting better at longer term. Even shorter term, flywheels can be a good option.
There's room for several different types of grid-scale energy storage, based on how efficient they are at different energy storage periods and numbers of charge-discharge cycles, and also in some cases on local conditions, like the availability of terrain and water sources for pumped hydro.
There's a good paper here which shows what the most efficient energy storage systems are for various combinations of length of storage (hours per discharge) against number of discharges per year, and for each one shows the current cost, and a predicted cost based on trends in technological advancements: https://www.sciencedirect.com/science/article/pii/S254243511...
There's a lot of the chart that is dominated by pumped hydro currently, but plenty of other storage technologies that are more cost effective on different timescales and numbers of discharges. But it looks like it's predicted for prices of battery storage and hydrogen storage to fall relative to the others, causing a different predicted landscape in 20 years.
And some of these, like pumped hydro, are dependent on geographic features, or access to certain resources, so even when one dominates overall, there can be others that dominate in particular geographical regions.
Generally they use pulse density modulation, rather than pulse width modulation, which increases the frequency of the noise and makes it easier to filter out. Sigma delta modulation, which the comment you replied to mentioned, is a way of doing pulse density modulation.
Imagine if you did dithering to produce grayscale images with a black and white screen by just using different sizes of rectangles; you'd have to have a very high resolution screen before you wouldn't be able to see the individual rectangles. That's what pulse width modulation is like. Whereas pulse density modulation, using a sigma-delta modulator, is more like a proper dithering algorithm, where you spread the pixels out evenly across space, you don't just use different size rectangles to represent different shades of gray.
Funny thing is, Anthony Gatto was brought up in a circus family and went on to become the world's best technical juggler (based on endurance at high numbers, incredibly difficult technical tricks, and overall consistency rather than just a few one-off record attempts), but eventually got bored of juggling and decided to quit and start a business doing concrete countertop installation.
I did a bunch of juggling in college, and several of my friends went on to do circus arts professionally. Generally they went into more acrobatics oriented arts than juggling; seems like juggling itself is not quite as interesting to audiences as it is to the jugglers.
Oh, and to tour other point, I noticed a gap between juggling and juggling performance. There's an article elsewhere in this post on Gatto, that sums up quite well how audience perception of difficulty is quite limited. This impacts a juggling performance severely, but has no impact on someone who likes to juggle. I suppose the same could be said of a lot of things though, without a technical eye, a lot of Olympic competitions are impressive, but I can't tell good from better.
I remember learning about Gattos shift of career. He was someone me and my friends would watch with admiration. When we learned he'd stopped, we were disappointed, but didn't question it.
I don't question any career change (done it 4 times myself) but I do find it interesting when someone moves from working with their passion (and you have to be passionate to get world-class at anything) to what is almost certainly just a paycheck gig.
I mean, he could be passionate about concrete benchtops, but what are the chances?
Your passion can also be soul destroying, or body destroying. Friends who have left the industry often site career-ending injuries, or that they were on track for a permanent disability.
Ugh, no way. There's way more to three ball juggling than just Mills Mess (no apostrophe, his name was Steve Mills and it's not possessive but just a title).
Mills Mess is the start of learning that there's more to three ball juggling than just a couple of over the top throws, not the end of it.
Agreed. After mastering the basic cascade, Mills Mess is a great beginner pattern to learn next, but there are way more challenging ones. Burke's Barage is another more challenging pattern.
And an AP1000 reactor costs about $6.8 billion to build, and substantially higher operating costs. 68% of the power for 14% of the price seems like a pretty good deal to me, there's a reason people are investing more in solar than nuclear, it's just more cost effective.
This doesnt take into account capacity factors. A "800MW" solar plant would be expected to actually product 10-25% of that after day/night and seasons are taken into account. Nuclear plants are more of a 90+% capacity factor.
So even if you discount the capacity by a 25% capacity factor, and use the lower cost per reactor that I originally quoted, this is still cheaper than nuclear. And that's just the up-front investment. Operating costs are much cheaper for solar as well, the majority of the cost is in the initial build.
Given that transmission isn't free, there are areas of the country where solar has a lower capacity factor than this, and solar and wind take more land, there are still cases where nuclear may be a better investment. I'm just pointing out that there are plenty of simple, economic reasons why solar and wind are growing at a much faster rate than nuclear; it's cheaper overall, it requires less up-front capital, etc. Nuclear is likely to fill niches for a long time, but investment in nuclear is not going to be the major way to decarbonize.
Building nuclear in a desert feel a bit like building hydropower dams in a desert. It does not really make sense and whatever the capacity factor is, being in a desert should increase it.
The only real drawback to building solar power in a desert is sand storms. That means the capacity factor is less relevant but life span and repair costs is a different matter. It is a bit similar to ocean wind farms. The capacity naturally goes up, but the salt water and transportation (as well as increased risks to engineers) makes life span and repair a bit more of an issue (it should be noted that most ocean based wind farms tend to use shallows and nature reserves near large cities).
But again, this project is built in a desert. The very definition of a place with consistent amount of sun. I hope the project works out.
There is an ecological cost to miles and miles of solar panels. Desert ecosystems are extremely fragile, and these kinds of projects can be very damaging. It’s not just wasteland. (Said as a desert Southwest denizen and lover who gets the impression that many people think, “oh, there’s no trees? It’s unimportant land.”)
I want the Utes to have success in this, but I don’t want the general attitude to be “trash the desert because there is sun there”.
The ecosystem will change, no doubt about that. Just like it changes when we start agriculture somewhere, or pastoralism. Even if we consider that the new ecosystem of desert with a lot of shade might affect neighboring pristine desert within quite a radius, there will still be a lot left in the foreseeable future. Very much unlike agriculture and pastoralism, which have been pushed into almost every corner even remotely viable for millennia.
It might be worthwhile to exclude certain areas of particularly rare variations of the ecosystem to be built in. But it's easy to end up with too much red tape that will be abused for NIMBY and by people who hide a fossil yolo attitude behind a facade of conservationism.
Perhaps there could be some mechanism for operating some veto quota, "pick the project you want most desperately to be stopped"? That scheme would probably end getting gamed in the ugliest ways, with sacrificial decoy projects getting proposed, not vetoed and then getting built to keep up appearances. Better not, heh.
There is the concept of "agrivoltaics" where solar and agriculture can be colocated. Apparently, certain fruits and veggies grow better with a bit of shade provided by solar panels.
The LCOE cost advantage of alternative energy vs ... everything ... at this point is well known and calculated in Lazard's yearly LCOE study.
Nuke advocates do themselves no favors playing shell games and weasel words with the economics. Nuclear is expensive. The nuclear industry needs to figure out how to make it a lot cheaper. And no, it's not just the NIMBY regulation.
The legacy nuke industry has a ton of deeply embedded lobbying and relationships with the regulatory agencies and congress, including ancillary groups that do fuel rod reprocessing and waste transport, cushy high-cost satellite industries.
Nuclear is stuck in a rut. Economically viable nuclear needs a clean-slate redesign and all the old players need to be thrown out. Computer designs, modern software and sensors, materials, etc. Research LFTR to the wazoo.
One of the big pushes IMO should be the US Navy, which should start using nuclear power for all its fleet ships not just subs/carriers.
Solar is cheaper when you have a flexible and well interconnected grid capable of smoothing out, say, a cloud passing over Ute nation land and abruptly pulling 1GW out of the grid. That kind of grid costs money and we have no idea how much and how achievable it is. The alternative, grid scale storage for the full rated power, is still insanely expensive and makes renewables completely uncompetitive.
Yes, nuclear is getting buried on price, but you make out the total cost of solar much lower and much more certain than it is in reality. Nobody really knows how much will renewables end up costing when they start to make up the majority of production.
Australian research on this suggests renewables will still be cheapest as the grid moves to fully carbon free, includin the cost to integrate with the grid:
> Even with this extra VRE cost in 2030, the answer to whether renewables are the cheapest form of energy is still yes. And it remains so when VRE is at 90 percent of the energy system
Considering that full economies of scale and technology has not yet been matured in solar certainly, and possibly wind, and certainly in battery storage...
Look, you're treating the current LCOE numbers and making the (mistaken or disingenuous) implication that solar/wind won't fall EVEN FURTHER, but they almost certainly will.
With solar, there is perovskites and many other avenues of improvement in the core technology. Both wind and solar will still drop in price from increased economies of scale. And battery storage is going to plummet with sodium ion in the near term, and hopefuly sodium-sulfur techs in the future in addition to whatever grid-specific use cases are developed.
So it's true! Nobody know how much renewables will cost... or HOW LITTLE they will cost... in the long run.
Existing already-built nuclear is woefully noncompetitive, but I'll take it for grid levelling over gas turbine and (ugh) coal, so keep the lights on.
But NEW nuclear? What price are you targeting? I would guess in the timespan of a new nuke plant construction (10 years), solar will drop by 50%-60% in costs (inflation adjusted), and I think wind still has 33% drops coming. I mean, how does a sensible person approve a nuclear project with this degree of uncertainty/evolution/revolution in power costs?
And if you want to talk uncertainty in cost of electricity, the unreliable final construction and operation costs of nuclear are much more unreliable from that standpoint.
Again, this is not about the production price of renewables, which is low and falling quite predictably, but the unknown long term costs of integrating substantial intermittent production into the grid.
Believable models of achieving that goal call for setting up capacity markets where traditional suppliers are paid to not emit, and stand by to intervene when required by weather conditions, achieving close to net zero year round emissions (¹. Nobody really knows how this will end up costing because no such grid exists today.
Grid scale battery storage is still very far from competing with traditional baseload production, even when supplied with free renewables. Sodium has been the next big thing for the last decade, but its only deployments are in the experimental, MWh range. It's still far from a mature, proven technology, let alone one that can disrupt lithium in the gridscale storage space.
Perhaps you are handwaving substantial technical and economic details away and making too bold claims insufficiently supported by data. Not unlike the nuclear fanboys who are seeing thorium fast breeders just around every corner.
(¹ Btw, this is just another nail in the nuclear coffin - coal too - because they can't play nice with a fast moving grid.
> The nuclear industry needs to figure out how to make it a lot cheaper. And no, it's not just the NIMBY regulation.
It is very expensive, there is no way around the extreme engineering costs of nuclear reactors. Even before trying to make then safe from threats extant and possible.
That is before the unknown costs of handling long term waste using technology that has not been proven, or invented, yet
Comparing just on W/$ feels like it's missing a bunch of additional problems with the power generation, such as nuclear risk or needing more than solar to cover a full year's electrical demand.
A lot of the nuclear risk is already included in that cost; we have fairly robust nuclear regulation and safety engineering these days. I have pretty high confidence in the safety of modern nuclear reactors, because there has been the engineering needed to ensure it, and there's fairly strong regulatory oversight. Of course, that all gets factored into the price tag, which is part of why the price tag for nuclear is so high.
I'm just saying that I see a lot of discussion of more nuclear investment as the solution to decarbonization, but it's hard to make the economics work out; nuclear has gotten more expensive over time, while renewables have been dropping in price dramatically.
I'm sure there is some room for nuclear in the market, but it's hard to see it providing more than a fraction of what renewables do, just due to the massive cost difference.
Plz bro, just 10 more years and the next design will finally solve all the probs.
I don’t like solutions that don’t ever make real progress. Solar is getting cheaper in real-time, as are batteries. Nuclear is getting comparatively more expensive every year.
True. This happens to be in a region of the country that gets a 25-30% capacity factor on solar; in the northeast or northwest, you'd see much worse results.
The basic point is that nuclear is just really, really expensive, and it has been getting more expensive over time, while solar and wind have been getting cheaper.
> When comparing solar to nuclear we also need to include storage and dimensioning to get an equivalent 24/7 output.
No, that is a red herring. That exact comparison would be only for greenfield projects disconnected from everything else. When connecting to an existing network, the existing (and future) generation on it is also important. For instance, if the network already has a high enough amount of gas generation, 10MW of solar or 10MW of nuclear would reduce the use of fossil fuel by the same amount; the same applies to reducing the use of water stored in hydroelectric dams.
It does require a lot more land; but we have a lot of land available.
Nuclear will continue to be viable in denser areas, with lower solar resources, and when you want to get a lot of production closer to large population.
There's a reason there are so many nuclear plants in the Northeast Corridor (Boston to Washington area), and so many fewer in the southwest, and I imagine that this trend will continue.
When comparing solar to nuclear we also need to include storage and dimensioning to get an equivalent guaranteed 24/7 output.
This might still make solar cheaper but difference will be smaller than headline numbers (and you might retort that for nuclear we then need to include dismantling costs as well).
In that case you'd also need to model how the cost changes if you combine solar with wind and other renewables. Wind and solar are to some extend complementary (there is statistically more wind when there is little sun and vice versa). You'd also need to account for distributing solar and wind across large geographic areas (i.e. the U.S. is so wide that there are a few hours difference between the sun setting on the east coast and on the west coast, somewhere wind is always blowing, etc.)
There are probably studies that have done an analysis of this kind for the entire U.S. and calculated various scenarios. I know that these have been done for Germany and other European countries. A 100% renewable system usually comes out cheaper than including nuclear in the mix to any large extend (though Germany has no remaining old reactors which could get their lifetime enhanced relatively cheaply).
Thats still building 2x the power generation (and you've got storage in there too). Those wind turbines aren't free. They have different maintenance costs too.
You don't get to say "oh well it'll be 1GW of solar if we also build 1GW of wind" because that's not the project.
This is all an excuse to talk around Solar's god awful capacity factors which take the shine off those $/MW headlines.
Yeah, but even renewables + storage is likely to be cheaper than nuclear. Right now pumped hydro is one of the best for grid-scale storage, but with the the reduction in cost of batteries, it may be that grid-scale battery storage becomes viable not too far in the future.
And remember, nuclear generally needs some form of storage or supplementation with on-demand generation (generally via fossil fuels). Nuclear reactors are very slow to increase or decrease their output; they're best providing a constant base power output, but to account for periodic changes in demand across the day, you need either grid-scale storage or to supplement them with things like gas turbines that can quickly spin up and down. Many of our existing grid-scale energy storage systems are there to support nuclear. For example: https://www.wbur.org/news/2016/12/02/northfield-mountain-hyd...
But if you're already going to be building the grid-scale storage, supplying it with renewable energy can be a lot cheaper than supplying it with nuclear.
I'm not saying that nuclear will have no place in the energy grid as we decarbonize. But the economics are hard to justify as renewables and storage become cheaper.
Reactors can load follow reasonably quickly, but the economics look terrible when the utilization drops, so you don’t want to load follow if you can about it. That’s also why nuclear and renewables don’t mix well.
IIRC the French are more aggressive about using nuclear for load follow, which is also why a lot of their plants went down for maintenance, because it’s harsher on them as well.
Wind, hydro, and storage. Pumped hydro has already existed for a long time for helping nuclear with load following https://www.wbur.org/news/2016/12/02/northfield-mountain-hyd... and as battery prices fall and production ramps up, even battery based storage is likely to become feasible for grid-scale storage.
Not every day is a windy day. Battery storage is ridiculously bad for the environment and wasteful. As mentioned, not a lot of hydro storage in Kansas.
Plus, when the hydro storage fails and floods a town, that’s still pretty bad.
Sure. No solution is one size fits all. This particular solar installation happens to be in Colorado, very close to a lot of area where pumped hydro would be extremely cost effective.
Somewhere like Kansas, wind power and battery based storage may be more effective.
Here's a map of pumped storage hydro potential; note how dense the potential is throughout most of the Western US. https://maps.nrel.gov/psh
I know "Kansas is flat" is a popular trope, but it's not even that accurate.
Depending on how you measure, lots of states are flatter than Kansas. Florida is the flattest state by nearly all measures. Illinois is crazy flat as well.
That’s pretty cool! My experience is playing with dc power and smaller panels off the grid (campingish) and I am foiled by clouds! I can totally see at a large scale clouds may not be quite as impactful as first thought.
If you need 100% of the power output all the time then that is probably why? Also the grade might be lower for camping but not sure on that. Also this is subtropical usage I am referring to so your watts may vary ;-)
