9 ms·

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

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!

qznc 12y ago
There is no technical reason why Rust should be slower than Nim, as far as I know.
- def- 12y ago
  Nim has the advantage of compiling to/through C, for which compilers have been optimized for a long time.
  - jgallag8 12y ago
    Rust uses LLVM, I believe, and LLVM does as good a job optimizing as just about anything else out there.
  - simias 12y ago
    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.
    - dom96 12y ago
      Have you seen these benchmarks? https://github.com/logicchains/LPATHBench/blob/master/writeup.md https://github.com/logicchains/LPATHBench/blob/master/writeu...
      - deleted 12y ago
        [deleted]
      - simias 12y ago
        I have not, I mostly glanced at http://benchmarksgame.alioth.debian.org/ 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.
        perturbation 12y ago
        >...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/jscache.js https://github.com/logicchains/LPATHBench/blob/master/jscach...
        idlewan 12y ago
        > 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.
  - pcwalton 12y ago
    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.
    - dom96 12y ago
      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.
      - pcwalton 12y ago
        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.
      - eonil 12y ago
        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.
    - def- 12y ago
      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.
dom96 12y ago
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.
- finid 12y ago
  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?
  - vbit 12y ago
    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.
cremno 12y ago
>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.
chipsy 12y ago
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.
- sanxiyn 12y ago
  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.
  - chipsy 12y ago
    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."
simias 12y ago
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.
- vbit 12y ago
  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).
  - eonil 12y ago
    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.
    - dom96 12y ago
      Have you taken a look at the GC documentation (http://nim-lang.org/gc.html http://nim-lang.org/gc.html)?
- klibertp 12y ago
melling 12y ago
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?
klibertp 12y ago
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)
- noselasd 12y ago
  I'll add http://pike.lysator.liu.se/ http://pike.lysator.liu.se/ to that list of "unknown" languages - It's my go-to language for doing simple prototyping.
  - klibertp 12y ago
    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.
wbhart 12y ago
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.
- k__ 12y ago
  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.
  - 12y ago
daveroberts 12y ago
Go and Rust and included in the Computer Language Benchmark game: http://benchmarksgame.alioth.debian.org/ 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.
- wbhart 12y ago
  Not to mention, Nim still doesn't have a Wikipedia article because it is "not significant". http://en.wikipedia.org/wiki/Nim_(disambiguation) http://en.wikipedia.org/wiki/Nim_(disambiguation)
  - laumars 12y ago
    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.
    - wbhart 12y ago
      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.
      - def- 12y ago
        https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Nimrod_(programming_language)_(2nd_nomination) 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.
p0nce 12y ago
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.
- finid 12y ago
  Google and Microsoft are better at doing stuff like that than others. I wonder why Apple has taken that approach with regards to Swift
  - RussianCow 12y ago
    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.

qznc 12y ago

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

def- 12y ago
Nim has the advantage of compiling to/through C, for which compilers have been optimized for a long time.
- jgallag8 12y ago
  Rust uses LLVM, I believe, and LLVM does as good a job optimizing as just about anything else out there.
- simias 12y ago
  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.
  - dom96 12y ago
    Have you seen these benchmarks? https://github.com/logicchains/LPATHBench/blob/master/writeup.md https://github.com/logicchains/LPATHBench/blob/master/writeu...
    - deleted 12y ago
      [deleted]
    - simias 12y ago
      I have not, I mostly glanced at http://benchmarksgame.alioth.debian.org/ 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.
      - perturbation 12y ago
        >...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/jscache.js https://github.com/logicchains/LPATHBench/blob/master/jscach...
      - idlewan 12y ago
        > 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.
- pcwalton 12y ago
  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.
  - dom96 12y ago
    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.
    - pcwalton 12y ago
      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.
    - eonil 12y ago
      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.
  - def- 12y ago
    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.

dom96 12y ago

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.

finid 12y ago
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?
- vbit 12y ago
  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.

cremno 12y ago

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

chipsy 12y ago

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.

sanxiyn 12y ago
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.
- chipsy 12y ago
  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."

simias 12y ago

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.

vbit 12y ago
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).
- eonil 12y ago
  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.
  - dom96 12y ago
    Have you taken a look at the GC documentation (http://nim-lang.org/gc.html http://nim-lang.org/gc.html)?
klibertp 12y ago

melling 12y ago

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?

klibertp 12y ago

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)

noselasd 12y ago
I'll add http://pike.lysator.liu.se/ http://pike.lysator.liu.se/ to that list of "unknown" languages - It's my go-to language for doing simple prototyping.
- klibertp 12y ago
  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.

wbhart 12y ago

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.

k__ 12y ago
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.
- 12y ago

daveroberts 12y ago

Go and Rust and included in the Computer Language Benchmark game: http://benchmarksgame.alioth.debian.org/ 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.

wbhart 12y ago
Not to mention, Nim still doesn't have a Wikipedia article because it is "not significant". http://en.wikipedia.org/wiki/Nim_(disambiguation) http://en.wikipedia.org/wiki/Nim_(disambiguation)
- laumars 12y ago
  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.
  - wbhart 12y ago
    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.
    - def- 12y ago
      https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Nimrod_(programming_language)_(2nd_nomination) 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.

p0nce 12y ago

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.

finid 12y ago
Google and Microsoft are better at doing stuff like that than others. I wonder why Apple has taken that approach with regards to Swift
- RussianCow 12y ago
  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.