top | item 23335283

(no title)

sherincall | 5 years ago

While I rather like nim as a language, there's a few more cons that need to be considered for any real use of the language:

- It has a bus/lottery factor of 1. The vast majority of all the changes were done by Araq and I have very little faith that the language would survive without him. This is even more pronounced with Zig (mentioned in comments here).

- It has had some very embarrassing bugs after the 1.0 milestone. Most of them were specific to Windows (e.g. [0]), which casts a lot of doubt on its cross-platform promise. Multiple times in the last year, when debugging a nim program, it turned out that the problem was in the language/standard library.

Now, these might not be reasons enough to not use nim, since it's a lovely language when it works, but a pro/con list should be honest.

[0]: https://github.com/nim-lang/Nim/issues/12315

discuss

order

beagle3|5 years ago

While Araq is BDFL and is still doing most of the implementation for Nim, there are nontrivial contributions from others, and commercial sponsorship at this point.

And with respect to the ecosystem-at-large, there are tens of contributors and a very healthy package repository: nimble (package manager) written and maintained by dom96; arraymancer (tensor+array+nn) written and maintained by mratsim; an up-and-coming thread runtime by mratsim (called weave) which is better than just about any existing thread runtime for any language. NimPy for seamless python integration (... which produces one DLL that works with every Python version; can your C++ do that?) by yglukov, and many more.

And most libraries you'd need already have a Nim wrapper, (and one is extremely easy to generate if not), though the pure-nim body is growing every day - have a look at https://nimble.directory/

threatofrain|5 years ago

I see one of the top jobs of the dictator as exercising reputation and credibility to gather and delegate expert work to expert lieutenants. If the years pass and you're still the lonely dictator...

dmix|5 years ago

> - It has a bus/lottery factor of 1.

What was Rusts early years like? Was it one developer for the first part?

I'd imagine this is not a big deal in the early days, where the benevolent dictator is as much the language as the project itself, not all technology adoption happens on the same timelines. Matz with Ruby took a long time to become super popular, Rich Hickey with Clojure seemed to be a powerhouse even as that found quick adoption before stalling.

fluffything|5 years ago

When Rust 1.0 was released it had in the order of hundreds of developers doing work here and there.

When Rust started as a hobby project it was a one man effort, but it was also a project with ~1 user. It grew developers before actually growing users, and for a while, it had more developers than users.

littlestymaar|5 years ago

> What was Rusts early years like? Was it one developer for the first part?

In the very beginning, it was a one-man project, but after some time it was picked-up by Mozilla research as an official research project, with several developers working on it (brson and pcwalton in addition to the language creator) and they also started a research new browser (in partnership with Samsung) using this experimental language. That's when people started to hear about Rust (and it was still very far from 1.0 at this point).

sherincall|5 years ago

Certainly. And I hope same thing happens with nim. All I'm advising against is people betting their livelihood on nim reaching critical mass before a single unexpected event happens that removes the benevolent dictator from the picture. Or at very least be aware of it and make an informed decision.

JNRowe|5 years ago

> Most of them were specific to Windows, which casts a lot of doubt on its cross-platform promise.

Oh. That really surprised me, as I had assumed the bugbears I have as an occasional nim user were because it was developed for/on Windows primarily. Actually bothering to take a look seems to show me that isn't the case at all.

Bugbears such as the linking story on Linux¹, the argument handling², the style and verbosity of the compiler output, [a bunch of others]. Nothing show stopping to be fair, but a bunch of things that just seem out of place(and that always seem to require explanation when co-workers see a nim tool).

1. https://github.com/nim-lang/rfcs/issues/58

2. https://nim-lang.org/docs/parseopt.html , although alleviated by argparse to some extent.

hhmc|5 years ago

Does anyone know the interpretation/etymology of 'lottery factor'? I assume it's the risk of the Key Person winning the lottery and abandoning the project? I guess it makes more sense in the context of rank-and-file employees, rather than passion projects...

samsari|5 years ago

I assume it only applies in the cases where the project is being produced by a company, and the lottery winner would then retire. For a hobby project, Key Person winning the lottery and quitting their day job would be a good thing.

WJW|5 years ago

It's a less morbid variant of "bus factor". Agree that it makes less sense than bus factor in this particular case.