Yes
Design: https://github.com/nim-lang/RFCs/issues/559
Plan: https://forum.nim-lang.org/t/13357#81170
In Nimony (Nim 3.0) Design Principlesnim-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 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 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
53 sourcesRelevant links:
Roadmap for 2025 and beyond - https://github.com/nim-lang/RFCs/issues/556
Nimony Architecture - https://github.com/nim-lang/nimony/blob/master/doc/design.md
Planned design - https://github.com/nim-lang/nimony/discussions/529
Nimony progress - https://forum.nim-lang.org/t/12693
In Work on Nim 3 has begunPersonally, I agree, but the Nim lead dev looked into it and declared it "unreasonably hard to implement with unknown effects for template instantiation"
https://github.com/nim-lang/RFCs/issues/547#issuecomment-1879179448
I wish he had detailed the problems more as I think opt-in to insensitivity at import time with some kind of compile-time error for ambiguity is The Better Answer. { For then Nim would not be taking away ident choice from (many) creators in order to support the ident-pickiness of (many) consumers. It's hard to measure/know/forecast, of course, but I suspect the 2nd "(many)" (the number of such very picky consumers) is low in absolute terms in spite of usually high name-consumer/name-producer ratios. A huge fraction of people just go along with whatever the name-producer did, a small fraction complain loudly, and a
Read the rest
n even smaller fraction would care enough to opt-in to insensitivity if such were available and, say, sometimes caused trouble. There is also a "broader system" aspect of the producer-consumer ratio changing as a prog.lang goes from dark horse/obscure/niche to popular (with a lot more consumers). }
All this said, I would reinforce what others here have said - the property is not actually as onerous in practice as you might imagine. So, it is really worth suppressing knee-jerk reactions to this one feature and giving the language a try, just with `nim c/cpp/js --styleCheck:usages` or whatnot.
> Overall, are you happy with your choice of using Nim?
Yes. It's a pleasant language to work with.
> What would you do different? (and what unexpected positives did you find)?
A couple of things I think need improvements are: (1) better IDE support (especially for JetBrains IDEs), and (2) better support for true sum types and pattern matching[0].
As for unexpected positives, I found that the standard library covers a lot of functionality that I rarely (or ever) need a 3rd party package. Maybe that's because I'm not doing anything exotic.
[0] https://github.com/nim-lang/RFCs/issues/548, https://github.com/nim-lang/RFCs/issues/525
In Fusion – A hobby OS implemented in NimNim 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 community-driven languages: while BDFL isn't very passionate about tooling, people have spoken and gears are turning to improve it[1].
It also helps that there is a company around (Status) that's using Nim in production and wants to invest money and dev-time[2] in the language.
- [0] https://github.com/nim-lang/RFCs/issues/544
- [1] https://forum.nim-lang.org/t/10959
- [2] https://forum.nim-lang.org/t/10762
In Crystal: Fast as C, Slick as Ruby with Tom Richards> This is a real trade-off. The feature I have here provides strictly less static safety than using sum types. There is a slight performance cost to checking the type tag when accessing case-specific fields. In return, you get simpler, more familiar syntax for working with case-specific fields, including mutable ones.
Interesting post! Nim uses variant/case objects as well. Generally they're pretty handy and more flexible than sum types as you can access non-variant fields as regular objects. Though it means you can't use the same field name twice, however on the other hand you can bring common fields out of the case portion. Also, a single object can have multiple case variants which can be handy.
There's a PR for adding the stricter sum types and pattern matching as well. https://github.com/nim-lang/RFCs/issues/525
Currently I just use
Read the rest
a library for sum type syntax on top of object variants: https://github.com/andreaferretti/patty
Oh, it's interesting, and I wish you the best of luck with your reading group!
I mentioned the others more out of thoroughness than any intended criticism. A wide diversity of students implies that different materials aimed at various levels always helps - some styles "speak" to some readers more/less. I would be personally quite curious if you decide to go with that book for teaching programming just happening to be in Nim. (Someone else who likes to teach elementary programming once said he might try to teach programming with Nim.) [1]
There are also a lot of free online resources like "Nim for ... Python Programmers" type things off the documentation site. [2]
[1] https://github.com/nim-lang/RFCs/issues/456#issuecomment-111...
[2] https://nim-lang.org/documentation.html
In Computer Programming with the Nim Programming Language: A Gentle IntroductionIf I recall correctly, lazy symbol resolution, which would allow both circular module imports and order-independent procs, was initially on the roadmap for 2.0. Currently, it was moved to a stretch goal for 2.2.
https://github.com/nim-lang/RFCs/issues/503
In Nim 2.0Python doesn't work with circular imports. NodeJS does. After using NodeJS for such a long time, I think it is a feature that is taken for granted.
That being said, the Nim team is working on it as per a few issues:
[1] https://github.com/nim-lang/rfcs/issues/6
[2] https://forum.nim-lang.org/t/2114
I love the language, and this is probably the only bottleneck for me.
In Nim 2.0> It's not so much a competitor (in performance or clarity) to Odin or Zig as it is a competitor to Go or something
That seems accurate. Dealing with raw pointers as one does in Odin or Zig is very much de-emphasized in favour of dealing with safe references, and a lot of effort is put into optimizing out all the overhead of those reference checks (hence ARC/ORC) and writing code to evade them. The manual memory management features of Nim are there for flexibility and fallbacks and are not really the main way to write code: even for embedded. The stuff that Zig (and Odin?) do surrounding allocators and alignment, and constructs for slightly-safer pointers, are really very interesting yet are most helpful if you are indeed working with pointers and worrying about offsets: which you usually aren't in Nim.
I am curious as to what you mean ab
Read the rest
out comptime, though. I have gotten the impression that equivalent constructs in Nim are more powerful. You have `static` blocks and parameters, `const` expressions, `when` conditionals, and then also both templates and typed macros operating on the AST (before or after semantic checking)... `when` even provides for type-checking functions with varying return types (well, monomorphized to one type) via `: auto` or the `: int | bool | ...` syntax.
I will also defend "naked imports" as a feature that works very well with the rest of the language: functions are disambiguated by signature and not just name and so conflicts scarcely occur (and simply force qualification when they do). And, this allows for the use of uniform function call syntax - being able to call arbitrary functions as "methods" on their first parameter. This is incredibly useful and allows for chaining function calls via the dot operator, among other things. Besides, if you really want you can `from module import nil` and enforce full qualification.
Interest in proper structural pattern matching sparked back up again recently and some complementary RFCs were proposed: https://github.com/nim-lang/RFCs/issues/525 and https://github.com/nim-lang/RFCs/issues/527.
Couldn't edit my post, but forgot to mention my main pain points with Nim have been:
- its module system, especially not being able to have mutually recursive imports (there has been a 7 year old proposal[1])
- order-sensitive declarations of procs (i.e. can't use a proc defined further down in the file unless you add a forward reference to it). For the latter there's an experimental pragma[2], but it doesn't work a lot of times once you introduce mutually recursive calls
- object variants requiring declaration of a separate enum instead of allowing inline declaration of the variant cases, and a close issue[3] with not being able to define the same field names under different variant cases.
[1] https://github.com/nim-lang/rfcs/issues/6
[2] https://nim-lang.org/docs/manual_experimental.html#code-reor...
[3] https://github.com/nim-lang/RFCs
Read the rest
Well, maybe not writing. Occasionally low-level C libraries - especially those that deal with keyboard input - decide to provide identifiers differing only in case... There's a WIP RFC for providing a way to deal with identifiers that need to be verbatium by surrounding them with backticks, though.
https://github.com/nim-lang/RFCs/issues/477
In Nim 2.0.0 RC2Showing the 15 most recent of 53 sources. Enable JavaScript to search and browse every indexed mention.