test.nim:
var count1 {.threadvar.}: int
var count2 {.global.}: int
var count3 : int # nim says this is global, not threadvar
nim follows the C and C++ route here; seems like the D route (thread local by default) is safer, and potentially more efficient (less concurrency issues)
Curious why this is the case?
I know of no reliable statistics about global vs thread local in the real world, but "thread local" is harder to support for the more foreign targets (there is this whole --tlsEmulation:on feature...)
if the reason is it'd prevent common idiom var count3 = 3 (which currently errors as: "Error: a thread var cannot be initialized explicitly; this would only run for the main thread"), this could be fixed.
True but it introduces too much runtime machinery for my taste.
Good code evolved to use explicit passing of parameters, so neither thread local nor shared variables are common anymore (ymmv). But if a global is needed it's usually for some configuration stuff that is shared across threads making global the better default. But you can argue either way, Nim's .gcsafe design certainly pushes one to use thread local storage. Which sucks for the logging module at least...