This is such a good attitude! I cut all meat out of my diet a long time ago, and when I mention it, people often say something like "I'd love to but I couldn't commit to never having meat again".

You don't have to! It's amazing if you do, but you're still gonna make a sizable impact on the cause you care about if you reduce your intake.

It's odd that people don't have this with other issues, the idea of "reducing purchases of disposable plastic" or "buying fairtrade more" make total sense to people, but food is still often cashed out in these "all or nothing" terms.

Yeah, but remember that data is live and it's currently night time in the UK! (I think average solar is pretty liw in the UK though- something like 5%)

We need to do a lot more still, but the fact that the UKs energy generation is 20% of the CO2 emmisions per MW that it was just 10 years ago, despite a very conservative government, is pretty awesome.

(20% figure from this page which has sone cool data and visualisations on it:https://grid.iamkate.com/ data is all sourced from the UK's National Energy Operator)

I think short answer is yes, but longer answer is also that Pixi is a drop in replacement for Conda, which is a lot less used than Pip (which uv is a replacement for).

I feel like in a lot of ways, most languages are great candidates for this, for lots of different reasons!

• Rust: Great choice because it produces a small, very well optimised binary. If you just care about the output binary being small and non-memory intensive, then this is probably a good call.

Buuuuut, Rust's compilation can be pretty resource intensive, so if you're actually developing on limited hardware:

• C (or curveball option, Hare): produces a small, well optimised binary, with faster compilation. But less framework type things to help you on your way to apis/servers/etc.

Then there's the fact that it's a home server, so always on, meaning you actually have generous resources in some ways, because any available CPU is kinda just there to use so:

• Python: has a runtime and can be pretty heavy CPU wise, but lots of frameworks, and in all honesty, would wind up being a lot faster to put stuff together in than Rust or C. Probably a great default option until you hit resource issues.

And then why not go whole hog into the world of experimental languages:

• Roc: Doesn't have versions yet, so super new, but should produce a pretty small binary and give you higher level ergonomics than something like Rust or C, especially if you're into FP.

And then we're forgetting about:

• Haskell: Haskell is the only true programming language, and any time there's a selection of programming languages, picking the one that isn't Haskell is the wrong choice. Just ask anyone who programs in Haskell.

But that doesn't factor in:

• Javascript: Sooner or later, everything is just javascript anyway, why even try to resit?

Plus:

• Assembly: Can you even trust that it's well optimised unless you're writing the assembly yourself?

Edit: My actual serious answer is that Rust + Rocket would be great fun if you're interested in learning something new, and you'd get very optimised code. If you just want it to use less memory that java and don't want to spend too much time learning new things then python is probably fine and very quick to learn. Go is a nice halfway point.

Thanks for sharing! I think there's a perception that carbon capture is mostly trees, but it's so interesting how complex everything actually is.

I only found out about the Ocean Carbon Pump a year ago, which is a pretty big deal for carbon capture: https://en.m.wikipedia.org/wiki/Biological_pump

Well yes, but how is that any different from putting batteries in your wind farm?

This is a cool diagram, but I think it makes it look like you can't combine stuff. Obviously solar and wind in a lot of cases just plugged straight into batteries for storage.

On the flippy floppy, hydropower can do both, but in completely different ways. If you build a dam, you can't generate electricity, and if you build a turbine, you can't store it.

I don't know what my point overall is. I guess just that energy is complicated, and there probably isn't a "one size fits all" fix.

I'm a data engineer, use parquet all the time and absolutely love love love it as a format!

arrow (a data format) + parquet, is particularly powerful, and lets you:

• Only read the columns you need (with a csv your computer has to parse all the data even if afterwards you discard all but one column)

• Use metadata to only read relevant files. This is particularly cool abd probably needs some unpacking. Say you're reading 10 files, but only want data where "column-a" is greater than 5. Parquet can look at file headers at run time, and figure out if a file doesn't have any column-a values over five. And therefore, never have to read it!.

• Have data in an unambigious format that can be read by multiple programming languages. Since CSV is text, anything reading it will look at a value like "2022-04-05" and say "oh, this text looks like dates, let's see what happens if I read it as dates". Parquet contains actual data type information, so it will always be read consistently.

If you're handling a lot of data, this kind of stuff can wind up making a huge difference.

Oh nice! I didn't know about it- thanks for the link

Well not for the people taking them, but you can make heaps of cash doling then out! (sarcasm)

I'm a data engineer, and have seen an ungodly ammount of 200-but-actually-no-stuff-is-broken errors and it's the bane of my life!

We have generic code to handle pulling in api data, and transforming it. It's obviously check the status code, but any time an API implements this we have to choose between:

• having code fail wierdly further down the line because can't parse the status
• adding in some kind of insane if not response.ok or "actually no there's an error really" in response.content logic

Every time you ignore protocols and invent your own, you are making everyone sad.

Will take recommendations of support groups I can join for victims of terrible apis.