We can't use Nim at my organization as the binaries it generates are detected as viruses and deleted by CrowdStrike Falcon when I attempt to execute them and results in a visit from our security team. I uploaded one of my binaries to Total Virus for inspection and several AV products mark it as malicious. This was with Nim verson 1.6.2. I created an issue but it was promptly closed as there was already open 6+ month old issue about this. I know it's not the project's fault and that the AV companies need to resolve this, but if this is not resolved it's going to severely limit the viability of Nim, especially in larger companies. I want to use Nim to build tools, but can't until this is resolved.
I don't think there is anything for Nim people todo. Anti virus companies run a very simple algorithm, they flag everything they have not seen before...
At this point anti virus companies are the virus, slowing down peoples computers, mining bitcoin, false advertising, hard to cancel payments etc...
Alternatively, you could tell the security team it is a false positive, and they can, mark it and report it as such to their vendor. Or the company could stop using a defective security tool.
It's interesting. How does one exactly address this? If anyone knows I'm genuinely curious since this seems horrible.
(Snark time) Is there someone that gets paid for protection? Maybe a "contribution" to security research efforts at one of these places? Or is there just an "I'm not a virus" flag Nim is forgetting to set.
AV vendors have points of contact to report false positives. They don't always respond quickly, but they're not brick walls. Reliable FPs from a specific toolchain seems like something their team would be especially interested in solving. CrowdStrike's reporting point is an email address on their contact page: https://www.crowdstrike.com/contact-us/
Ok I sent an email report explaining the issue with additional info. Let's see what happens.
Edit: Got a reply:
> Thank you for contacting CrowdStrike’s public AV scanner team! If you have not done so yet, please upload a sample of the file in question to Hybrid Analysis at https://www.hybrid-analysis.com/. Furthermore, please make sure that your request contains the SHA256 hash of the file.
I look forward to them no longer flagging one specific Nim binary produced just as an example.
Try adding debug symbols or make a fatter binary. Nim (and to a lesser extent Zig) has an emphasis on producing tiny binaries. I suspect some of the same optimization outputs matches the signatures of malware (which often is written in heavily optimised code).
I realize you are trying to help, but I find this to be a very depressing suggestion. "Make things worse". Fortunately I do not need to care about people captured by these anti-virus cartel members so I will not do this.
Same here, I can use nim.exe on desktop, but nimble.exe is killed SentinelOne. It works on Linux machines. Before they were deleting everything named bash.exe (not anymore).
I played with Nim a little, and it's a great language.
The things that were difficult were 1) Remembering which objects were initialized with "newThing" and which needed "initThing," 2) I never quite figured out what the restrictions on writing an "iterator" are and why, and 3) It's not clear whether a uniform error/exception handling approach has been figured out. I'm also not a fan of canonicalizing variables so you can write them any way you want to, since it harms grepping and the consistency of code.
Otherwise, the language was really enjoyable, and code tends to be both surprisingly terse while remaining readable, and fast to compile and run. Being able to turn the GC off is a pretty cool feature, and I love the default "result" variable in functions.
Right now it feels like a "better Go," but I always watch any language that gives me hope that I will someday stop having to use C++.
> I'm also not a fan of canonicalizing variables so you can write them any way you want to, since it harms grepping and the consistency of code.
Perhaps surprisingly, the opposite is true. You can enforce a style and a library that uses another style doesn't pollute yours and mix it all over the place.
There's also `nimgrep` (never needed this in >5 years on this language), or `nimpretty` to normalise styles.
> someday stop having to use C++
Nim can compile to C++ so you get ABI compatibility, and control over performance should be just as fine tuned. Nim should be able to run at the same speed as C/C++ since they both offer the same level of hardware access and portability. Depending on your needs it should be possible.
> code tends to be both surprisingly terse while remaining readable, and fast to compile and run.
This is one of Nim's most powerful features. Easy to read productivity. Prototypes end up being good enough, and it's got the teeth when you need them.
The language default is 'fast and safe', all the fancy stuff is opt in when you need it. E.g., variables are put on the stack by default, heap GC is attached to the type rather than instance (static lifetime + RC/optional cycle collector). Variables are initialised to zero, but there's `{.noInit.}`, access raw pointers but with strong typing and construct/destroy hooks, and so on.
Then there's the god-tier metaprogramming that lets you have optimisations that would be impossibly onerous to write, let alone maintain, manually, and give them the sweetest syntax you like. Full compile time VM in the native language, and type safe AST macros. Just standard Nim code, processing syntax trees with the standard library, say, outputting a framework from some data in a file, or providing a deep learning DSL that generates code for optimised matrix operations. It's like going from 1D to 2D.
It’s funny, I totally forget the name canonicalization is there. Compared to the nightmarish and completely unreadable nature of C++ template libraries it’s really a non-issue.
But as @arc776 it’s actually handy for making your code based more consistent. Python was always a bit of a pain where different libraries would be either snake or camel case causing your code to have a weird mix.
One of the most surprising things about the survey is that in the editors section, they didn't have anyone using QtCreator, it has had support for Nim for a few years now. It is experimental, but it has worked well for me.
Nim is very attractive to a previous CoffeeScript user like me. I used it to build my own [ClojureScript clone](http://calcit-lang.org/), but finally found I really want ADT and pattern matching, which drove my to Rust.
Object variants could support this need. But I was already amazed by those Haskell features.
> I really want ADT and pattern matching
I feel like many people go to the Rust bandwagon for the wrong reasons while mosts would benefit more from a higher level and more expressive language such as scala 3
Not much, I would say. Something important in CoffeeScript is "everything is an expression". That was a feature in Lisps, in Haskell, in Rust, but would never be default behavior for JavaScript. JavaScript is becoming less odd with modern features, but still far from being liked.
a bad aspect of CoffeeScript I see is "it's not an industry language". too flexible, insufficient integrations with standard tools, slow fixes and new features. The industry definitely need as lot of features for pushing and also controlling work.
CoffeeScript's syntax make a lot more sense than ES6, and CoffeeScript 2 compiles down to ES6 primitives. It's a shame that it's usage is pretty low in the industry.
Having a single Result type as standard has a huge benefit. You can do error handling for every library you use in exactly the same way. You also get decent stack traces because the runtime can reason about a single error type. Unified error handling is, IMO, necessary for making a language a pleasant experience.
Is it Rust's static lifetime constraints? Is there some feature you would miss if you used Nim instead? Or would you prefer to use Rust because more organisations are using it?
It's interesting to know what the perceived weaknesses and strengths are. Nim does have pattern matching but it's rarely used, whereas it seems to be used a lot in Rust (probably because of the prominence of enums). Nim has static lifetime management, but it's mainly used for eliding and thread safety (for now). Traits are an interesting feature, and make a good example of why I'm so bullish on Nim: someone has already replicated them with a macro: https://github.com/haxscramper/nimtraits
The popularity critical mass thing is mainly getting eyes on the language, but I think Nim has a slight advantage in that it's incredibly cooperative with its compile targets and FFI. Like Python, it's great for good glue code and 'scripting' without the performance penalty, and I hope that helps it meld into people's toolboxes over time.
Nim's concepts [0] are sort of like Rust's traits or Haskell's typeclasses - maybe more expressive in some ways. Pattern matching can be added on as a simple library and has been done several times, maybe most pedagogically outlined here [1]. Lifetime annotations just seem unproductive to me. Nim with ARC/ORC does have safe [2], automatic memory management without "a GC" or need for lifetime annotations.
Lel 1) JVM languages can compile to ELF binaries with GraalVM 2) lifetimes are an antifeature that is not needed outside of niche performance critical purposes. Moreover in the real world it's much easier to produce slower code in low level and non gc based languages. Btw I'm pretty sure SOTA latency critical GCs such as ZGC (<0.1ms max pause time) has outperformed non-gc memory management for latency critical workloads.
More importantly the jvm ecosystem has received order of magnitude more resources at optimisation for complex needs (drools,lucene, the whole Apache empire, etc)
Rust is a joke compared to Scala featureset.
I picked it up and played with it. I mostly liked what I found. I do web dev and the story there is less compelling than other languages if you're looking for something more than Jester. I may be misremembering, but even though the frameworks are async (some with that atrocious "{.async.}" pragma) the db libs were not.
I think Nim would really take off if there was a good and actively-maintained SDK for a major cloud provider, or even for one of the larger VPS sellers.
Thanks for making these, I actually had no idea these existed! I don't "need" them now but seeing these gives me ideas for projects and makes future things easier.
I wish discovery of community libraries was higher, I'm constantly discovering libraries that do amazing things 'hidden' away. I know there's https://nimble.directory/ and https://github.com/xflywind/awesome-nim but most of the time I end up using a search engine for something specific only if I think of it.
