Alright, then show me! For example, the beginner tutorial was linked a while ago (http://nim-lang.org/tut1.html) and I wouldn't criticize it at all, because it's well written, but it doesn't show me why I would care about Nim when there are dozens of languages I could choose instead.
It looks like Python, with a little more types.
Fwiw, I'm also a language geek and my favorite language is Factor. If I wanted to evangelize it, I could show how idiomatic Python or Haskell code translated to Factor takes up less than half or a third in size. So that's its USP (Unique Selling Point) -- really short code. What is Nim's USP?
Julia: "fresh approach to mathematical computing", Rust: "safe resource disposal without GC", Go: "C successor backed up by Google", Swift: "Replacement for Objective-C", Clojure: "Scheme on the JVM", Nim: "no idea what to write here"
Is it the Why should I be excited? paragraph: "Nim is the only language that leverages automated proof technology to perform a disjoint check for your parallel code. Working on disjoint data means no locking is required and yet data races are impossible" If I understood what the hell that means, maybe I would be excited. :)
Nim is like writing C at the speed of Python, and running Python at the speed of C.
If you took Python but made it perform blazingly fast, and made it suitable for the most demanding of embedded and systems programming applications, in addition to game dev, you'd get Nim.
If on the other hand you're satisfied with Python, then keep using it. It was trivial for me to port a Python elliptic curve implementation to Nim. I'd certainly recommend it over Cython, because Nim is simply designed as one complete system built for writing high performance applications with a sane syntax.
Statistics (on an x86_64 Intel Core2Quad Q9300):
Lang Time [ms] Memory [KB] Compile Time [ms] Compressed Code [B]
Nim 1400 1460 893 486
C++ 1478 2717 774 728
D 1518 2388 1614 669
Rust 1623 2632 6735 934
Java 1874 24428 812 778
OCaml 2384 4496 125 782
Go 3116 1664 596 618
Haskell 3329 5268 3002 1091
LuaJit 3857 2368 - 519
Lisp 8219 15876 1043 1007
Racket 8503 130284 24793 741
Thank's for the explanation! Then I know Nim isn't for me because "winning the benchmark game" isn't important to me -- even Python is fast enough for almost everything I write. But I understand why it is appealing to others.
Are there any other up-to-date benchmarks of Nim? In larger programs, performance is often dominated by allocating and garbage collecting memory. It would be interesting to know if Nim performs as well in that discipline as in raw number crunching.
The reason I use Nim is because it is a compiled Python with static types, generics and very powerful macros.
When I say "powerful macros" I really do mean it. I wrote what is essentially the equivalent of C# async await using only Nim's powerful metaprogramming.
For me the big selling point is being able to do so many things at compile time. Stuff like
const lookupTable = veryComplicatedFunctionCall()
or letting you declare types differently depending on compile time specifications. And then there's the macro system which I haven't really used but seems pretty nice.
So maybe "C with a macro system that's safe and does everything you always wanted it to do"?
As someone who does a lot of work on microcontrollers where there's no filesystem to read in configurations from and where small binary sizes count this is all very exciting for me.
I am excited about Nim because it compiles to C that can run on an ARM microcontroller. I believe this was a possibility at some point, but I don't know if this is a priority for Araq. So (personally) I see it as a (potential) "C replacement for embedded systems".
I like this use case. I've had the misfortune of trying to cross compile Python for ARM. It's very difficult, because the build process runs the freshly compiled python executable. This obviously doesn't work when you are compiling an ARM executable on an x86 machine. The answer for us was to use Scratchbox [0]. This let us run the compilation on an emulated ARM machine.
In case anyone is wondering: The actual platform was Chumby [1], and Python ran great on it. We had a little twisted [2] application that displayed images and played sound. To display the images we just wrote an image file (after using PIL to manipulate it) to /dev/fb. It was really fun! I just double checked the hardware the chumby: A 350 MHZ ARM9 processor with 64 megabytes of SDRAM. It sounds a little crazy to me now to think of transforming images using PIL in 64 megabytes of ram, but it actually worked quite well.
You copy the nimbase.h file along with the nimcache/*.c files. That's it. The compiler doesn't do it because it's a waste of time/space copying a file which you most likely can include from somewhere else, and it's not a generated file.
Good to know. It would be nice if there was an option for the compiler to build a single .c file that was totally self-contained, for distribution purposes.
I don't know anybody who redistributes source code as a single C file, but you could try concatenating the files into one. Usually people redistributing source code don't mind having several files bound together by some make|build script. The nim compiler has the --genScript switch to make one. Most people willing to get something redistributable prefer a binary static|dynamic library or final executable.
> Usually people redistributing source code don't mind having several files bound together by some make|build script.
A single .c file is easier to integrate into various build systems. For example a Visual Studio project, or another Makefile without needing a separate script. It's just cleaner.
> Most people willing to get something redistributable prefer a binary static|dynamic library or final executable.
That's truly exciting. I wonder how well it'd run on Altera Nios 2 with, say, 16 kB of RAM. If Nim works well for that case, I'll start to use it yesterday!
Nim compiles down to C and can produce code to run directly on bare metal. My understanding is that Go and Rust (to a lesser degree) require a runtime. Perhaps someone with better knowledge of all three languages could chime in.
Rust's runtime has been reduced to bounds-checking of array access, IIRC. So to a much lesser degree, and I believe Nim also provides this behavior by default.
Go is garbage collected and has an opinionated ABI and runtime. Completely different beasts.
Rust has been used to write code that runs on bare metal too. Typically, this is done by using #![no_std], since the standard library depends on things like jemalloc and libc stuff. Everything that doesn't depend on these is in libcore.
Put that up, and allow integrate CPython 2.7 into Nim's output binaries for use of interfacing with Python2 libraries through Nim code... and you have yourself a serious contender for picking off many Python refugees and some serious traction within industry too.
That's a good point. One could try "faster, safer Python" here, but I agree that it should be discussed and made official, so that anyone seeing Nim's homepage would immediately know what it's about.
Nim fixes those while keeping things which attract people to Python in the first place. It should be enough of a selling point.
I write most of my code in C + Python (and sometimes in Python + C). For me Nim ticks all the boxes, even the minor ones (how syntax looks etc.). I can't wait to give it a try once I am done with my current project.
Exactly. This is why I mostly agree with the comment which said that Nim should be advertised directly to Python programmers. Pythonistas have a hard time finding a language which would be faster, lower-level but still elegant, simple and expressive - and Nim is a solid candidate here. It's not 100% aligned with Python design, but it's much more similar to Python than Go is.
As an engineer I would be persuaded by a) implementing something practical but simple simply, b) implementing something a bit more complex legibly and c) writing about the results which explain why they are neat.
The killer promoter is of course a book.
I usually wait before starting on new languages so I'm not slowed down by incomplete tooling, missing compiler features etc.
What really gets me going is a 1-2-3 tutorial which explains how to implement something non-trivial like calling c dlls.
Learning the syntax/features of the language should be part of documentation, not a tutorial.
"Hello World" as the core/intro example with nothing else after that (or trivial command-line programs) will not get many adopters.
Show people how to build REST APIs, GUI programs (like a text editor), a small web-server and maybe some other scientific/math example.
Showing just a few features and then saying "go build" will not get normal people to adopt the language. Only "savants" will pick it up.
Give examples/libraries and people will build on those.
The syntax is also not that close to Python. It is obscure in some places and not as readable. If you're going to compare it to Python, do a readability test:
Write the exact same application in Python and Nim and then ask somebody else to compare the 2.
I tried to pick up Nim, but I was fighting against it every time I tried to go beyond a trivial CLI program.
I'll take Pythons slower implementation with 3000 libraries over Nims "C-like" speed where I can't even build a REST API.
I like Nim, but if all the effort of promoters is just promotion, the language will stay where it is.
You geniuses working on Nim for a long time need to share your examples and show the noobs how you built things with decent screencasts/tutorials/lessons.
Something tells me that even just 3 decent examples where real applications are built (eg. a game like Snake using a GUI and game-engine/lib) will get +1000 Youtube hits in no time.
Nim is very, very close to being the most competitive language in my toolkit. If JSON were handled more elegantly, like Python, I'd probably be completely sold.
Binding to Python would also be an absolutely killer feature.
> Lacks reliable independent secondary sources to establish notability as required by WP:GNG. Every source is WP:PRIMARY. Every one of them. Googling turned up posts to online discussion forums but nothing useful. Additionally, I note that the decision to delete at the previous AfD was unanimous for the same reasons.
> Perhaps think of it this way: a language becomes notable when people who haven't been involved in its creation start writing about it. If/when this language gets to that point you'll have no problem creating an article. At the moment, though, there just hasn't been enough uptake to get the coverage we need for notability.
An aesthetically nice website is a neutral or a negative signal when it comes to technical subjects, like computer languages. Content first, graphical design is completely secondary.
Just need to represent information about the technical subject clearly.
If the technical merits are there, adopters will come. Technical people are not baffled by $animal . $excrement. Instead, it puts them off.
Edit: I get downvoted a lot, but could someone prove me wrong? What technical concepts (like programming languages) got popular with help of nice graphical design?
That kind of thinking will only prevent adoption, not help it.
Aesthetics are important to technical subjects as well. It shows that a lot of time and consideration have gone into every part of the project, not just the technical side. It's also a good sign of community support/interaction. I will agree that content is the most important, but you shouldn't write off aesthetics so easily, especially when you want people to be interested and adopt your technology.
Try to google some popular languages. Use http://archive.org/ to see how their respective pages looked like in the past. I find it hard to believe aesthetics helped their adoption.
Interesting article, related to web design and conversion rate:
Popularity being based on the Rails 2.0 release since that's when Ruby/Rails seemingly started to take off. It's a bit before my time so if anyone knows better feel free to correct me.
It looked pretty good when I saw it for the first time today. Told me what it is about concisely. I don't see how a better design could significantly improve Nim's adoption.
Edit: I did completely miss the carousel at top of the Nim main page. I think it'd work better, if it was just serially on the page instead of the widget. Same content, less "design".
You're missing the entire point. If they had a better design it would probably interest people more, pertinent information would be more visible, and it wouldn't look like it came out of 2002.
This is pretty much the "sales" page for Nim and it looks outdated and unmaintained. For comparison check out the Rust homepage. It's not "flashy" but it's simple and looks fairly nice. It gives you a simple example and tells you why you should be using Rust in as few words as possible.
All of those languages/tools show that the community/devs care about how they and their language look to others/potential adopters. I'm not saying that having a great site design (not graphical design, that's different) are going to make Nim the most popular language on the planet. I'm suggesting that it can, and will help if they move forward and pick up a more modern design and simplify the content to get their point across.
I don't understand why Python comparisons are being thrown around here. From my limited experience with Nim (I liked the name Nimrod better, but oh well), it seemed a lot more Wirthian than it did Pythonesque. And of course: AST macros.
Nim is relatively immature and I would expect you will spend time fighting the FFI. I mean, PyQt is wonderful, brilliant, possibly the best GUI toolkit I've ever used anywhere, and very mature and backed by a company that does nothing else - but I still spent time fighting the FFI.
If you want to play around with the language then great, but I suspect you'll spend more time running into bugs than writing your actual program. Which may be fine; certainly it'll be a learning experience.
Writing Qt-flavored C++ was a lot of fun last I tried it (some five years ago). And now there's QML. Have you tried writing your entire project in Qt? It may be a smoother experience than you think.
I have some experience using C++ with both Qt and wxWidgets, but I am looking for an excuse to learn something new. And a systems language with Python inspired syntax and comparable expressiveness that is suitable for creating GUI apps is something that would definitely make me want to investigate Nim further.
Thank you for the link, but I can reasonably expect that Qt bindings for Nim either exist or will become available soon, as most languages that get any traction get them. I still don't know, however, if it's a good choice to try and put a GUI app together in Nim. Will it surprise me with a huge binary, like Rust does? [1] Will it be easy to develop in it on multiple platforms? I can find all those things myself, but in the spirit of what the OP describes as putting the best foot forward, I'd like to be able to quickly assess whether the language is potentially a better choice to solve my next problem than those I already know or am planning to learn.
Having seen multiple young open source projects, like Nim, play themselves out over the course of my many years in the Bitcoin space, I expect the savviest developers at this point to benefit most from Nim by establishing themselves as core contributors.
The devs who got into Bitcoin on the ground floor in 2011 and 2012 are three years later on the most sought after venture backed teams, with the whole world hanging onto their every last word. Young and profoundly promising languages like Nim offer a similar opportunity if you're willing to risk it.
It could very well be better to use the myriad of other, more mature and stable languages to solve truly pressing issues. Nim is very young, and the risk:reward ratio is skewed more towards contributors than users who can't risk bugs.
I find it disturbing that languages are now adopting promotion strategies because not enough people are using them.
For fuck's sake, focus on improving the language and this will come organically. This isn't a competition as to who has the most popular language, and the most popular languages are always going to be total shit.
Just write good code, marketing departments are the bane of the entire IT sphere, you shouldn't be trying to create one for a niche language.
> focus on improving the language and this will come organically
Or not. There are dozens of languages which are good, a couple of decades old, and only known and used by a very small community. They all followed your advice and in effect they "lost" man-centuries of contributions to other languages.
I don't know how well this is going to play out for Nim, but for a project which can't even have its own Wiki page because of how unpopular it is it may well be a good thing.
>For fuck's sake, focus on improving the language and this will come organically.
I don't have statistics to back it up but I would wager that waiting for users to come organically is among the top reasons software projects of any kind fail. Why should programming languages be special in this way?
For better or worse human beings are creatures who like to categorise things. This is how we deal with complexity, even if the categories are not always optimally chosen. Marketing departments inevitably start off with pushing a category for a product and suggesting this is it's "best at" or indeed "only option" angle. This allows we category seeking beings to remember it better, and indeed, provides a secure "beachhead", even if very specific, which the product (~language) can dominate and from which it can credibly grow. Nim does not seem to have this beachhead, and basically is therefore diluted across categories and is harder to remember. I therefore agree with the original post that Nim does not have unique selling point if you will.
Separately, "marketing" is of course a term loaded with negatives, but it is essentially about communicating a benefit in a very crowded and competitive environment. That benefit has to be very clearly enunciated and pushed, and if it is a clear and simple message, then it will be effective.
It's a secondary concern that a language is a polyglot at all sorts of use cases, is good at everything. It first has to have users. Users have lots of choice so you're best off giving a small subset of them the idea that this is the perfect tool for their specific use case, and grow from there, than telling everyone this is good at everything, even if that is true.
Unfortunately the best all rounder is often forgotten if she/he's not number one at something.
TL;DR: In a crowded and complex marketplace marketing's segmentation methods are unfortunately needed.
That's not true. Being the first few people means that the tools are not developed, common questions aren't answered, books aren't written, getting help is difficult, etc.
There are only 18 questions on StackOverFlow, for example:
The fact that there are only 18 questions on StackOverflow could also mean that the language is that good that rarely you find something requiring further explanation. Or maybe Nim users use the Nim forum instead for questions (http://forum.nim-lang.org), where finding a C forum or Python forum is not that easy/direct.
Most of these suggestions are about how to make Nim more immediately useful to people, e.g. by being more focussed, making sure important libraries are well-optimised, etc.
I think it's really good that they're asking, "why aren't more people using our language?". That seems like a great step towards improving it.
As reasonable as that is, "if you build it, they will come", is a myth. Say you have an excellent product, and I would absolutely say Nim is excellent. With priority #1 out of the way, you have to speak up for yourself.
It looks like Python, with a little more types.
Fwiw, I'm also a language geek and my favorite language is Factor. If I wanted to evangelize it, I could show how idiomatic Python or Haskell code translated to Factor takes up less than half or a third in size. So that's its USP (Unique Selling Point) -- really short code. What is Nim's USP?
Julia: "fresh approach to mathematical computing", Rust: "safe resource disposal without GC", Go: "C successor backed up by Google", Swift: "Replacement for Objective-C", Clojure: "Scheme on the JVM", Nim: "no idea what to write here"
Is it the Why should I be excited? paragraph: "Nim is the only language that leverages automated proof technology to perform a disjoint check for your parallel code. Working on disjoint data means no locking is required and yet data races are impossible" If I understood what the hell that means, maybe I would be excited. :)