All these are implementation details.
The programmers should be seen as “users” of the language.
What you give here is a list of excuses on why system X doesn’t do what is best for its users.
The programmers should be seen as “users” of the language.
What you give here is a list of excuses on why system X doesn’t do what is best for its users.
For languages like Python for example, this is a big issue, and reason why alternative concurrency patterns to async/await haven't made much progress.
I don’t know why people confuse this so much
E.g. it might be visible to you that a certain operation runs quickly on certain inputs, or that a particular output is chosen for a particular input, even though the documentation does not specify the exact output.
“It’s difficult to do A given B”
As a user I don’t care about B. I just want A.
For your example, the concept of explicit pointers are orthogonal to threads. That’s why you can have OS threads with explicit pointers.
Just because it’s difficult to make them work together doesn’t mean they are incompatible as concepts.
It’s still an implementation detail.
For example, during Win95 one could argue it’s impossible for a crash program not to crash the whole system.
As a user I don’t care what’s going under the hood. I just don’t like it when my Windows 95 app can crash the system. It is an implementation detail
Targeting a specific IR is an implementation detail.
Having explicit pointers and thread are not mutually exclusive concepts. It’s the implementation details that make them difficult.
HN can be so annoying sometimes
Well, ironically, the exception that applies to all languages being: "does my code still work?" choices... which is what pron was addressing.
But the GP replied to a comment that was claiming threads of execution are better than async. So in the context of the reply the threads are the “best for the the user”