> Isn't that a bit too high to be manageable?

Yes. See many past conversations on why Github Issues become unmanageable.

Labels help to segment, but aren't enough.

I find the number of 'open' issues a demotivator (bordering on depressing) for my projects, or when I look to work on others; even if most aren't issues but support questions/feature requests/on hold. If not triaged well, digging through to find the real bugs takes effort.

Github tried with 'Projects' but I haven't seen many (any?) projects using them successfully. For individual workflows they seem to work well. Big projects have fallen back on milestones.

Julia has 2400 open issues and 660 open PRs (http://kristofferc.github.io/post/julia_issue/ 2017)

but the size of Julia is much larger and it serves a purpose/focused market (nim aims to be a solution for everything and it is a master of none).

What do you mean? Julia is a general-purpose language too.

Rust has 4,500 dotnet core libs 2,600 donet coreclr has 2,000 Golang has 4000

Actually plenty of issues are RFCs and feature requests.

We have a new RFC repos to brings a bit more sanity to the bug tracker: https://github.com/nim-lang/RFCs/issues

Ansible has 3900+ issues and 1700+ open pull requests on Github...

So you're suggesting Ansible's issue count is also unmanageable?

No, he's suggesting thousands of open issues on successful projects are common...

I am merely suggesting popular open source projects can have a really large number of issues.

Was looking at Flutter recently and it has over 4000 issues.

They can always just go the React Native route and blindly close them all. Problem solved.

I think that's understandable, in spite of being a young niche/language the community oversells it continuously on larger communities (like HN) but it is that much polished. The promise: pythonic, cross compilable, fast solution for everything with readable macros.

And in my opinion it is not like that, see my comment on the top level.

You're right: there are a lot of bugs and this should be improved!

However, some of those are subjective opinions: a lot of people do see it as pythonic in syntax, even not if pythonic in other decisions. It is cross compilable and fast and one can write readable macros and create readable DSL-s with it.

All other similar languages have even bigger issue counts: this is a shallow metric to base a conclusion on.

Issues have a status one presumes -- 1000 "requests for new features" or minor BS complains don't matter as critical issues.