Hacker News Reader

Comment by themartorana | Hacker News Reader

All the hype on HN seems to be towards Rust and Go (with Go having its share of haters), but Nim sounds particularly interesting as a side-step from Python that runs faster than both Go and Rust.

Can anyone give me some insight as to why it's not as hyped, if at all? I'm rather unfamiliar with Nim, and it's seems to have a smaller community, but it feels like it should be getting all sorts of love considering its speed of execution.

Thanks in advance for the help!

View on HN

Actually it's being hyped that's weird. There are literally dozens of very interesting languages being created and developed right now and I bet you don't know of any of them. The only - and they are very few in comparison - languages which are being hyped since very early in their life cycle are the ones backed by corporations. Both Rust and Go are such languages and that's basically it.

"Normal" languages live on a different time scale: it takes many years to gather enough users to even have a chance of generating a bit of hype. For most languages that moment never comes: they are good, solid languages with decades of development behind them and completely obscure and unknown. Others become well-known in certain areas while still being unfamiliar for the "general public".

Take a look at Haxe, Opa, Elixir, Cobra or Io for example. They are all very interesting (each for its own reasons), mature and productive - and completely unknown. Out of those only Elixir gets mentioned here sometimes.

Anyway, a choice of language should never be based on "hype" alone. Of course, language popularity is an important factor, but most often limiting yourself to popular languages is a case of premature optimization: it's quite likely that in your project the language popularity won't make a difference (especially in small/short-lived projects) and that "raw" language features are more important than hype. (Of course that's not always the case: bigger or long-lived projects benefit from language popularity very much, for example by having easier time finding replacements for developers who went away and so on)

I personally wouldn't label Haxe as "completely unknown" - as a general-purpose language, yes, but it's relatively popular in game development due to its "killer app" of OpenFL.

One of the things that kills some of these "completely unknown" languages is that it isn't obvious they are still being developed. The last known release is years ago, or they still only support one platform, etc.

I'll add http://pike.lysator.liu.se/ to that list of "unknown" languages - It's my go-to language for doing simple prototyping.

Right, those were just examples, there are many (many!) more interesting languages.

Pike is a bit of a special case due to its history though. I first learned it in the 90ties, when I joined an effort to port some MUD from LPC - Pike's predecessor - to Pike. At the time both LPC and Pike looked very weird to me, coming from mostly static, compiled languages like C and Pascal. A "mixed" datatype (like void* in C) with type predicates was something new to me, built-in mappings and other high-level datatypes were too. I don't remember the details, but I think both Pike and LPC had an unusual object system, closer to prototype-oriented languages like Self, JS, Io or Lua than to "normal" class-based ones (but I may be wrong on this). Anyway, it's another good example of solid and mature but unpopular (to the point of obscurity) languages.

Last time I checked Io was slow and it didn't solve any new problems. If I wanted a slow OO language, I would rather keep using ruby/python as I already know them.

Haxe has the small niche of flash type games, and I think it is doing fine in that area. But to expect it to be as popular as a general purpose language is not warranted.

Haxe is general purpose language. It compiles - among other things - to Neko VM, which is a really nice little VM, good for rapid prototyping and to C++ code which is good for everything. The latter is how Haxe supports iOS IIRC.

Io is not "slow", although the level of dynamism it provides has obvious performance downsides. It's generally "fast enough" and - in my experience - a bit faster than CPython. Slower than JITed Lua though. It does, however, solve the C10k problem with its coroutines, actors and futures, which are implemented transparently for the user and with niceties like automatic deadlock detection (on runtime). It's not exactly anything new, but it was new when Io first appeared (I mean the implementation as a language feature, not the concept which is probably 3x as old as even I am). It has also very nice C FFI and very flexible, easily modifiable syntax and optional lazy evaluation which makes it great for developing DSLs.

That being said I don't "expect" these languages to be popular. For the most part, for most developers out there, it genuinely makes no sense to know them. I'd like them to be more popular, but I'm not stressing over this. I know them and I think I can use them to my advantage where it makes sense and that's enough for me personally.

But the thing is that Haxe doesn't really solve anything else other than being good for flash games. So even if it is Turing Complete, there is no point in spending time learning it if you do not care about making flash games.

And last time I checked, Io was slower than CPython and offered nothing more than a little more ideological OO purity. It didn't have any killer feature.

| Actually it's being hyped that's weird. |

The economic realities of software development require disposable human resources.

And this is why most most large software projects fail. Software development is not something 'disposable human resources' can do reliably.

I agree. Software development is (as of now) in its arts and crafts stage of development. Expertise matters. Experience matters. Professionalism matters.

The "economic realities" are /symptomatic/ of the impedance mismatch of an 'industrial scale' demand on the consumer side and an arts and crafts production side.

> most .. projects fail.

It is a minor miracle that they can even be attempted and many even succeed.

Another unknown language, in which I program, is Pliant www.fullpliant.org

The main reasons I think, are that Nim is not "production ready" and that other developers think of Nim as Andreas Rumpf's baby.

In my opinion, this happens when a single author is responsible for most of the implementation of a language.

Another example of this is the Crack language, which is still essentially controlled by one person, despite people declaring it "ready for writing useful code".

Two things make non-commercially funded languages successful. Firstly, they have a team of core developers (even if that is just 3-4 people), who often disagree with one another. Secondly, ad hoc contributions, which don't quite fit with the original aims for the language, are encouraged so long as they don't revert important core design decisions.

Julia and D are prime examples of successful languages along these lines. They both have more than one core developer, and they both have the feel of an ecosystem with many use cases, rather than a very focused language with strict design goals.

Experts seem to agree that both Nim and Crack are very competent, interesting languages. So I believe they have a very bright future when the main developers are happy that the core language is just about right, and when the guiding principles are understood well enough that a core group of developers can continue that vision.

Note that what I am saying has nothing to do with the main authors encouraging external contributions. In the case of both of the languages I mention, they both do that actively. And Nim certainly has other developers actively contributing.

Followup: I want to explain why this is so important. As a developer looking to use Nim (or any other language for that matter), I want to know the language is production ready, so that my code won't break. And if I have issues that need resolving in Nim before my project works, I want to know that I am not waiting on one individual to fix them. I need to know there is a core group of identifiable people I can go to who can answer my queries, escalate my queries and ultimately resolve my issues. Of course these things are also important for the members of the Nim development community itself, not just users of the language.

While Nim has mostly been developed by Andreas, there seems to be about 3-4 people working on the compiler and standard library. I've contributed a bit myself, and I've found Andreas and the other developers very friendly to outside contributions.

I am very optimisitic about the Nim community, it's still small but it is open and friendly, so I think all the potential for growth is there, especially now that the compiler itself is reaching maturity

I think you hit the nail on the head. I've been following the Nim forum and the IRC channel for a while and, while I fully agree with dom96 about Rumpf not being the only developer, still find the difference with communities like Julia (which I closely follow as well) sometimes staggering. The hypothesis that the lack of success of Nim is due to its not being supported by some organisation like Google or Mozilla does not explain why Julia has many more contributors and its development proceedes at a much quicker pace. AFAIK there is no such organisation behind Julia's development.

I've seen more than one time discussions on the Nim forum die of a sudden death after Araq just joined and said something against the idea being discussed. I've never seen something like in the Julia mailing list. Like wbhart, I think this happens mainly because there isn't just one core developer.

From what I can see Julia has a lot of academic institutions behind it. Take a look at the contributors and you will see lots of mention of MIT and Harvard. I may be wrong but I am assuming that those institutions are sponsoring the development of Julia. Nim has no such support from anyone!

I doubt academic institutions "sponsor" programming languages, other than paying the salary of some of the people who happen to be writing them.

Where is Rumpf? MIT?

http://web.mit.edu/nimrod-lang/arch/i386_linux26/doc/tutoria...

I'd say that the academic institutions may be paying some of these people to develop Julia.

As far as I know, Andreas Rumpf does not work for MIT or any academic institution if that's what you're implying. It is rather curious that the MIT website has a copy of Nim's documentation.

I'm not really implying that. Somewhere or other it says Andreas is working for a top secret startup and is always trying to start his own.

What I'm saying is that it can be misleading how much academic institutions are "behind" academic projects. If you talk to most academics, you'll discover that they believe their academic institutions are doing everything they can to discourage their projects (academics can be somewhat sarcastic).

Some of the Julia core devs are academics and write papers on Julia, yes. Their salaries are paid by those institutions. They may have students who can do some coding for them (so long as they write a thesis too). But being an academic is a very demanding lifestyle. With few exceptions, you are paid to write papers, teach, do administration and apply for grants, not to write code.

I think it's more likely that a couple of the developers are being paid to write Julia than it is that they are all working on it in their spare time.

While it may be a demanding lifestyle, you are also paid to do research. And research could include developing new programming languages.

Design by committee is inferior (too many cooks).

But most good maintainers I know listen to critique of the people who use their stuff.

More devs are good for another reason than disagreeing, if one doesn't work on the code anymore, there are others who can.

I agree with you. One needs a group of like-minded individuals who understand and agree on the core design goals, but who have individual say in what they implement. Nim isn't being designed with an inferior model, it is being designed with an inefficient model. With three or four core devs, the work goes 3-4 times faster (slight exaggeration of course). That means a language can become popular in 5 years instead of 15. This is why companies love teams so much. One that works well together is worth many developers who work well alone.

While Andreas is still doing most of the core development it is not true that he is still the sole developer of Nim. I am personally involved with a lot of work on the standard library and there are two others who also work on the compiler. We all have a say in the design of Nim. In addition to that I have built a lot of software for Nim programmers in Nim like for example Nimble and the Nim forum.

I was vaguely aware of this. But where are the major design decisions publicly discussed?

If you look at the Julia issue tracker, you'll see an enormous amount of discussion between and with core devs about language design decisions.

It's good to have someone primarily responsible for the compiler, someone responsible for libraries, another for GC, another for the package manager, etc. I'm not suggesting every core dev needs to be intimately involved with every line of code or design decision. It's more about how the development process feels to outsiders. After all, the question that was asked was about why Nim is not being hyped, rather than why is it not a fantastic language (it is fantastic).

It is great to hear about two other (albeit nameless) individuals working on the compiler though.

I will agree that discussing programming language design decisions in the open is something we have to work on. IRC unfortunately is not ideal but it is where most of these discussions take place. I am personally trying to encourage people to write RFCs on Github or on the Nim forum and there are some already there (https://github.com/Araq/Nim/labels/RFC).

I don't know much about language design, how tightly are syntactical/grammatical decisions coupled with other stuff like GC?

I understand, that, if things the language uses are implemented in that language itself, the language design breaks them. But if not?

A language like Java could probably work without GC, give the dev a "free" method and be done with it. The whole language would look the same syntactically.

Most discussions about major things occur in IRC in #nim on freenode.

> With three or four core devs, the work goes 3-4 times faster (slight exaggeration of course).

Fred Brooks would like a word...

More seriously, this is the important part:

> like-minded individuals who understand and agree on the core design goals,

A team who agrees on the big picture, but can work together to sort out the small details, is really important.

There's also balances between doing things quickly and doing things right. Sometimes, slowing down a bit gets you a significantly better end product. Sometimes it's just a slowdown.

For me the feature that makes Rust stand out is memory safety without garbage collection. It's got all the goodness you'd expect from a modern programming language while giving me basically all the flexibility I could get from writing C or C++. That's a very strong differencing trait, at least for me.

I've never used Nim and I should probably give it a try but it seems that the "garbage collected, parallel oriented" niche is somewhat more cluttered with the likes of Go, the various languages built on top of .Net or the JVM, the lisps, the haskells... Not all target exactly the same use cases but there's a lot of overlap here and it's harder to stand out.

Nim is different. Advanced but pragmatic type system, macros, native compilation, tiny runtime, good C interop - no language I know of offers quite the same set of features. I was very pleasantly surprised with it and decided to keep it as an "tiny, expressive, natively-compiled" solution in my toolbox.

There is nothing quite like Nim in the other languages you mention. Nim's GC is different than most of the others and you can also control it so it only runs for a certain amount of time. Nim is also very expressive and clean. The meta-programming capabilities are fantastic. Its overhead is significantly lower than the JVM and it is cross platform (unlike .net).

I think Nim author need to documentate/explain/illustrate a lot more about its GC. I once have interested in Nim, but I couldn't figure out how its GC is proper (predictable & deterministic rather than throughput) to RT apps. And that dropped my interest on it. I believe this is a biggest obstacle to RT app programmers to take interest on Nim.

Nowadays the term "GC" almost implies "tracing GC", so "non-tracing GC" need to be well explained. Or need to adapt some new term to explain new concept. Currently, Nim's GC explanation just looks like incremental RTGC that is not really attractive to existing RT app programmers.

Have you taken a look at the GC documentation (http://nim-lang.org/gc.html)?

The reason, in my opinion at least, is that Nim does not have a commercial company behind it like Go and Rust who have Google and Mozilla respectively.

This in turn means that Nim does not have as many resources (it is developed completely voluntarily in people's spare time) so development is slower.

Yep, that's basically true. If the development of a language like Python started at about this time, I bet it would be in the same position as Nim.

But how can you get a major company to get behind Nim when the all want to have their own programming language?

Maybe you can't. But you can get the small companies and individuals first. Slowly the contributions make the ecosystem stronger and bigger and risk-averse organizations then can hop on as well. This is pretty much how Python grew.

Rust and Go have big backers behind them. This generates a feedback loop of hype leading to toy projects and thought leadership, which subsequently turns into real adoption. If weren't for that they would be maturing at about the same rate as Nim.

Adoption is greatly helped by hype, but maturity is something different. Rust and Go have a number of paid developers working full time on the implementation. This helps maturity and is unrelated to hype.

Maturity in the compiler != ecosystem maturity. To pick up the broader mainstream also means external tooling(ide, debugger, etc.), library code, documentation, examples and tutorials, live events like conferences and lectures, and "friends who use it" (critical mass in localized communities)

When you miss some of these elements the barriers to entry go way up and the community is limited to people who can tolerate the environment without it. That's true regardless of how good or proven the base technology is. Hype and institutional use accelerates this cycle by forcing it onto developers - you end up with more people early on who say "yes, i put this into production and i can tell you how it worked."

Corporations have become better at promoting technologies to developers, including worse technology. Languages are seen as strategic advantages against the competition ("A language that only work on our devices!"). So I would bet corporate money find its way towards tech blogs and user groups, to bring the kool-aid to the masses. Also keep in mind that big corporations like Google are dominant entities and anything they do is closely watched by peons. For the success of BigCorpLang they need their toy projects anyway.

Google and Microsoft are better at doing stuff like that than others. I wonder why Apple has taken that approach with regards to Swift

If by "that approach" you mean not developing it in the public, that's always been Apple's strategy. They benefit from developers being locked in to building for their platform.

>why it's not as hyped

I don't know how relevant that is, but Rust has Mozilla (and Samsung?) and Go has Google plus some Unix / Plan 9 people behind it. But Nim? There are probably other factors as well.

By hype, do you mean fewer people using it? Can't really submit articles and projects for Nim that don't exist. If you like the language, why not write something in it then blog about it?

There is no technical reason why Rust should be slower than Nim, as far as I know.

Nim has the advantage of compiling to/through C, for which compilers have been optimized for a long time.

That isn't an advantage, IMHO. rustc generates LLVM IR, which allows it to take advantage of essentially all the same optimization passes that clang does. Generating LLVM IR instead of C has some advantages—debug information can be made more precise, precise aliasing metadata for optimization can be added to the output, accurate garbage collection is possible, there's no need to go through the C parser and semantic analyzer, etc.

Examples of features that rustc uses today for optimization beyond those available in C are the "nonnull" and "dereferenceable" attributes (along with some custom optimization passes to make non-null pointer optimizations stronger than what LLVM provides out of the box). An example of a feature beyond C that it could use, but does not today, is custom type-based alias analysis.

I'm currently working with the Xeon Phi and there you basically have to use Intel's C, C++ or Fortran compiler if you want good performance out of the box. Since Nim compiles to C I can write code that gets auto-vectorized and -optimized by the Intel compiler.

Perhaps it's not an advantage, but it certainly is not a disadvantage. An advantage that I can think of is portability as well as easier interfacing with C libraries.

Almost all systems that matter have an LLVM port these days, so portability isn't really an issue in practice (though sometimes C can help with microcontrollers, etc.) Game consoles in particular are all x86 or PPC these days. Easier interfacing with C libraries is a fair point, although you still have to figure out how the two languages' type systems interact and presenting good error messages can be a pain if you're relying on the C compiler to do semantic analysis.

I disagree to optimisation, but agree to portability. It's difference of 100% and 99%, but sometimes the 1% can be significant. And of course, it also can be insignificant.

Rust uses LLVM as a backend so it gets similar optimization passes as clang for instance, so it's not so different. Basically rustc generates LLVM IR where Nim generates C, apparently. In most of the benchmarks I've seen so far you could expect similar performances between C and Rust.

Not to start a language flamewar but I'd like to see hard numbers before I believe that in the general case Nim is faster than Rust.

Have you seen these benchmarks? https://github.com/logicchains/LPATHBench/blob/master/writeu...

I have not, I mostly glanced at http://benchmarksgame.alioth.debian.org/ where Rust generally matches C performance whithin a few %. But Nim is not part of this benchmark apparently.

I haven't looked at your link in details but the fact that one C++ implementation manages to outperform all the others (including other C and C++ implementations and of course Rust and Nim) by more than one order of magnitude leaves me perplex. It means there must be a huge room for improvement in a lot of those tests. Also the timing code is implemented in the tests themselves using each language's primitives which seems a bit risky to me when comparing language performances.

Also the unsafe rust version has exactly the same performance as the safe one which is weird. After looking at the unsafe version it appears that all the unsafe blocks are just here to remove the bound checks on the vector indexing and that's it. That seems like a weird choice for optimization, I'd have tried to make the recursive function iterative first, for instance. At least it goes to show that that particular check is not too expensive and it's better to stick to safe code when possible.

>...one C++ implementation manages to outperform all the others ... by more than one order of magnitude

As does the cached Javascript version. All of the implementations in the path benchmarking by fiat use a naiive algorithm (recompute the cost for each recursive traversal). The C++ and Javascript cached versions are supposed to show that algorithm choice is much more important than language choice (and do some memoization of the cost calculation).

https://github.com/logicchains/LPATHBench/blob/master/jscach...

> he fact that one C++ implementation manages to outperform all the others (including other C and C++ implementations and of course Rust and Nim) by more than one order of magnitude leaves me perplex.

This uses a "pruning" algorithm and is a different algorithm than all the other implementations use. It shouldn't be used to compare the different languages, as it's just not doing the same work.

Rust uses LLVM, I believe, and LLVM does as good a job optimizing as just about anything else out there.

Go and Rust and included in the Computer Language Benchmark game: http://benchmarksgame.alioth.debian.org/

Nim, and many of the other interesting languages mentioned in this thread are not.

I'm not sure if this is a cause or effect.

https://github.com/def-/LPATHBench/blob/master/nim.nim

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

That looks amazing. One would expect it to be slower given all of the interesting language features.

I've been wanting to learn one of the up and coming languages (Rust, D, Go, etc.). Would Nim be a good choice?

If you write C/C++ for a living but want a nicer syntax and better language features, then yes, absolutely. If you're looking for a specific niche, then it depends. I'm personally more excited about Rust than Nim, but I also don't do much systems programming these days, so I don't have a specific purpose in mind.

Why are you more excited about Rust?

Probably depends on what software you would like to develop and what languages you already know and enjoy.

Well I've been writing Python for quite a while and I'm currently getting into both Scala and JS/Node.

Not to mention, Nim still doesn't have a Wikipedia article because it is "not significant". http://en.wikipedia.org/wiki/Nim_(disambiguation)

I can't see where it says Nim (programming language) is "not significant". Maybe the reason there isn't a Wikipedia article is as simple as because nobody who has an account on Wikipedia had heard of or thought to create an article on Nim. The solution to which is quite simple, go create an article.

It used to have a page. It was deleted because the language was not considered significant. This is a relatively famous case, referred to frequently.

https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletio...

> 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.

The problem is that most sources about Nim are by Araq or not reliable enough.

I really dislike this policy when applied to programming languages. Things from pop culture are going to be referred to pervasively in the media and blogosphere, but programming languages don't get there without massive marketing pushes, press releases, etc.

That doesn't mean a language is not itself notable.

Anyway, there's plenty about Nim that is not primary:

http://goran.krampe.se/2014/10/13/here-comes-nim/

https://www.btbytes.com/notebooks/nimrod.html

http://picheta.me/articles/2013/10/about-nimrods-features.ht... (by Dominic Picheta but external to Nim website)

http://steved-imaginaryreal.blogspot.co.uk/2013/09/nimrod-re...

http://vocalbit.com/posts/exploring-type-classes-in-nimrod.h...

http://blog.ldlework.com/a-cursory-look-at-meta-programming-...

http://joshfilstrup.com/posts/2014-10-27-2014-monads-in-nim....

http://ziotom78.blogspot.de/2014/01/experiments-with-nimrod....

http://progopedia.com/language/nimrod/

https://geetduggal.wordpress.com/2014/03/03/consider-nimrod/

http://www.drdobbs.com/open-source/nimrod-a-new-systems-prog... (by Andreas Rumpf - but definitely an indicator of notability)

http://lambda-the-ultimate.org/node/4749

http://ivoras.net/blog/tree/2013/Oct-2013-10-05.what-i-like-...

http://www.infoq.com/presentations/nimrod (by Andreas Rumpf, but a sign of notability)

http://rosettacode.org/wiki/Category:Nimrod

http://gradha.github.io/articles/2014/11/swift-string-interp...

http://togototo.wordpress.com/2013/08/23/benchmarks-round-tw...

http://felsin9.de/nnis/nimrod/nimrod-gpn14.pdf

http://learnxinyminutes.com/docs/nim/

http://stackoverflow.com/questions/tagged/nim?sort=votes&pag...

http://gradha.github.io/articles/2014/03/nimrod-for-cross-pl...

https://impythonist.wordpress.com/tag/nimrod/

https://github.com/trending?l=nimrod

http://maniagnosis.crsr.net/2013/12/letterpress-cheating-in-...

That doesn't mean that the best resources aren't on the Nimrod website itself. But penalising a language for having excellent primary resources would be a bit crazy in my opinion.

I just discovered that blogs and other self published resources may not be used to establish notability for Wikipedia.

Basically Nim cannot ever become notable unless there are press releases about it or peer reviewed papers written on it. And without a company like Google garnering/writing press releases and none of the authors of Nim are at academic institutions... Well this is awkward.

Too many programming languages, too little time; and no one seems willing to make and publish measurements for all those "interesting" languages.

http://benchmarksgame.alioth.debian.org/play.html#languagex

Reply on news.ycombinator.com