Live data from Hacker News

Pros and Cons of Nim

onlinetechinfo.com

31–40 of 86 posts

Re: Pros and Cons of Nim

#31

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 mileston…

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

Re: Pros and Cons of Nim

#32
post #27

It occurs to me that the although they were aimed at different uses cases the language that's actually closest to Nim today is Julia. Python-like syntax, compiled to native code, significant meta-programming capabilities, some native support for concurrency. The biggest difference seems to be the approach to types, since Julia is a dynamically typed language (with optional type annotations) and Nim is statically type…

Julia's ahead-of-time compilation story is not great. If you just want a single executable, it's kind of a pain, and there are all sorts of caveats. I think it's slowly getting better, though, but the language really wasn't designed for that use case. If I needed run-time metaprogramming/JIT compilation/a REPL, I'd go for Julia. For a single executable, I'd choose Nim.

Re: Pros and Cons of Nim

#33
post #31

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 mileston…

> - 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 th…

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.

Re: Pros and Cons of Nim

#34

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 mileston…

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

Re: Pros and Cons of Nim

#35
post #31

Earlier quoted context omitted.

> - 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 th…

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.

Re: Pros and Cons of Nim

#36
post #34

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 mileston…

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.

Re: Pros and Cons of Nim

#37
post #27

It occurs to me that the although they were aimed at different uses cases the language that's actually closest to Nim today is Julia. Python-like syntax, compiled to native code, significant meta-programming capabilities, some native support for concurrency. The biggest difference seems to be the approach to types, since Julia is a dynamically typed language (with optional type annotations) and Nim is statically type…

Last I checked, Julia is not AOT compiled, and some people don't like Julia's startup time.

For numerical computing however Julia wins hands own purely based on the community and libraries.

Re: Pros and Cons of Nim

#38
post #34

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 mileston…

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

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

Re: Pros and Cons of Nim

#39
I love Nim as a language. I do not love the Nim ecosystem. It is too sparse. Even now there isn't a good web framework that folks can use in production. Jester is ok but it doesnt inspires the same kind of confidence that Echo, Fiber etc would do. Jester still doesnt have its own web page marketing it.

I really think that the folks behind Nim need to focus on getting some killer apps in the ecosystem and in marketing them. That's all Nim needs. Just some useful tools wrapped in a nice package.

Re: Pros and Cons of Nim

#40
post #26

I'm a big fan of Nim, but I really wish it supported cyclic type declarations in separate files and out-of-order functions without forward declarations. As it is, I'm constantly structuring things around those limitations. Big projects often end up squeezed into a single huge file (or a few huge files).

yes please!

I had forgotten how irritating creating header like declaration files were till I tried Nim.

Post reply on HN