> And before pcwalton drops in with his endless spamming
about Nim not being safe, Nim being undefined
He only jumps in, when someone claims Nim is safe or the sweet spot, or something equally wrong. Nim's pretty syntax comes with a price, just like Rust's safety comes with a different kind of price.
If he has said that, yes, then that would be wrong [1, 2] in that you cannot send GCed references between threads in the first place. For example, the following code results in an error:
var s = "foo"
proc foo {.thread.} =
echo s
createThread(foo)
test.nim(3, 6) Error: 'foo' is not GC-safe as it accesses 's' which is a global using GC'ed memory
[1] Modulo any remaining compiler bugs, of course, or using explicitly unsafe features.
[2] Also, are you maybe confusing this with Go, which does have such a problem?
[1] It may have been that using global variables to share refs between threads did only trigger a warning at some point, not an error. I'm not 100% sure about that. But the serialization has been there since the early days of multi-threading support in 2011.
But how could the segfaults then happen? Aha, you mean the test code perhaps shared via globals?
Personally I am quite sick and tired of that particular "take" on Nim - why not for once criticize other parts of the language? :)
Because I'm not interested in criticizing languages as a whole—that would be language warring for no reason. Claims of memory safety are what are important to me, just as, for example, claims of correct crypto constructions are important to crypto people.
Anyway, I see no reason to go further here, given that nobody has claimed anything is memory safe.
Claims that Nim is memory-safe when it's not is not a difference of design goal though.
It seems to me that a) Nim is (or at least is meant to be, but bugs can sidestep it) memory safe if you stay within the rules for it, and b) Nim is not throwing around vague claims of safety that are not documented in the language manual.
That's completely worthless. C is also memory-safe if you stay within the rules for memory safety.
> Nim is not throwing around vague claims of safety that are not documented in the language manual.
Of course not since nim is not posting on HN (as it's not a sentient being prone to procrastination) it's obviously nim supporters making claims about nim's safety.
It's really not any weaker of a guarantee than Rust makes, being memory-safe if you stay within the rules of not saying `unsafe`. Or opening /proc/self/mem for writing, anyway.
I'd also feel a lot better about Rust's moral highground of memory safety if its undefined behavior was actually spelled out a bit more rather than just punting the hard parts to llvm docs. I don't think every Rust user knows how to avoid aliasing problems between `&mut` and `*mut` either.
That said, I don't agree with the claim that Nim is less safe than Rust because Nim uses "ptr" types and Rust uses "unsafe" blocks to mark unsafe regions. I prefer Rust's approach, but it's pretty much just a question of UI, not anything substantive.
As I understand things, though, solving them is a work in progress.
And you asked why this happens, and I answered, because Nim claims it is secure. Not more not less.
It's like saying OpenSSL is perfectly (or as good as it gets) secure, and there aren't any known vulnerabilities. That statement is going to get a strong reaction from anyone that specializes in security and reads HN (for example tpatcek).
I don't like or dislike Nim. I did like Nim's macro system, although I fear its too powerful (it seems like macros would be really easy solution in many cases).
But I am genuinely interested in where this claim is made, perhaps we need to adjust some documentation or make things more clear - so do point us to it if you find it again.