chikere232

It's certainly a skill to launch quickly at that scale. There are plenty of bureaucratically managed slowly launched duds too

I hate meta with a passion, but I don't deny they have some great infrastructure and engineers to enable the bad things they do to the world

Last year's Advent of Code had a task that was NP complete and lacked good well known approximation algorithms. I almost gave up on it when I realised as that feels impossible

In practice the data was well behaved enough and small enough that it was very doable.

It would be most fair to hash the names first, especially for this paper

I imagine one reason people have a hard time with the monty hall problem is that they have learnt a rule that seems to fit but really doesn't. A person not trained at all in math might do better as they haven't learnt that rule.

There's probably a name for that cognitive bias, but I don't know it.

"Probably beyond help" means they're not going to change their opinions no matter what, so trying to find phrasing that helps change their opinions is a waste of time.

Being a musk supporter in this day and age isn't a simple difference in opinion, unless you're a good person who's been living under a rock, in which case a mention of musk being pretty awful could actually help you.

I think there are lots of sort of tuned out but generally nice people who might shy away from buying a tesla if the perfidity of Musk is mentioned whenever tesla is discussed.

The people who like Musk are probably beyond help

It's pretty useful to remind people that buying a tesla is supporting Musk.

Singletons are just globals for people who have learnt "globals are bad" but lack a deeper understanding

With tesla, the bad apple is in charge

yeah, it follows their documentation, it's just a bad idea.

A lot of the things they break are pretty minor cleanups and it seems they could easily not have broken things. Many other languages, even compiled languages where the explosions happen at compilation, are much more careful about these things. For a dynamic language like python it's an especially bad idea.

That's fair. Too many languages and frameworks are all too happy to break things for pointless cleanups or renames.

Python for example makes breaking changes in minor releases and seems to think it's fine, even though it's especially bad for a language where you might only find that out runtime

Often some bits are automatable, or some manual steps are verifiable, and then suddenly it's a do something script

When I do this I keep some persistent state so I can interrupt it, e.g. if the thing is a yearly task I run it like `./do-the-thing.sh 2025`, and make a 2025 dir where I keep state on how far I've gotten

So if you OK the first step, I can touch a 2025/first-step file. If the script crashes or is interrupted and rerun, it can check for that file and skip the first step

If something has changed so the automation doesn't work, it's nice to be able to crash out without losing state, fix the script and rerun.

I usually have the script tell me just the next manual step and then exit, because that frees the terminal up for me to do other things. I can use the command history to rerun the script easily

I do this for some yearly tax stuff, as the big issue for me is that it was a year since I did it last and getting started with a complex and boring thing is hard

So I built a script that tells me what the first step is. When it's done I run the script again and it tells me what to do next. Often the first few steps are "download this CSV from the bank" so the script can detect I've done than and go directly to the next step when I rerun the script

The reason I have a script I rerun rather than a "press enter to continue" is because it then only keeps persistent state, and I can easily do a bit every day until done

A common pattern is

    if ! [[ -e checked-all-the-receipts ]]; then
         echo "check that the receipts match the list of expenses, then"
         echo "  touch checked-all-the-receipts"
         exit 0
    fi

It just means it's in the best shape of any of the languages in it's domain

wow, that's an amazingly impossible standard no software lives up to.

Or much technology at all. If you use anything that is 1000 years old, it's probably been maintained or cared for a lot during those 1000 years

Because security is hard and there are people constantly working on finding new issues.

It's a bit like asking why the army needs tanks when horses worked well the previous war

Also, why do I have to install new software in every couple of months to access my bank account, secure chat, flight booking system, etc., etc., without any noticable difference in operation and functionality. A lot of things unreasonably becoming incompatible with 'old' (we are talking about months for f's sake!!) versions. That's a nuisance and erosion of trust.

Are you talking about security updates?

I haven't seen that as much. The horde of people chasing the hype curve left C behind long ago. When they leave rust, rust will be better off

You can't rely on an authority to step in every time some disagrees. People need to resolve their own conflicts rather than yell until bailed out

It would be a silly strategy compared to saying that mixing languages is a bad idea and rely on inertia.

Also, letting rust in doesn't seem to stop the personal attacks, case in point

If you're gonna lead a group of people effectively, you kinda have to listen to them. leading by decree works occasionally, but you can't afford to do it often.

If there's a lot of people sceptical to rust, doing a limited experiment is one way to figure out if it's going to work. Rust people working in the kernel should act accordingly. Drama like this is not helpful

This seems like black and white thinking. There's a huge spectrum between

"suck it up, buttercup" or "I hear you; rust is gone".

where various levels of compromise happens.

Maintainers are people and people can change their mind over time. If rust was a huge success in large parts of the kernel and you still had a few holdouts, sure, you could tell them to adapt or go away. In this early stage, it's kinda up to rust people to show that both they and rust can work in this setting

Nothing is stopping you

Perhaps you could fork the kernel and start a better community?

If we were dealing with a toddler, one could blame the parent for rewarding their misbehaviour attention... an adult developer not so much

It's not without merit. Two languages is an extreme cost in complexity compared to one, and you have to be a deep expert in both to fully figure out anything on the boundary.

Perhaps rusts potential benefits are worth it, but it's certainly possible to disagree with that

Any trending language will attract some not so great people who make their choice of a shiny language their whole personality. It's really a pity for rust to be in that position now, as those people are there for the feeling of superiority and will cause drama to get it

If rust ends up being mainstream successful, those people will move on to something else and start attacking rust for whatever they feel their new language is superior in

Someone should have hugged them when they were kids

Well... the maintainer also shouldn't blow their stack

You can certainly imagine ways an authority figure could have defused a situation of a maintainer blowing their stack, but your framing kinda absolves the maintainer of any accountability for their actions.

A team member who needs a lot of defusing is doing something wrong, and needs to learn how to defuse themselves.

Often such apis (select/poll/epoll) have an option to wait with a timeout, so if you have a bunch of different timers, you can manage them yourself (e.g. on a heap) and set the timeout to the nearest timer

Of course if you have epoll you probably have timerfd, wich does give you a unified interface, just not as portable