nimskull
nimpy
nimskull | nimpy | |
---|---|---|
13 | 38 | |
253 | 1,420 | |
2.0% | - | |
9.9 | 5.8 | |
10 days ago | 3 months ago | |
Nim | Nim | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
nimskull
-
V Language Review (2023)
> Unfortunately there seems to be a big "civil war" happening right now in Nim land
I believe the war is already over, the other side forked the language and seems to move in their own direction to create something new - https://github.com/nim-works/nimskull . That's probably for the better.
I've been around Nim communtiy around a year and I haven't seen any major conflicts break out since these people left. Nim is still actively developed and a jou to use.
-
OpenD, a D language fork that is open to your contributions
FYI, some members of the Nim community are working on a fork, for apparently similar reasons as OpenD (community-led development). https://github.com/nim-works/nimskull under active development and not ready for general consumption though, from my understanding.
-
A Tour of C++, 3rd edition (covering C++20 plus a few likely features of C++23)
There's a looming feeling that C++17 is really going to be the last version of C++ (practically, in production). The Vasa is now half-sunk [0][1], but the alternatives are yet to be truly born. The current issues surrounding the language standards:
- The important but half-baked features of C++20 that has never really been polished enough for actual production usage (modules, coroutines)
- Unnecessary "hyper-modern" C++ features which are dead on arrival (ranges)
- The dramatic increase in build times due to the STL library (which are accelerated by those hyper-modern C++ features) [2]
- The fleeing of LLVM/Clang engineers to other projects (as you've said, Apple engineers shifting work to Swift, and Google abandoning Clang and moving to Carbon).
- Implosions in the ISO committee (notably the controversy surrounding the rape convict)
It's really not looking good, but there aren't that much alternatives so I think people will just stick to C++17 for the moment. Listing the worthwhile competitors:
- Rust is a bit too awkward to use in many cases where C++ is used (particularly with unsafe Rust), and inherits some of the hyper-modern complexities/insanities of C++.
- Zig is still too unstable, they just finished reworking the compiler
- Jai is not even released to the public
- D might be a candidate but IMO they should really commit 100% fully for GC-less betterC mode...
- Nim still has many warts and unbaked features, and also the dev community was split into half recently [3]
[0] https://www.aristeia.com/TalkNotes/C++vstheVasa2-ups.pdf
[1] https://www.stroustrup.com/P0977-remember-the-vasa.pdf
[2] https://old.reddit.com/r/cpp/comments/o94gvz/what_happened_w...
[3] https://github.com/nim-works/nimskull
- NimSkull: A Hard Fork of Nim
-
Nim Version 1.6.6 Released
I started programming in Nim around 2015 and still write code in it from time to time. At this point I would have a tough time suggesting the language to anyone for much. While you can certainly accomplish almost any programming task with Nim, how much frustration you will encounter fighting the compiler and broken / under-specified language features and semantics might be a turn-off. There are other major warts with Nim, which I'll outline briefly below.
1) Nim's leadership is awful and has always been historically. Those in charge of managing the community are more interested in their personal reputation's and resumes than they are actually contributing working software to the language's ecosystem. Even the BDFL treats Nim like their own personal compiler R&D playground. There are so many broken features in Nim which never see the light of day or never get removed.
2) Continuing to expand on the point above, the Nim compiler has become insanely difficult to work on. As more and more half-baked features have been added to the language, the situation has only worsened. There are many would-be contributors who have come into the community only to leave completely frustrated or appalled by the lack of interest in improving the situation from those leading the community.
3) The development path is driven by leadership and not the community, and leadership has no plan. This was extremely evident last year when Araq and others were asked for a roadmap for Nim and they admitted to not having one, and basically wrote one up in a forum thread. Araq and dom96 and a few others, especially those who have been brave enough to actually deploy Nim code in production (looking at you status.im) tend to dictate what gets worked on or fixed. There is no coordination amongst folks working on initiatives. You can look at the `fusion` project, which was started by Nim's leadership, drew contributors in, and then was abandoned by leadership while maintainers were left on the hook to keep things afloat until they too dumped the project.
Things have gotten so bad, that a hard fork has been in development since last year, and many of the more senior community members or those who have been around for a bit have migrated there: https://github.com/nim-works/nimskull
Nim's community now consists of mostly new members or folks who weren't really active in it before, but maybe used Nim. Of course, the leadership remains in place, but there are only a handful of folks remaining that have been around for more than a year or two. Mostly those who bit the bullet on using Nim in production or built large projects with Nim and are stuck maintaining them.
My advice would be to look elsewhere.
- NimSkull - A reimagining of Nim
-
Computer Programming with Nim
A lot of previous contributors to Nim are currently working on an experimental fork due to disagreements with the development of the official compiler: https://github.com/nim-works/nimskull
nimpy
-
Mojo is now available on Mac
I mean honestly, the closest language to Mojo really is Nim. In the latest Lex Fridman interview [0] when he talks about his ideas behind Mojo it pretty much sounds like he's describing Nim. Ok fair, he wants Mojo to be a full superset of Python, but honestly with nimpy [1] our Python interop is about as seamless as it can really be (without being a superset, which Mojo clearly is not yet). Even the syntax of Mojo looks a damn lot like Nim imo. Anyway, I guess he has the ability to raise enough funds to hire enough people to write his own language within ~2 years so as not have to follow random peoples whim about where to take the language. So I guess I can't blame him. But as someone who's pretty invested in the Nim community it's quite a shame to see such a hyped language receive so much attention by people who should really check out Nim. ¯\_(ツ)_/¯
[0]: https://youtu.be/pdJQ8iVTwj8?si=LfPSNDq8UKKIsJd3
[1]: https://github.com/yglukhov/nimpy
-
Show HN: Pip Imports in Deno
You can also do this in Nim, which basically means you can write any program you could in Python with libraries in Nim. https://github.com/yglukhov/nimpy
-
Nim v2.0 Released
Ones that have not been mentioned so far:
nlvm is an unofficial LLVM backend: https://github.com/arnetheduck/nlvm
npeg lets you write PEGs inline in almost normal PEG notation: https://github.com/zevv/npeg
futhark provides for much more automatic C interop: https://github.com/PMunch/futhark
nimpy allows calling Python code from Nim and vice versa: https://github.com/yglukhov/nimpy
questionable provides a lot of syntax sugar surrounding Option/Result types: https://github.com/codex-storage/questionable
ratel is a framework for embedded programming: https://github.com/PMunch/ratel
cps allows arbitrary procedure rewriting to continuation passing style: https://github.com/nim-works/cps
chronos is an alternative async/await backend: https://github.com/status-im/nim-chronos
zero-functional fixes some inefficiencies when chaining list operations: https://github.com/zero-functional/zero-functional
owlkettle is a declarative macro-oriented library for GTK: https://github.com/can-lehmann/owlkettle
A longer list can be found at https://github.com/ringabout/awesome-nim.
-
Prospects of utilising Nim in scientific computation?
I use Python daily for its massive momentum for scientific stuff, but I also use Nim for everything else. Nim compiles to C, and making Python native modules with Nim is easy with Nimpy.
- Can't run compiled nim code in Python
-
Returning to Nim from Python and Rust
If are a data scientist and come from python take a look at nimpy, a great way to just import python libraries and use them! https://github.com/yglukhov/nimpy Numpy, pandas, pytorch all usable in Nim.
Nim is the ultimate glue language, use libraries from anything: python, c, js, objc.
-
Python's “Disappointing” Superpowers
I've come to really enjoy programming in Nim. Note that Nim is very different language despite sharing a similar syntax. However, I feel it keeps a lot of the "feel" of Python 2 days of being a fairly simple neat language but that lets you do things at compile time (like compile time duck typing).
There's a good Python -> Nim bridge: https://github.com/yglukhov/nimpy
-
Dunder methods in nimpy
See this nimpy issue about it: https://github.com/yglukhov/nimpy/issues/43
-
What language to move to from python to speed up algo?
It has pretty good integration with python, either for having your main code in python and writing small hot functions as nim and importing via nimporter or using python libraries in nim via nimpy.
-
ABI compatibility in Python: How hard could it be?
Related: Nimpy[0] provides an easy way to write Python extensions in Nim, which manages the ABI side very well.
Python 2 is now gone, but until it was, Nimpy was an easy way to write Python extension modules that only needed to be compiled once, and would work with any of your installed Python 2 and Python 3. Magic.
[0] https://github.com/yglukhov/nimpy
What are some alternatives?
Nim - Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula. Its design focuses on efficiency, expressiveness, and elegance (in that order of priority).
NimProgrammingBook - Computer Programming with the Nim Programming Language -- A gentle Introduction
Box - Python dictionaries with advanced dot notation access
Arraymancer - A fast, ergonomic and portable tensor library in Nim with a deep learning focus for CPU, GPU and embedded devices via OpenMP, Cuda and OpenCL backends
nimporter - Compile Nim Extensions for Python On Import!
matrix.to - A simple stateless privacy-protecting URL redirecting service for Matrix
scinim - The core types and functions of the SciNim ecosystem
nimblas - BLAS for Nim
nimpylib - Some python standard library functions ported to Nim
RFCs - A repository for your Nim proposals.
Datamancer - A dataframe library with a dplyr like API