If it has some of the benefits of valgrind (or similar) runtime checking, but quick enough to use in production, and can be mixed with (trusted) unsafe C/C++ for the performance critical portions (hot loops). Undermines the value of Rust, at least a bit.

My retired mother has a nice new Samsung TV that is a bit enthusiastic about being connected to the wifi.
Luckily for her I know the wifi password and the TV does not, and shall not.
But it's a terrible experience that the TV "stops working" and "needs" to connect for Samsung reason.
It's not your TV Samsung, it's Mum's TV, please stop.

Tax plastic to reflect the true cost of dealing with it.

The main problem with plastic is that it's falling to taxpayers, rather than consumers of plastic to shoulder the true cost of recycling or disposal.
The cost of scooping it up from the river. Retrieving it from far out at sea. Processing it into something reusable. Pay the true cost.

C# was initially a windows-centric thing, even though the language is pretty nice and seemed nicer than Java, last time I looked.
I'd still be reluctant to use it for anything serious, from a cross-platform perspective.
But would even more reluctant to touch Java again, admittedly.
Generally for me C++ if performance matters, Python if it doesn't.

The cool kids with their throw-away web stacks were berating Python 2 ten years ago. They could not believe there was little motivation to migrate, some Python is so intricate and esoteric that even the authors would have been daunted, but at least knew how to test it. It was a failure of the community to abandon support for it, a regrettable decision, so after all this time I really can't resist saying it: I told you so.

Same situation here. Roblox is one of the key reasons our kids were migrated from Ubuntu to Windows.
Not sure if they'll return or not...

I think there are are plenty of devs doing ongoing maintenance of old codebases that have a lot of historical and outdated assumptions. Generally the younger devs to gravitate to shiny new stacks and might not have the experience or willingness to invest in the old-school stuff. And there tends to be a lot of rickety testing infrastructure and practices that go with that. I really don't think you need to re-train if you've seen your share of C and C++ code bases from ye old days. It's still out there in producing getting a job done, and somebody needs to know their way around it to update dependencies, fix bugs or do modest changes to satisfy a new requirement.

In the C++ space I'm current training for C++17 and C++20, but I'm well aware that the vast majority of code out there isn't even C++11. There would be some technical benefit bringing some of that forward to C++11 or C++17, but it's generally not glamour work.

In Australia we now have a situation with second-tier "news" organisations putting out trivial click-bait stories in an effort to attract more attention and revenue via facebook. I'm sure there will be an uptick in (other irrelevant and unwated) sponsored content to foot that bill. But the stated objective of fairly compensating genuine journalism is looking like a failure, already.

Ripe for some tweets - Python 2.7 and Windows 7 still work just fine on January 15th 2020, despite predictions of apocalypse.

Python2 will be around for a good long while. As much as the cool kids want to push Python3 there is a universe of working and business essential Python 2 running day-in day-out that no sane person wants to touch. I'm quite certain that Python2 will be better supported once it's free of the Python3 people.

I second this. What IceWM needs most is a project manager and an evangelist.

Do a refresh of the website, reach out to all the known historical developers, start a blog about IceWM - little tutorials about what is good about IceWM, triage the bugs the best you can without diving into the code. If the debian and/or Fedora packages are missing, create some or work with the packaging folks to make them better. Convert the revision history to git and put it up on github, if possible.

I think there is a decent backlash going on against Unity and Gnome 3. I'm currently using Cinnamon, but I'm fairly willing to give something old-school a try. I was happy with KDE3, then went to Gnome2, and really feeling that Unity is both unstable and inappropriate for work. (I do want to search for things locally without that going to Amazon for advertising purposes) Cinnamon is workable for me, but I'm not rusted onto it.

Get the pitch right - it's probably not for Grandma, but it might appeal to seasoned developers who don't like instability and don't like any "surprises". One thing that's valuable to me is having something agreeable without much customization. I tend to have various machines with various distros installed, something solid and consistent across all those is a valuable feature to me.

- Nigel

I have have a Linux desktop, which my kids sometimes use.
KPotatoGuy is one I can suggest. My 6 year old is starting
with minecraft, but it's a bit scary and complex still. (It's fun
as long as I am around to coach and make suggestions)

But what my kids (3 and 6) are really into are games on the Android and iOS tablets and phones -
angry birds especially. Consider that they can touch without knowing the alphabet, knowing
what "escape" or "space" or "return" are about. And the left button, right button, and scroll
wheel, etc. These devices are ideal for kids, and software is generally affordable, and the
stuff "just works" reliably - minimal admin, fiddling or administration.

So I really recommend they have access to an iPhone, iPod, Nexus7 (or whatever) and some
different styles of easy games without the crummy adds that land them on spammy "buy now"
websites.

And the best thing about it is that having YOUR computer to yourself is important too!

- Nigel

Aside from all the interesting suggestions made here already - one challenging area to engage with is parallel processing. Google for CUDA, OpenCL and pthreads for an idea of where things are heading for processing intensive applications, that might once have been the domain of Fortran. Indeed, there is probably a whole lot of Fortran code ready and waiting to be adapted to CUDA, and Fortran expertise a bit hard to come by.