What happens when you make a move in lichess.org?

Isolation does weird things to the mind, one of which distorts reflected appraisal, other parts where reflected appraisal is denied in communications are even more impactful. It induces a involuntary hypnotic states which varies in intensity by exposure.

The tortured takes on mannerisms of the torturer, and when denied communication, or only distorted reflected apprsail long enough their entire being unravels, and you have psychotic break or disassociate completely. The psychotic break is a semi-lucid state where planning is capable. To make an apt comparison, an active shooter might fall into this latter category. Years of investigations into what causes these people to do what they did, and the powers that be can only say with certainty that these people were bullied, but no clear cause can be found.

Coercion is a dangerous thing.

You can corroborate what I've said with the literature in the books I mentioned, or with isolation studies where the studies had to be cancelled early for the safety of the study participants. There is a lot of research out there.

Destroying someone's identity, their personality, what makes them them, is true evil, and these structures are how you do it which is why its so important to recognize the problem, few do.

Your comparison is apples to oranges. It is not asking someone a opinion, its silencing them entirely by force, where they are disadvantaged when they don't answer. There is a very big distinction between the two.

Basically, you needed a good and experienced developer from the start of a project for it to be a nice code base.

> I'm very fluent in Scala 2, but I will avoid Scala if I can, mostly to stay away from purely functional programmers.

There is the whole [Li Haoyi](http://www.lihaoyi.com/) ecosystem in Scala that is much more python-like, but nicely designed, statically typed and using immutable datastructures by default. I think it's the best you can get nowadays if you want to have immutable datastructures on the JVM. Any other option I've ever tried was way worse.

If you are fine with Java's stdlib then I guess Kotlin is the better choice.

> Does it prevent me from using a non-thread-safe object in multiple threads?

I would answer the question with yes, but maybe in a different way than you might expect. Scala prevents problems/bugs from using a non-thread-safe object in multiple threads by simply having immutability by default. Rust cannot do that (due to performance) so it has to have another way (the borrow checker). I would argue that the Scala way is better if you don't need the performance / memory-efficiency of rust and can live with garbage collection. That reduces the domains that you can use Scala for, but in exchange the code will be simpler compared to Rust code, so in those domains Scala will have the advantage but it's a minor one.

> Or storing a given object which is no longer valid after the call ends?

To this one I would say "in practice yes". Rust is better here, but when using e.g. [ZIO Scope](https://zio.dev/reference/resource/scope/) then the problem isn't really existing. You can technically still do something like that, but you would basically have to do it intentionally. Rust has the advantage here though, but it's a minor one.

> Does it have a unified error handling culture?

No, Scala has no unified culture. Maybe the situation is better than in Rust, but then Rust has its own problems. [Just a few days ago I found a comment about a problem caused by a hardcoded panic that caused issues](https://github.com/orgs/meilisearch/discussions/532#discussi...).

> Does it have named destructuring?

Unless we are talking about two different things, yes it does. I would even argue that Scala is more powerful here, because it also supports local imports and (with Scala 3) exports. So not only can you extract fields of an object into a variable, you can also generally bring them into scope and alias them at the same time, but you can do the reverse as well: [you can export them as well](https://docs.scala-lang.org/scala3/reference/other-new-featu...).

Yes the instance of chess is finite but the problem of computing moves is inherently in NP.

The key is that just because a problem is in NP it does't mean that its difficult to solve the instances with small parameters.

See the famous coloring, SAT, or any other equal NP problem...