There's definitely some talk in the community on improving dev tooling as a logical next step to improve adoption, eg: https://github.com/nim-lang/RFCs/issues/300
In Nim in 2020: A Short Recapnim-lang
RFCs
OPEN SOURCE2019–2025
nim-lang / RFCs
RFCs
A repository for your Nim proposals.
31Distinct people
53Mentions
2Explicit recommenders
143GitHub stars
What to know before exploring
What it is
A repository for your Nim proposals.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
Nim has been on a steady path of improving tooling support[0] since 2.0 release. LSP is a lot more stable now than even a couple months ago. That's what I love from…
archargelod used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- mratsim/weave · linked in 5 of the same discussions
- nim-lang/nim · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 8:03:49 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year53 dated mentions
Observed mentions: 2019-01-09 14:38:56 UTC to 2025-12-05 18:00:03 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 5 | 2 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 15 | 0 | 15 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 13 | 3 | 10 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 0 | 2 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
RFCs
A repository for your Nim proposals.
Which RFCs are being implemented?
Check out these milestones for the list of RFCs that are planned to be or are currently being implemented: #503.
Contributing
Submit a new, appropriately named issue based on issue form.
Read the full README on GitHubWhat Hacker News says
15 sourcesInteresting to see more CPS in the wild.
Nim may have first-class continuations in the not too far future as well https://github.com/nim-lang/RFCs/issues/295
I'm still evaluating and comparing CPS vs coroutines as the base primitive.
In Don’t Think, Just DefunctionalizeState machines can be metaprogrammed: https://github.com/mratsim/Synthesis
You describe the events, transitions and even interrupts and this compiles to optimized goto statements with no allocation, no indirect function calls, no switch statement.
There are compile-time checks to make sure you don't have state with no transition from and it also produce a visual graph of your state and transitions.
It's been tuned to be used as the core of my high performance multithreading runtime so zero overhead compared to handwritten.
It is suitable for any state machine with zero alloc constraint and state machines can be composed (they are just a function).
I hope in the future to be able to add model checking using Nim Z3 integration so that we can reach Ada/Sparks formal verification prowess: https://github.com/nim-lang/RFCs/issues/222
In Nim Apocrypha, Vol. INim has merged first class view types and their lifetime tracking:
- https://github.com/nim-lang/RFCs/issues/178
- https://nim-lang.org/docs/manual_experimental.html#view-type...
In V (Vlang) 0.2You can read about the reasoning behind subgraph ownership here: https://github.com/nim-lang/RFCs/issues/244
In ORC – Nim's new memory managmentNim is apparently getting support for owned pointers [1]. There's a proposal [2]. The proposal PR has since been closed, but it's apparently still being worked on.
[1] https://nim-lang.org/araq/ownedrefs.html
[2] https://github.com/nim-lang/RFCs/issues/144
In Nim compiler — Pascal source codeThis is currently being remedied as we speak:
https://github.com/nim-lang/RFCs/issues/250
https://github.com/nim-lang/Nim/pull/15287
In Prologue: A web framework written in Nim> no data races for multithreading
This is simply not true. Rust borrow checker has no notion of memory models: i.e. sequential consistency, acquire, release or relaxed semantics.
The Tokio team needs an additional model checker to ensure no data race in Tokio:
- https://github.com/tokio-rs/loom
If you want to ensure no data races you need formal verification not a borrow checker, I've compiled my research and a RFC for Nim formal verification here:
- https://github.com/mratsim/weave/issues/18
- https://github.com/nim-lang/RFCs/issues/222
In Nim 1.4One of the links in the end of the article leads to the RFC which talks exactly about this, see last commit by Araq especially:
https://github.com/nim-lang/RFCs/issues/177#issuecomment-696...
In short: yes, the current plan is to phase out other GCs over time.
In Introduction to ARC/ORC in NimI've written Weave for the Nim programming language:
- https://github.com/mratsim/weave
- RFC that describes the goals: https://github.com/nim-lang/RFCs/issues/160
In Show HN: A thread hierarchy management library in CI've written a multithreading runtime from the ground up in Nim.[1]
And yes, writing that taught me that current programming languages are not sufficiently equipped to deal with concurrency bugs, including Rust. The bugs that I had where of the dining philosophers kind (deadlocks or livelocks when trying to put a thread to sleep for example or resolving data dependencies between multiple threads), some were due to a bug in glibc where only formal verification allowed me to ensure that I was doing the correct thing and it was the lower-level layers that was incorrect.[2]
Similarly, state machine formal verification to prevent design bugs is something that hardware engineers are deeply aware of but would also be extremely useful to ensure "correct-by-construction" event driven code in software engineering.
In comparison, we have many more t
Read the rest
ools to address memory bugs (Address Sanitizer, Valgrind and fuzzers in particular) but synchronization and communicating state machine bugs are still impractically addressed at the moment. This is something I'd really want Nim to explore and I'm really excited about the Z3 integration[3] to enable new formally verified use-cases[4].
Unfortunately, when I express concerns about those bugs to people from the Rust community, they tend to dismiss those as if the borrow checker was the panacea to all multithreading problems.
[1]: https://github.com/mratsim/weave
[2]: https://github.com/mratsim/weave/issues/56
[3]: https://nim-lang.org/docs/drnim.html
[4]: https://github.com/nim-lang/RFCs/issues/222
And that's where model checking / formal verification is a tremendous help (or would be if it was easier to use).
There are many properties of multithreaded/distributed systems that are emergent and that current static compilers don't address.
In distributed systems it's becoming more common to use TLA+[1] to model the system and ensure that we don't have bugs at the design level (rather than just the system level).
In particular for message-passing, I'm quite curious about the state of the research on Communicating Finite State Machines[1] and Petri Nets[2] and if there are actual products that could be integrated in regular languages and are not just of academic interest only.
I expect that Ada/Sparks[1] has some support for this pattern though Ada multithreading story is not there yet (?).
I'm quite excited about the future Z3 prover i
Read the rest
ntegration in Nim[5] and the potential to write concurrent programs free of design bugs[6] to address both ends of the concurrency bugs:
- bugs in the low-level concurrent data structure via formal verification (which is something I used int he past to prove that my design was bug-free and that the deadlock I experienced was a condition variable bugs in Glibc[7] and I had to directly use futexes instead.
- bugs in the high-level design, implemented as event-loop / finite state-machine reacting to events as received by channels
Are there people working on model checkers or formal verification in Rust? Like the author, i think addressing memory bugs.the borrow checker is only a part of the "fearless concurrency" story and preventing design bugs would be extremely valuable.
[1]: https://lamport.azurewebsites.net/tla/tla.html
[2]: https://en.wikipedia.org/wiki/Communicating_finite-state_mac...
[3]: https://en.wikipedia.org/wiki/Petri_net
[4]: https://www.adacore.com/sparkpro
[5]: https://nim-lang.org/docs/drnim.html
[6]: https://github.com/nim-lang/RFCs/issues/222
[7]: https://github.com/mratsim/weave/issues/56
And shameless plug, my talk at the NimConf on debugging multithreading programs (data structure and design): https://www.youtube.com/watch?v=NOAI2wH9Cf0&list=PLxLdEZg8DR...
Slides: https://docs.google.com/presentation/d/e/2PACX-1vRq2wvd4q_mo...
stuff like concepts and code reordering are planned to eventually became stable.
Nowadays everything is decided in the RFCs repo https://github.com/nim-lang/RFCs/issues before a PR hits the main repo.
In NimConf 2020 Videos> Most of them were specific to Windows, which casts a lot of doubt on its cross-platform promise.
Oh. That really surprised me, as I had assumed the bugbears I have as an occasional nim user were because it was developed for/on Windows primarily. Actually bothering to take a look seems to show me that isn't the case at all.
Bugbears such as the linking story on Linux¹, the argument handling², the style and verbosity of the compiler output, [a bunch of others]. Nothing show stopping to be fair, but a bunch of things that just seem out of place(and that always seem to require explanation when co-workers see a nim tool).
1. https://github.com/nim-lang/rfcs/issues/58
2. https://nim-lang.org/docs/parseopt.html , although alleviated by argparse to some extent.
In Pros and Cons of NimYou're right no dependent types, though to be fair that wasn't the only thing mentioned, and none of the other replies have yet suggested a language with dependent types either.
I was responding to:
> ...great tooling and moderate performance. There are many aspects to programming languages beyond raw speed. The world has enough cookie cutter procedural and OOP languages. I'd love to see a new language from a different paradigm succeed.
Nim's paradigm is fairly open (no small thanks to metaprogramming and unified function call syntax), and drops a lot of the baggage from the usual class (ahem) of OOP languages. There's loads of mainstream languages that focus entirely on OOP and I really resonate with wanting to explore different approaches to creating solutions, as I think OOP tends to colour how a language approaches problems.
Seems a b
Read the rest
it sudden to jump from my posting a reply to this as the same vein as "rewrite it in Rust".
In terms of languages with existing dependent type implementations, it looks like the main options would be ATS, Agda, F*, or Idris. Some of these are pretty far away from the OOP paradigm too.
Also:
> Nim doesn't have them and never will
https://github.com/nim-lang/RFCs/issues/172