josefx

That was from an article covering the last public event mentioned by Wikipedia. Do you have any more recent sources?

At least some of the articles linked by that wikipedia page still listed various things like summons, divine rapier and illusions as disabled.

> They ran an event where the bots would play for 4 days straight and they won 99.4% of 42,729 matches.

Of course they also flat out disabled any mechanic their AI hadn't mastered.

> because that's not what it is

Why not? Is it the lack of race conditions? The lack of crashes or memory leaks? Is it the fact that you came up with it in five seconds and it is still a million times better than what we have? Or is it the fact that the holy book of Posix spells out how to do it badly in C and because of that we are never allowed to replace it with something better?

> and on UNIX, that’s, well, UNIX.

Let me clarify. There is no reason for std::env to be dragged down by UNIX, it could be its own, modern, safe thing with the Unix API living in std::pet_cemetary or some comparably clear namespace for people who have to pass runtime information to a C library through absolutely unsafe ways. Environment variables are usefull, the unix limitations make them less so.

> Rust can't magically fix how Unix works.

Rust has no reason to touch the original Unix API. Take a snapshot of the values at startup and write an API around that, any runtime modification of the Unix environment is suspect anyway and anyone who wants to deal with that rotten mess can jump through half a dozen hoops.

> Rust is doing everything it can here, these APIs are labelled unsafe

Unix gave us C, clearly Rust should have just labeled every C standard library function like malloc and free unsafe and thrown up their hands instead of introducing ownership semantics and all that messy compiler logic around it. After all Rust can't fix how Unix works, so they shouldn't have tried in the first place.

Except it still drags unsafe legacy APIs into the future as part of its core library. std::env for example isn't some safe take on how to deal with a system provided program environment in a modern multithreaded language, it is a thin wrapper around an ancient C POSIX API that is not threadsafe and cannot be fixed.

> Note that use-after-free would be prevented in memory-safe languages such as Java, Go or Rust.

There are also hardened malloc/free implementations for C based runtimes. Of course none of that is perfect, the famous heartbleed exploit for example bypassed any outside memory protection as the library agressively reused already allocated buffers, none of the languages you named would protect against that.

> We've been doing this for 50 years

Code that turns into an unmaintainable mess the moment even one of the types involved contains dynamically allocated data? Yes, seen that thousands of times.

The article creates a type that has typesafety, resource management and basic copy/assignment operations backed in.

> Yes, and then in the interim we invented having a hundred trillion dollars in GDP.

And every now and then we have to rescue banks that are too big too fail at the cost of everyone else, because someone dreamed up a way to increase short term profits that involves giving loans to people who will never pay them back.

> neither your car,

Praising a trillion dollar GDP, but can't afford a used car.

> from a flat earth

That in the same paragraph as Galileo is a bit self contradicting. The church was stuck on an ancient greek model of the universe and the greeks were very much aware that the world was round, they once spend a day or two measuring it.

From what I understand a data race on a simple built in feature like an interface pointer can result in a bad address / type pair, which can cause memory safety issues on any future access. I don't think you can get the JVM itself confused about what type a pointer points to.

> Knowing you got paid, being able to pay your rent, being able to pay for goods and services… seem like pretty everyday concerns.

Is it usual for companies in the UK to just not pay their employees?

> The bad guy here is the driver. Could Uber have done more?

Isn't their entire business model build around bypassing the regulations build around the taxi industry? Things like training for new drivers and I think they even refused to do mandatory background checks early on.

> If you want to force Uber to take responsibility for the driver, the simplest thing is to get rid of the driver.

When their driverless car ran over a cyclist they pretended it was too dark to see anything, using a video from a cheap camera as "evidence".

Unsuitable? Probably depends on your use case. Even a normal end user system shouldn't constantly kick your threads out unless it has enough other things to do to to keep every core busy.