> why "Projects like Nim and D can never be failures"? I've explained that point. At very least they brought value to the thousands of programmers that used them, but that's just one aspect of their achievement.
D (since 2001) and Nim popularized the idea that a language can come close to the execution speed of C/C++ while giving programmers a ton of benefits like better developer productivity, a much better syntax (ex. [UFCS](https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax)), metaprogramming, modern library / module management, faster compile times, etc. Some of those ideas have made it back into C++ enhancement proposals, as well as newer languages (ex. Swift). This is how progress often happens in the world of free software: experimental innovations often start in less popular projects and spread to more popular ones if successful. OpenBSD and FreeBSD pioneered many security innovations that only later made it to Linux. NetBSD was used to bootstrap the GCC toolchain to obscure platforms before Linux support caught up. Etc. > what is the common between them? * Both compile to lean native binaries (unlike the majority of languages, which are either interpreted or executed on top of a VM). * They come [close to the speed of C](https://github.com/kostya/benchmarks) even with GC. And they can [replace C](https://dlang.org/spec/betterc.html) with manual memory management. * When I look through examples on Rosetta Code, I usually find that D and Nim are the only statically typed languages that don't make my eyes bleed. 🤮 * They are also 100% free and [legally unencumbered](http://copyfree.org) (ex. unlike Java, Ada, Delphi). They're also grass-roots projects; not advertising campaigns for Google (Go, Dart), Microsoft (.NET, TypeScript), Apple (Swift), etc. * Both Nim and D have multiple compiler backends. With Nim you can choose any C compiler backend, plus there's [NLVM](https://github.com/arnetheduck/nlvm). With D there's dmd, ldc (LLVM), and gdc (GCC). * * * > what do you think about redlang [Red/System](https://static.red-lang.org/red-system-specs.html) is interesting. I do like [the syntax](http://rosettacode.org/wiki/Category:Red). Cdecl FFI seems pretty easy. But in many ways it's not in the same league as Nim and D: * **Libraries:** Red doesn't have an organized [module ecosystem](http://www.modulecounts.com). I couldn't find things as simple as PostgreSQL support. GitHub has total_count of [280](https://api.github.com/search/repositories?q=language:red) Red projects, compared to [3,115](https://api.github.com/search/repositories?q=language:nim) for Nim / [10,325](https://api.github.com/search/repositories?q=language:d) for D. * **Performance:** I can't find Red/System included in any benchmarks with Nim or D, which is quite telling. It also doesn't seem to have a [competitive Web framework](https://www.techempower.com/benchmarks/). * **Portability:** Nim one of the most portable languages imaginable (though I can't vouch for the stdlib), easily including every living Unix (ex. [F](https://www.freshports.org/lang/nim)/[O](http://openports.se/lang/nim)/[N](http://pkgsrc.se/lang/nim)/[DF](https://github.com/DragonFlyBSD/DPorts/tree/master/lang/nim) BSD, [Darwin](https://pkgsrc.joyent.com/packages/Darwin/trunk/x86_64/All/nim-0.19.0.tgz), Solaris, AIX), [HaikuOS](https://github.com/haikuports/haikuports/tree/master/dev-lang/nim), etc. This means you can write a tool in Nim, and people will be able to `nimble install` it anywhere, including new / experimental / future OSes / microprocessors. D is behind in ports, but its [inclusion in GCC](https://pkgs.org/download/gdc) means very broad architecture support. Red only supports [12](https://github.com/red/red/blob/master/usage.txt) OS/CPU architecture combinations. It requires i386 binaries even on 64-bit Linux, and isn't included in ports for any more exotic OS. * **Static Binaries:** Red/System is indeed a very lean execution environment, but it doesn't seem to support static binaries (as far as I can immediately tell). A "Hello World" binary is lean, but depends on 2+ MB of i386 .so's.
