For all those who are really interested in the language and have at least a small amount of experience with it already: Nim is ripe for contributing!
While the main team works on bigger things drawing v2 closer, there's still lots of issues of various magnitude and lots of housekeeping bits that can be done while getting yourself acquainted with the project's structure.
Hi, is Nim a good replacement for python? I write a lot of scripts, but I find that python can get cumbersome to maintain. I'm looking for something with stricter typing and a sane packaging/directory system, but also easy/fast to write. If Nim can work with numpy it's a plus
I think out of the bunch of new system programming languages it sure is the most friendly towards users coming from dynamic programming languages.
My nim solutions were actually more concise than my JS code when doing some Advent Of Code puzzles.
And it has nimpy which is a bridge to the Python world though I haven't used it personally.
The only downside I can think of regarding nim is that the standard library is OK-ish I guess but not great. Still needs some work but I think they are aware of it.
yes, definitely for me nim has replaced python as my go to language even for small tasks.
I find it even more productive than python thanks to the typing system. An often neglected highlight that I appreciate a lot is the fact that static typing + procedure overload has the additional benefit that names of functions tend to be very natural (you can reuse the name of function if the type signature is different). That along with UFCS (universal function call syntax), allows to create great apis in no times. Also template are a very easy way to boost productivity and allow to write great DSLs. See also an old but still relevant and very valid introduction of Nim for Python programmers [0]
It can work with numpy and even better there is a performant numpy replacement called arraymancer. Take into account that since you do not need to be afraid of loops, even working with standard sequences is very performant. See also the SciNim getting started book [1]
Well it depends a bit on your usecases. Nim certainly has a stricter type system, and since it is compiled you can be fairly certain that a program you have compiled won't suddenly start to misbehave (e.g. no JavaScript leftpad issue since it won't pull in libraries on runtime). The packaging system is fine for most purposes, and it recently got better with the introduction of lock-files. Once you get comfortable with the standard library and your favorite packages it's also very fast to write, maybe even more so than Python because it has less boilerplate.
As for numpy there are libraries that allow you to work with Python from Nim, and vice-versa. Not entirely sure how well they work for numpy as I haven't tried that myself. But there are also packages which does similar things in Nim. However packages will probably be your biggest hurdle when converting stuff to Nim. The Nim ecosystem is definitely smaller than Pythons, so it's a bit hit-or-miss if it has the packages you need for your specific usecases. You are more than welcome to join the Discord/IRC/Matrix room and ask around though.
For me it was. Python was everything for me - but too slow. It was a pretty quick to convert software to Nim, and I have never looked back. You don't get the whole ecosystem from python, but you get fast code and easy syntax. We even often use Nim instead of small shell scripting.
Nim goes further there by removing the need for tools like Pandas and numpy. You don't have to write code in "Pandas-style" because native Nim is equally fast and sometimes faster.
> Nim goes further there by removing the need for tools like Pandas and numpy. You don't have to write code in "Pandas-style" because native Nim is equally fast and sometimes faster.
Can you clarify this? Is there an equivalent data stack in Nim? Or is it that nim is lighter-weight because, for example, it permits transforming tabular data into language structures natively (i.e., without library support)?
This issue alone means I can't use it at work, and I haven't put much time and thought into Nim as a whole because I could only use it in private toy projects.
I understand it's mostly the AV vendors fault and the devs shouldn't have to worry about a problem they haven't caused, but for me, this grinds real-life adoption of the whole thing to a halt.
It's not clear to me what they could do. In the thread you linked, it's not just the binaries of the various nim executables, but also user generated binaries. And it appears that even signed binaries are getting flagged by some vendors.
I'm guessing the issue is that some malware writers started using nim, and the antivirus vendors then decided to make heuristics that detect nim generated binaries and call it malware.
This is pretty much it, malware was written in Nim, vendors started fingerprinting those binaries but didn't include any/enough non-malware binaries. This means that the fingerprint is more "this program is written in Nim" and less "this is malware written in Nim".
Yes, but it's not like this only happens with small/new languages. Even today, Go-lang binaries will often get detected by various Windows anti-malware software. They even have a section in their FAQ about it [0].
Also, in Hare's specific case, it doesn't _really_ matter as they will never support Windows or MacOS [1], and there isn't a significant presence of anti-malware software on linux distros.
Not supporting Mac is a big shot in the foot from Hare. Is this a case of ideology getting in the way of pragmatism, or do they have technical reasons? Singling out proprietary platforms sounds ideological.
"As other commenters alluded to, it's an ideological and practical decision. We simply prefer free software operating systems. We do not care to legitimize nonfree platforms, and we prefer to be able to read (and patch) the code to understand the tools we depend on. If that's a deal-breaker for you, no worries - Hare does not have to appeal to everyone to achieve its goals."
Hard to say, since we have no idea how the antivirus vendors are identifying nim. Maybe there's something about the fact that nim compiles to C which is then usually compiled by mingw? (You can use compilers other than mingw, but it's the default).
Mingw might have a higher weight for "this is malware". Then you combine that with nim generating code that's common across most nim binaries (the GC, boilerplate symbols, etc).
Then there's perhaps not enough positive signals to offset that, since there's not yet a wildly popular windows app written in nim.
I hope I didn't come off as too aggressive in my original post, I'm not trying to demand anything, or trying to act like I know anything they don't, I most certainly do not. I just love the language so much, I wish I could use it more. The linked issue doesn't show any traction, and other languages used for malware don't have this problem, so I (probably incorrectly) presumed there was a lack of interest to solve this. I apologize if I came off as demanding.
They have to work with and stay on antivirus vendors more aggressively. You can take new releases and submit them to the antivirus companies to get white-listed.
They each have their own processes, but a lot of them allow going to their website and submitting as false-positives, then you can do follow up e-mails.
Probably best to select the top 10 AV companies, to keep the workload down. Per each release, shouldn't be too bad, though likely someone or a group needs to be designated for the task.
We take it very seriously, but there isn't a whole lot we can do unfortunately. Apart from reporting false positives the only venue we could pursue is applying obfuscation practices used by actual viruses. This of course has its own slew of issues.
Yep, I mean, if the virus defence community took the same blanket, lazy approach with C and C++ compilers because viruses can be written in those, too (shock horror!) they'd be shutdown by some big players very fast.
There is trade offs to both sensitivity and insensitivity. Just because you are used to one approach from your favorite programming language does not mean the other way is "wrong".
Want a consistent style? Use that nice --styleCheck:usages option. No problem at all.
Honestly, I think Nim should keep the current approach just to filter out certain people.
What are the arguments for insensitivity? I'm not used to it, and it seems to my rookie eyes that it only opens venues for confusion (forcing to pay closer attention to symbols to mentally "de duplicate" them), inconsistencies within a same/foreign code base that make joining a project/jumping into an external library just slightly harder, and more vim/emacs/tab/spaces jihads.
The main advantage is that you can follow a consistent style in your codebase even if your dependencies follow a different style, so you don't have a situation like in Python where if you use the unittest module, you're forced into not following PEP8.
It actually is something that gives me pause for thought. In my field of coding (finance) ambiguity is terrifying and eventually you get it wrong.
Maybe it's not so bad in practice, but looking from the outside, I think... really? To be specific, case-insensitivity doesn't bother me, but the automatic conversion from camel-case to snake-case... very much so.
You must remember that Nim is a statically typed compiled language with support for distinct types etc. This means that you wouldn't be able to call the wrong procedure if you didn't provide it the right types. Besides, not allowing similarly named but differently cased identifiers causes less ambiguity, not more.
I mean, it really might be fine. I've written maybe 20 lines of Nim in my life, what do I know.
I just look at it and see a foot and a gun pointing at it. The arguments for it sound to me like "it's fine, there's a safety and a clever mechanism that prevents shooting yourself in the foot".
Maybe it's all fine, but I'd for one feel more comfortable if the gun wasn't pointing at the foot in the first place.
This is an interesting take, I do see the value. If I was trying to prevent this type of aliasing, I'd have the compiler throw an error if there were two aliased variables names (xyz and XYZ for example), rather than merging them automatically.
Since Nim is statically typed you can't simply create a new variable with the same name as an existing one without errors. You can shadow variables in a deeper scope, but then only the latest version is available. Defining a function xyz and then trying to define another function xyZ is indeed an error.
Are you confusing syntax with semantics? Your hesitance seems to come from
intuition and it's not uncommon for intuition to make mistakes like that.
Having a single syntax with multiple semantic meanings would indeed be a foot
gun.
I can't think of a way how different syntax translating to a single semantic
meaning could cause any concern. It's not like the wrong thing can happen, it
just might look differently depending on codebase.
Yeah I can see how it might seem scary. It takes you out of your comfort zone and it's easy to start thinking uncomfortable things have to be scary. I've been using Nim for a couple of years now, and I've never run into a safety issue with it.
Reading through the GitHub issue, it seems like the one place it makes sense in my eyes is that you can refer to stuff in external libraries with your convention even if the library uses a different one. I'm not sure if there's something I'm not thinking of, but to me it'd make sense if the library boundary was the only place it let you do it.
I love Nim and wish it would take off and become as common as python. Case sensitivity isn't affecting that for me. But it still really irks me.
There are times when you might want to use the same variables in different cases (math), and the assumption that you wouldn't seems like nannying to me.
Also, fundamentally, it's a very english-centric view and encourages that by default. I'd prefer case assumptions weren't implicitly baked into the language at a basic level.
I guess for me I just feel like a character is a character and I don't want the language telling me I should view it differently.
The nice thing about being able to run others people code with your style is that your entire codebase stays in one consistent style. You don't run into issues like in other languages where one library author has done some dubious style choices which then propagates into your code. This was always a pain-point for me in Python.
And I'm not certain what scenarios you envisage where this would be an issue, why do you care how other people call your functions?
Dubious decisions in third-party libraries are common, but camel vs. snake case is probably not the main...
I care about how a function is called because so much tooling around programming is effectively grep. I can grep for a function name and get a pretty good idea where it is called. There's also a million variants of grep - git grep, unholy regular expressions (recently I used one to find all instances where foo is called with exactly 2, not 3 params, in Python), IDE plugins and so on. GitHub search? Google search for exceptions?
IIRC Nim comes with some kind of "nim-grep" that is camel-vs-snake-aware, but that doesn't fix all the other tools.
The minor gripe, additionally, is that you often have quasi-singleton classes called "FooManager", then a single instance called "foo_manager". Now... are these colliding? Or not, because the first letter _is_ case-sensitive? What does "fooManager" map to then?
In my utility function, this feature gives me nothing but concerns. But then again, I'm not (yet?) a user the Nim community provides for so... <meh>
> you often have quasi-singleton classes called "FooManager", then a single instance called "foo_manager".
Like this:
type FooManager = object
var foo_manager: FooManager
> Now... are these colliding? Or not, because the first letter _is_ case-sensitive?
Well as you correctly reason, the first letter's case distinguishes them.
Convention in the language is for types to start with a capital letter and instances start with a lower case letter.
> What does "fooManager" map to then?
It maps to the `foo_manager` instance because underscores are ignored, they're just for you. By the way, underscores are exceedingly rarely used in Nim code because they're not semantically significant, why bother.
Still, if you like you can use them in your code, and others can choose not to as they want. Clashing identifiers are a compile error so no worries.
> other people's code can, refer to the same thing by different names
They can but the compiler will just tell you it's ambiguous and to qualify it. Also bear in mind Nim has very strong static typing, so for things to clash they also have to have exactly the same type, otherwise no worries.
You can even rename symbols on import or force qualification for all symbols, but I've never needed to do either in years of heavily using the language.
> the automatic conversion from camel-case to snake-case... very much so.
If an identifier clashes, you get a compile time ambiguity error. It means `is_OK` and `isOk` will report ambiguous identifiers and force you to qualify it or rename it.
This also helps further reduce ambiguity indirectly by forcing sensible naming.
As a frequent Nim user, I've tried it a few times and it doesn't seem to do much, other than reflow lines in not very logical places. I'd prefer an uncompromising formatter like Black/Prettier/StyLua.
My ideal would be to simply not allow having my_variable and myVariable in the same namespace but given that you can do that in essentially every language I sort of prefer that they have to refer to the same thing.
If you define them both yes, but you're still free to use them both.
var my_var = 1
myVar += 1
echo(my_var)
Will happily compile and give you 2. I'd prefer an error in that case because while I'm not liable to make that mistake but I could easily mistype long_variable_name as long_variablename without noticing and then cause myself problems when I try to grep.
Searching has never been a problem for me in years of using Nim but there is `nimgrep` bundled for style insensitive search. Also I'm no RE wiz, but seems like RE might help if it came down it.
Just to stress myself as an anecdote though, I have years in the language and it hasn't come up yet for me, and I've never needed to use `nimgrep`.
A bit off-topic, but I'd like to see a language à la rust+gc, with pattern matching, traits, and the functional stuff rust got right, but without all the worries of lifetimes, and maybe some easier trait management (function signatures become very ugly imo).
I've heard the claim that lean is going in this direction.
The ergonomics of both are more oriented towards functional programming rather than imperative. Rust is still primarily imperative with great APIs for functional programming.
It has great GC piggybacking on the huge amount of efforts going into dotnet, each release since dotnet core has just gotten faster and faster, not just GC but many parts of the ecosystem, see e.g. https://devblogs.microsoft.com/dotnet/performance-improvemen...
Function signatures are usually not needed due to the type inference algorithm, so while it is statically typed, you often don’t need to write out the types of functions.
Not just seamless, I want it to use rust libraries natively and basically be rust under the hood. Think coffeescript but for rust. The problem with most people's suggestions will be that it deviates too far from rust (giant VMs) and a new language would need a duplicate ecosystem.
I feel like this is an inevitability at this point. Kotlin is basically this, and C#/Java/Typescript are getting there, albeit with some historical baggage that might make it slightly less ergonomic.
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.
> many of the more senior community members or those who have been around for a bit have migrated there
It's true that compiler developers like krux, Clyybber, saem migrated to nimskull, I don't disagree.
> but there are only a handful of folks remaining that have been around for more than a year or two
But I totally disagree with your false statements about "senior" community members (those who don't do compiler development) migrating to nimskull - this is not true at all. There are a lot of "senior" people left in the Nim community.
And again, nimskull isn't a "silver bullet" either. It has the flexibility to change major things in the language just because it's a hard fork and almost no one (except people who develop it) uses it for real projects, whereas Nim has an actual userbase that doesn't want their code to be broken, especially considering the fact that nimskull has already removed a lot of the stdlib libraries, especially async (which there is no alternative to in Nimskull).
Most of the "senior" community members who have migrated to NimSkull are those who liked to work on the compiler. The ones who remains using Nim are those who like to write libraries and projects. I've yet to see anyone create a library or project with NimSkull, although that might be because I'm not too exposed to it. I would love to be proven wrong, but for the time being NimSkull looks like a good idea if they can pull it off. But currently it looks like ripping of the band-aid to get to a better place and currently it's still in the burning and stinging phase before things (hopefully) gets better.
I apologize if my sentiment came off as Nimskull is a realistic alternative for those who are frustrated with Nim - it certainly is not, and I think your description of the state of the project is spot on PMunch!
I guess your definition of senior and mine vary. I'd consider senior members anyone willing to work on the compiler, as they are the members with the potential to move the language forward and out of the mess it currently finds itself in.
Are there experienced programmers in the Nim community, sure? Are they able to fix Nim with Nim's leadership in place? Doubtful in my mind based on history.
Also, I apologize if it seemed like I was evangelizing Nimskull or suggesting folks switch to it. I agree it is in no shape to serve a replacement for Nim presently, and may not ever be.
Nothing here is untrue, but from my perspective it's overstated. I don't use discord, but I visit the forum daily, follow most of the RFCs, and spend a lot of time coding in Nim (https://github.com/dsrw/enu). I really like Nim, mostly like its community, and think many more people should be using it.
I'm sure fusion could have been handled better, and for 2021 the roadmap was a bit hazy, but I can't think of any other big missteps. Araq, dom, PMunch, and other senior folks are in the forms helping people and answering questions every day, and my interactions with all of them has been very positive. The big post 1.0 feature was arc/orc, and that was very well communicated. Bugs are being fixed, useful new features are being added, and future plans are being discussed in the open.
And Nim itself is great. The "if it compiles, it works" factor is high, yet I almost never feel like the compiler is fighting me. Simple things are simple (I'm teaching it to a group of 12 year olds), it's incredibly flexible, it's fast, and it's suitable for almost any sort of problem. There's nothing else like it, and I expect I'd continue using it for at least a decade even if it switched into maintenance mode tomorrow. I think it will take at least that long for something better to come along.
The compiler works until you stress the type system or try to take advantage of features that are experimental and then stay that way forever. How many iterations of concepts have we been through at this point? What happened to hot code reloading? Why do we have all these legacy GCs?
The point is the compiler has more and more cruft that makes it increasingly more complex and increasingly unreliable. It also makes it so that bugs are harder and harder to fix. Not to mention that it's basically impossible to track what is going on with the language at any given point in time because there is no roadmap or updated status. It also doesn't help that certain folks like to create ten GitHub issues and RFCs for every perceived slight in the language.
Once again, the problem boils down to a complete lack of leadership or interest in running the show - and instead of empowering the community to make that happen, leadership sits back and acts like everything is great and perfect and pats themselves on the back. When someone complains that it is not, leadership finds a way to defend itself and turn sentiment against the person complaining. It happens over and over again and it's why Nim isn't a success story like languages that actually have empowered communities and leaders that are interested in leading and not just collecting book revenues / making .io games, etc... while actively gatekeeping those who would like to get involved in making things better.
> unless you limittest generics, most people wont even encounter this.
I don't think my totally normal usage of generics for type safety could be called "stretching the limits." My usage of generics includes using a parameter [V] for OpenGL meshes to introduce type safety with the vertex type. I'm pretty sure that's perfectly normal?
Recently one of my friends tried compiling my project - pan[1] on Windows, and for whatever reason - it doesn't work! stating that it "cannot instantiate 'V'", whatever that means. I've had this error annoy me many times before, but I have no clue what triggers it or how to reproduce it reliably. Call this a 'stable implementation.'
I've run into the "cannot instantiate 'V'" somewhat regularly. Generally it means the compiler doesn't have enough info and defaults to trying to use `V` as a concrete type.
Generally it's not usually an issue with Nim's generics itself, but rather bad error message. Definitely an area for improvement IMHO. Though having used a fair bit of C++ templates over the years, I still find the Nim errors much more tractable after a bit of experience.
There _are_ a few broken limits of Nim's generics, but they are things pushing the type system to a limit.
I'm not sure there is one - but I guess a language where you're not constantly dealing with horrible error message, an under-specified and broken implementation and a shitty stdlib - might be better, even if it doesn't have some of the nicer frills of Nim.
Ye gods and little fishes, is there a new-ish language suitable for application programming, which has a more-or-less feature-complete design and implementation, and where there's no petty drama going on every other day? And which, to boot, lets you get a job done without requiring/strongly suggesting that you become a part of their vibrant community?
A have a sinking feeling such language exists and is called "C".
You know why I’m using the term, though. It’s a battering-ram-of-a-tongue-in-the-cheek. Each time I’m encouraged to engage in a community, it’s called vibrant for some reason.
It’s like the “incredible journey” term for companies that get swallowed whole by other companies, leaving their customers to dry.
This matches my experience with Nim community and it's toxic leadership. The amount of petty drama the community leaders get involved with is unbelievable. Spending a few weeks on their Discord, and observing how the leadership interacts with new/opposing ideas is enough to get a clear picture. It doesn't inspire trust.
Contrast this to, say, Zig, their road-maps and community structure is light years ahead.
What the heck man? This doesn't match my experience at all. And I can't find your username on neither matrix nor discord. Did you just found a chance for a sucker punch and took it? I bet Zig is the wonder land.
It does fit my experience and you'll find me as a lurker in the discord. Though I'm not surprised you haven't noticed this. The mod in question is a master in gaslighting. I'm not sure I would have noticed if I didn't have personal experience with this level of manipulation.
It's not a coincidence you see the same name pop up, every time someone gets bullied out of the discord.
But those who got banned didn't they ignored the warnings, continued flaming and insulted other users? Will you pretend that people who behave themselves get banned?
Oh, they absolutely ignored warnings and used rude insults. And if you were in their situation, you would have too.
Have you ever dealt with someone that constantly lies and misrepresents your opinions to make you look like a villain? Have ever gotten frustrated, because the person you're arguing with is constantly shifting the goalpost to their benefit? Have you ever said something needlessly rude out of frustration?
How would YOU react, if after dealing with all this disingenuous bs, YOU get told to watch your tone or you get banned for being toxic?
The justifications after a ban always make logical sense, true. But if you read through the logs with even a little bit of empathy, it becomes clear very quickly who the toxic person in those interactions is.
Edit: I'm not talking about a specific person getting banned. This happened numerous times, including newcomers.
I agree to some extend and that's why I believe bans should be lifted after 30minutes when people have calmed down. But on the other hand one should watch how he behaves and not blaming it on others.
dom96 simply needs to go - they are nothing but self-serving and they cause more damage to the Nim community than any other member by far.
I'm not even including the horrible software they've authored and cargo culted into the language's ecosystem and tooling. That should be enough of an offense to be removed from any decision-making role.
I haven't seen this at all, and am actually baffled that you're talking about dom. My experience of him has been the literal opposite.
He didn't cargo cult his software into the ecosystem. He made the ecosystem. Nimble is the package manager because there was no package manager until dom wrote one. Jester is the default web framework because it was first, and despite its age it's still pretty good. Same for choosenim. And asyncdispatch. And all of the other tools/libraries that he wrote.
Obviously writing some early software doesn't give him a free pass. I could understand the attitude if he was a jerk, but I've never seen him be anything but helpful.
I mean, I have experienced first-hand, dom96 being a jerk directly to me after I spent months of effort building something for the community. I'm not the only one either. If it was just dom96 being a jerk my criticisms might not hold water, but the problem is far deeper than that.
Try to advocate for replacing any of dom's tools / software packages and see what happens. Try to advocate for taking Nim in a direction counter to what dom perceives as the right one, even though they no longer contribute to the language anymore besides telling people to fix their broken software they're no longer willing to maintain, or to throw their weight around in RFCs / IRC.
You're proving my point. Any criticism must be an attack (e.g. suckerpunch in this case) and must be met with heckling and banning. Zig is no wonderland, but I haven't experienced things like the creator of the language personally engaging in almost every drama and banning community members.
Why am I not allowed to be suspicious, with a new account doing advertising for Zig while creating controversy? How about you provide more details, instead of throwing accusations?
While the main team works on bigger things drawing v2 closer, there's still lots of issues of various magnitude and lots of housekeeping bits that can be done while getting yourself acquainted with the project's structure.
Here's a few links for your consideration:
* https://github.com/nim-lang/Nim/issues?q=is%3Aissue+is%3Aope...
* https://dev.to/xflywind/best-ways-to-make-your-first-contrib...
* https://nim-lang.github.io/Nim/contributing.html