41–50 of 86 posts
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).
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…
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).
Earlier quoted context omitted.
People complain about lack of generics and proper try/except/finally in Go. Nim has both.
Then let's ask instead, why use Nim over Pascal?
Pascal dialects, while much safer than C, suffer from use-after-free and possible memory leaks, also you don't need to mark unsafe code as such.
This includes any modern Pascal variant.
Using "no memory leaks" and "reference counting" in the same sentence is #fakenews. Reference counting leaks cycles unless accompanied with a tracing GC (at which point reference counting makes little sense).
Earlier quoted context omitted.
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.
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…
Earlier quoted context omitted.
Then let's ask instead, why use Nim over Pascal?
Actually type safe, with support for various kinds of automatic memory management. Pascal dialects, while much safer than C, suffer from use-after-free and possible memory leaks, also you don't need to mark unsafe code as such. This includes any modern Pascal variant.
> Memory leaks are not a concern as Nim uses one of several available garbage collectors. The new ARC option works with reference counting instead of a GC. Using "no memory leaks" and "reference counting" in the same sentence is #fakenews . Reference counting leaks cycles unless accompanied with a tracing GC (at which point reference counting makes little sense).
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…
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/
Oh! I have another use-case; first-class (easier-than-others?) cross-compilation support. I had to build a one-off tool that was a a glorified "curl wrapper" with validations, for Windows; on a Mac. Wrote a simple nim script, cross-compiled for Windows, and it's been fine and dandy for a year now :) I'm sure other languages support this (golang?), but Google's SEO suggested nim-lang.org