"C essentialist" is a line very hard to hold, because C via ISO is moved towards an horrible language like c++ (generic,__thread,etc). So, it is not C anymore, it is simple and lean C which should be the target of an essentialist line of conduct.
Whatever, a good new language would first and above all be easier to write a compiler for than simple C.
__thread is essential for some applications, what's wrong with it?
To access TLS-ized system variables (for instance errno if I really need to, I would use the sysv ABI __tls_get_addr() function).
But in the application domain, I would use pthread TLS.
That's much much slower though.
You would have to cache the system TLS address in the application pthread TLS.
No, pthread TLS is the slower one. Accessing system TLS can be done fast since lib knows the details of the implementation and, worst case, it can use inline assembly.
Also, pthread TLS adds a pointer dereference to each access.
The compiler does not know the inner layout of how the system TLS variables are stored (could be musl way, bionic way, glibc way, etc). It only knows that for system TLS variables it has to go thru __tls_get_addr(), stated by the sysv ABI. Indeed, you are not forced to use pthread TLS to cache the value, you can use your own thread allocated memory, or keep it around on the stack/regs. On x86_64, once you have resolved the address with __tls_get_addr() you can use the same address value for all threads, then use common to all thread storage.
I think we agree.
Clearly no, because Vala has a bunch of issues with memory safety. Not because it's a bad language, but since it translates directly to GObject, there is a lot of problems around pointers, ownership, ... mainly because that language lacks maintainers and GTK/Gimp developers didn't like it because they are "C essentialists".