[fataliss]

Maybe my lack of lower level language knowledge will show here, but how does that compare to Rust? I keep seeing and hearing about these new-ish languages Rust, Nim, Zig, etc. that all claim to be C/C++ perf lvl but better developper experience. Any of these is preferred for API/Web development? Does it yield much advantage over something like Elixir that already provides significant perf increase over a Python(Django-Flask)/RoR stack?

[dom96]

> Any of these is preferred for API/Web development?

I often wonder why anyone would use a language like Zig or Rust for Web development. I am very much biased in favour of Nim here, but to me in general a non-GC'd language seems like overkill for web development. So I would rule those languages out straight away.

I can't speak to Elixir, likely the main difference will be the lack of a mature Django-like framework. I'm assuming that Elixir has one, whereas Nim doesn't. If you're looking for a fun project, I would love to see that made for Nim and happy to give pointers if you need them :)

[fataliss]

Indeed Phoenix is a great web framework for Elixir. Idk that I'd be qualified to tackle something like building a web framework but I'd be curious enough to look into it :)

[steveklabnik]

In my mind, and be aware of my bias here, these languages split up into three different categories:

* Has a GC, but you can remove it. This is Nim and D.

* Relies on pervasive refcounting. This is Nim if you choose that implementation, Swift.

* Has no GC. This is Zig and Rust. (Though obviously you can use refcounting in these languages, but it is as a library.)

While this focuses on a specific aspect of these langauges, I think it also represents their philosophies pretty well. Nim and D start from a "what if we had a GC" and then try to make things nicer down the stack. Rust and Zig are how nice can we go starting from nothing?"

There are also additional factors that may or may not play in here, depending on what your needs are. Arguably, Rust is starting to break out of the "niche language" stage and move into the "significant projects and is sticking around" phase, whereas many of these other languages aren't quite there yet. This can matter with things like getting help, package support... some people love the open frontiers of new languages, others want something more mature. https://nimble.directory/ has 1,431 packages at the time of writing, https://crates.io/ has 48,197.

[darthrupert]

How many of those 48,197 have over 50 lines of code? How many of them have had changes in the last 1 or 3 years?

Same questions apply to Nim too of course, but I believe Rust's focus on newbies and pretty much trivial crates/cargo new pkg addition has led to a lot of cruft in there. Not to mention squatters (even if those are probably not a majority).

Also, I would challenge your classification of ARC being in the same category as Swift, memory-handling wise. Nim's ARC has hard realtime capabilities, would that be possible with pervasive RC?

[cb321]

I agree that sheer package count is a weak metric especially for very hyped up "can I put it on my resume" prog.langs, and in the context of "maturity" (as opposed to "popularity"). I also agree that programmer attrition rate (or its complement retention rate) are a bit better.

While I cannot speak to Rust's packages, as part of testing a new Nim package manager against the published ecosystem, I happened to just a week or three ago be surveying the freshness of Nim's ecosystem. About 80% of those 1400 Nim packages have been updated in the past 2 years. By last git update, 50% have not changed since 2019/October and 30% have not had a commit since 2018/November. 50..80% fresh (with apologies to Rotten Tomatoes!) is much higher than I would have guessed naively. I am not sure even Python would score so highly. I realize these above numbers are but a start down a more real analytical road. Maybe someone could measure Rust in this way.

In terms of package quality, the one time I re-wrote something that existed in Rust in Nim, my Nim version ran like 10x faster than Rust. That was a couple years ago (https://github.com/c-blake/suggest if anyone cares) and is just one data point. I do think Rust unfairly enjoys a presumption of performance when almost any language has ways to make code run fast. Less ambitious or knowledgeable programmers can always make things slow, but they also seem biased against picking up Rust. So, there is also a sample selection bias, but this has probably all been said before.

[strokirk]

On the other hand, many many packages on https://pypi.org/ have not been updated in the last 5 years since they are essentially feature-complete. They don't need active development, the feature-set in the last published version still works.

[cb321]

It's a fair point that sometimes software is "just done". Combining the dependency graph with version freshness may yield even more informative retention/attrition metrics. { EDIT: as in "either updated in N months or a dependency of something which was". Of course, this can easily neglect reverse dependencies not in the package graph, but perfect can be the enemy of the good. :-) }

[steveklabnik]

It's funny, because everyone wants different metrics. Some people would argue that no changes in the last 3 years is a sign of maturity!

Anyone can argue any metric, and that's 100% fine. Any of these things can only be a really rough measure of anything.

[darthrupert]

Yes, Common Lisp people say that a lot. I'm sure you know why :)

[disruptek]

Nim doesn't require that you use a gc; one of its many gc options is `none`, which is, as it sounds, no garbage collector at all.

[steveklabnik]

Right, that was the “you can remove it” part.

[jibal]

But then strings and most of the stdlib aren't available to you unless you want one big massive memory leak.

[moonchild]

Sibling talks about memory management. Some other notes:

- Nim and rust have macros.

- D has very high-quality metaprogramming (probably better than any other language without macros).

- (Afaik swift and zig have fairly normal templates. I don't know as much about those.)

- D and zig have compile-time function execution (think c++ constexpr on steroids on steroids).

- Swift is likely to be the slowest of the bunch; like go, though it's technically compiled to native code, its performance profile is closer to that of a managed language. The others should be generally on par with each other and with c.

[dom96]

I would say that Nim has one of, if not the, highest quality metaprogramming among these languages. Indeed, compile-time function execution, AST manipulating macros, declarative templates and term rewriting macros are some of the metaprogramming features in Nim.

[jibal]

Nim beats D on metaprogramming.

[moonchild]

I said 'better than any other language without macros'.

Nim has macros.

[jibal]

And I said something else.