Hacker News new | ask | show | jobs
by sherincall 2211 days 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

4 comments

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/

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...
But duties are being delegated and Araq isn't alone. For example multithreading has been delegated to the amazing mratsim: https://github.com/mratsim/weave . There are multiple people helping with the new move-semantics-based runtime: https://github.com/nim-lang/Nim/issues/14224 Documentation is delegated to narimiran who also has his fair share of commits: https://github.com/nim-lang/Nim/graphs/contributors?from=201...
> - 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.

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.

Rust is design by committee with complicated and large syntax area and to solve one problem of memory safety created a mountain of borrow checker syntax and a steep learning curve.

So only time will tell if BDFL based language comes up like Linux or design by committee like language. Right now Rust is not that significant like Nim and Zig so all have a chance to come up.

Once there are substantial software written in them like C or C++ than only will know, right now among modern language only golang and Swift reached that stages as being significant systems programming language in spite of GC. Indeed I doubt if Rust will be as revolutionary as Lisp or Haskell or Smalltalk in terms of contributions for the development of compilers and language designs.

Not bad for a bot, tell your master that your coherency levels are well down.
> 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).

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.
While the lottery factor is concerning, also many corporate-driven languages have a similar risk: the company can drop the language or bend it out of shape to satisfy business needs. It happened many times.
Which languages are you referring to where it's happened many times? Racking my brains but falling short.
Visual Basic
HTML, CSS, JavaScript, and the Browser Wars come to mind
> 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.

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...
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.
It's a less morbid variant of "bus factor". Agree that it makes less sense than bus factor in this particular case.
It doesn't make any sense: you win the lottery and stop working on your baby?

I know it's not a big deal but it seems borderline superstitious to me.