8 ms·

> isn't that rust, but better? Clearly no, because Vala has a bunch of issues with memory safety. Not because it's a bad language, but since it translates dire

by aikah 4y ago

> isn't that rust, but better? 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".

sylware 4y ago
"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.
- bonzini 4y ago
  __thread is essential for some applications, what's wrong with it?
  - sylware 4y ago
    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.
    - bonzini 4y ago
      That's much much slower though.
      - sylware 4y ago
        You would have to cache the system TLS address in the application pthread TLS.
        bonzini 4y ago
        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.
        sylware 4y ago
        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.

by aikah 4y ago

sylware 4y ago

"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.

bonzini 4y ago
__thread is essential for some applications, what's wrong with it?
- sylware 4y ago
  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.
  - bonzini 4y ago
    That's much much slower though.
    - sylware 4y ago
      You would have to cache the system TLS address in the application pthread TLS.
      - bonzini 4y ago
        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.
        sylware 4y ago
        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.