My First Program With Nim! It's a Password Generator!

What's the reason why nimcrypto's sysrand isn't part of the standard library? It seems like a good candidate.

ARC/ORC cpu intensive loop bug?

I opened a [Github issue](https://github.com/nim-lang/Nim/issues/15392) so hopefully we can find a solution. Thanks, I'll try using Weave. It looks much more polished then the standard library threads. I appreciate the high performance SHA2 libraries you pointed out but I really only mentioned

Update MinGW related info and packages

I opened a [Github issue](https://github.com/nim-lang/Nim/issues/15391) about it.

Update on --gc:arc

The old refcounted gc relied on a scan of the stack. arc/orc works strictly pointwise instead, no stack scan anymore.

Option to hide "Last Online" in forum

I created an issue for this feature request: see

Update on --gc:arc

I'm curious about the "Independent of the stack size, large arrays on the stack do not cause slowdowns" part. Is that because arrays are initialised or due to the stupid stack-extension mechanism in Windows where it touches stack pages at function entry?

Growth of popularity and Nim community

For the record, I love the new GC. I hope the mentioned fix for ARC in arraymancer is merged soon because I want to start using that too.

How to figure out why proc is not GC-safe? And is there a way to force Nim to ignore that?

Because `func` is relatively new, it's about a year old and many libraries, in particular the standard library, predate that.

How to figure out why proc is not GC-safe? And is there a way to force Nim to ignore that?

> In practice it works better to annotate many of your procs directly with the > effects you had in mind. Would it be a good way to prefer to use `func` instead of `proc` everywhere if it's possible? Also, I wonder why `func` is not used more heavily, I see people mostly use `proc` even in cas

How to figure out why proc is not GC-safe? And is there a way to force Nim to ignore that?

var global: seq[string] proc violation = var s = global proc q() = violation() proc p() {.gcsafe.} = q() Run I do get a stack trace: temp2.nim(4, 6) Warning: 'violation' is not GC-safe as it accesses 'global' which is a global usin

How to figure out why proc is not GC-safe? And is there a way to force Nim to ignore that?

I think a stacktrace of effect violation (`gcsafe`, `noSideEffect` and `raises: []`) would significantly improve effects ergonomics. And they are one of the most interesting safety features of Nim.