4 ms·
If not having to clutter code with memory semantics isn’t enough of a case, I could gush about UFCS abrogating the need for interfaces, or Nimble and the dead-s
by netbioserror 4y ago
If not having to clutter code with memory semantics isn’t enough of a case, I could gush about UFCS abrogating the need for interfaces, or Nimble and the dead-simple module and export system (and not needing to scatter ‘pub mod’ files all over the project), or the choice of any number of useful GCs or to forego GC, or the very quick compiler presenting very powerful, sensible options and making things like static linking trivially easy. This all blew my Rust experience out of the water.
But it’s ultimately an uphill battle. Nim has no marketing budget. It’s comparable to any language introduced in the 90s going up against Java. There is a zeitgeist of “cool” around Rust that means many tools will be written in it regardless of how much grassroots rooftop shouting anyone does about Nim. I think too many people assume we all live in a world of perfect information and rational decisions, but that just isn’t the case.
- nindalf 4y agoYeah it’s entirely possible that some people pick what’s popular instead of what we think is theoretically optimal. I would only caution you about assuming that people are following the zeitgeist instead of making sound technical decisions. For example there’s only one language that prevents race conditions at compile time. Maybe they write more multithreaded code than you did and really prize this feature. Maybe they like the libraries that make the ecosystem rich. Does nim have anything as polished and performant as clap and serde? Maybe they like the generally high quality of documentation in the Rust ecosystem? I could point out several other legitimate axes on which Rust is a superior alternative. It doesn’t matter, because you’re aware of most or all of these. What’s important is for you to avoid falling into the fallacy of “what’s popular must be bad, because the average person isn’t as smart as me”. Lots of smart people fall into this trap. It’s especially bad to fall into this when you’re thinking about platforms because the utility of a platform is directly proportional to its popularity. Language X might have so many flaws, but if it’s popular then the community around it could find myriad ways to mitigate the flaws. They’ll release a million useful libraries that make our lives easier. And if the language gets 50% more popular, it gets 50% more useful to us because the ecosystem gets richer. Better ecosystem means more companies adopt it => more jobs available => it’s a sound choice to learn this language in your free time => more devs available with this skill => it's a good idea for more companies to adopt it. It’s a fly wheel of adoption. Java benefited from this, even if it wasn’t a perfect language. Rust benefits, but to a lesser extent because there’s so many good alternatives now (including Java!) Even if Rust doesn’t do it for you in 2023, I’d counsel taking a look again in 2026. The growth around the language (80% per year in crate downloads, 30% per year in crate authors) means that it’s possible that you might find most of your pet peeves might have been addressed by then. Either in the main language or in a library.
- cb321 4y ago>Does nim have anything as polished and performant as clap and serde? "Polished" and "high quality" are more subjective/implicitly about adoption, IMO. "Performant" has many dimensions. That said, I just tested the Nim https://github.com/c-blake/cligen https://github.com/c-blake/cligen vs clap: cligen used 5X less object file space (with all size optimization tweaks enabled in both), 20% less run-time memory for large argument lists, and the same run-time per argument (with march=native equivalents on both, within statistical noise). cligen has many features - "did you mean?/suggestions", color generated help and all that - I do not see obvious feature in clap docs missing in cligen. The Nim binary serde showing is unlikely as good but there are like 10 JSON packages and that seems maybe your primary concern. More to add color your point than disagree (and follow up on my "adoption") - your ideas about polish, quality, docs, etc. are part of feedback loop(s) you mentioned. More users => Users complain (What is confusing? What is missing? etc.) => things get fixed/cleaned up/improved => More users. Besides "performant" being multi-dimensional, the feedback loop is more of a "cyclic graph". :-) Or maybe this is just a sub-graph of "ecosystem richness". While I probably prefer Nim as much or more as @netbioserror, I am not too shocked by the mindshare capture. It seems to happen every 5..10 years or so in prog.langs. While many of your points are not invalid, tech is also a highly hype-driven & fad-driven realm. In my experience, the more experience with this meta-feature that someone has, the more skeptical they are of the latest thing (more rounds of regret, etc.). Also, that feedback graph is not a pure good. Things can get too popular too quickly with near permanent consequences. ipv4 got popular so quickly that we are still mostly stuck on it 40 years later as ipv6 struggles for penetration. Whatever your favorite PL is, it may also grow features too fast.
- nindalf 4y agoYeah, your points are valid. I think the beauty of serde is its flexibility. I can change the format from JSON to one of the other 21 supported formats with ease. We're both agreed - popularity benefits platforms in many ways. I'm not a fan of hype-driven things, unless the hype ends up making the thing more valuable. Rust is a good example - there was undoubtedly something useful there with its concept of compile time checks and memory safety with performance. It also had nice tools like cargo. But that wasn't enough. Quality alone isn't enough. Look at the adoption curve (https://lib.rs/stats https://lib.rs/stats). If it had remained as popular as it was in 2018 then it would not be something I could recommend for general purpose programming. The main criticism of Rust in 2018 was that there weren't enough libraries to do basic things. You had to write and maintain a lot of that yourself. Fortunately for Rust, the hype based around its feature set and early successes snowballed into more adoption. In 2023, hardly anyone complains about missing libraries. At most they're missing one or two, and they can write those themselves. Joining a hype train of a platform is a rational thing to do, because of the technical benefits of using a popular platform. I'm far more critical of fads in our industry where we blindly copy practices from large tech companies, like algorithmic interviews. Copying interview practices doesn't lead to shared benefits, unlike a platform. > Whatever your favorite PL is, it may also grow features too fast. For what it's worth, Rust is really conservative about adding new features. Only big features I can remember in the last 3 years is GATs, and that's a pretty nice feature. Most of the feature work is making things more consistent. For example, we can write async functions but not async trait methods. They're fixing this inconsistency now.