[0815test]

> For HNers, it's an opportunity to still make a huge difference by contributing to a relatively young language

It would be better for someone to work on an alternate, Python-like input syntax (focusing on readability and good intuition, and perhaps more attractive to novice programmers) for some established language, like Rust. Working on a "young" language, you just miss the chance of contributing to an ecosystem that's already been in development for quite some time, and where efforts aren't going to be left stranded as the bulk of the dev community chooses to go for something else.

[jamieson-becker]

> for some established language, like Rust. Working on a "young" language, you just miss the chance of contributing to an ecosystem that's already been in development for quite some time

Would you still make this point if you were comparing...

for example, Rust and C++?

... where Rust is the "young" language? Working on such a young language (and, FWIW, Rust is younger than Nim), you might miss the chance of contributing to an ecosystem that's already been in development for quite some time.

Not every language grows up with a silver spoon from Mozilla or Google.

[0815test]

Given that C++ is widely regarded as having unfixable problems (and even the ISO-C++ community is now basically admitting this, with the C++ Core Guidelines being nothing more than a somewhat pointless band-aid), yes I would. If C++ was fixable, Rust would not exist in the first place. (Same goes for e.g. Ada btw - if you could simply fix both the clear lack of openness in the available Ada toolchains, and its lacking anything comparable to the Rust borrow checker, Rust would also not need to exist.)

I can tell why Nim was created - there is a somewhat widely felt need for a systems language (Nim is clearly targeting C/C++ compatibility) with a more Pythonic input syntax! But it's far from clear that Nim itself as it exists today is a sensible answer to these issues.

[otabdeveloper1]

> is widely regarded

Yeah, citation needed, d00d.

> with a more Pythonic input syntax

A 'more Pythonic syntax' is literally the least important requirement anybody needs in a programming language.

[Symmetry]

There are things about Nim, like the thread local garbage collected heaps, that you can't really replicate in Rust. Sometimes you want garbage collected language because it makes your life easier. Sometimes you don't because you're a library or realtime or you want to optimize the hell out of your code.

[0815test]

Pluggable GC heaps or the like will likely become possible in Rust at some point. We can already see some of the groundwork being provided, e.g. with support for things like custom, user-specified allocators (at a local, not whole-program level - this is not yet in Rust, but definitely in the pipeline!)

It's just a bit silly to couple one's choice of language/ecosystem/etc. to a single memory-management strategy, and the Python/Nim-like choice of obligate GC as an extension to obligate reference counting also seems a bit puzzling. That's basically taking every sort of automated memory management under the sun and compounding their disadvantages - I'd think one can do better than that, in fact even Go or Ocaml do better than that!

[ddragon]

I'd say there isn't really a better general option. Some people may want to target the largest amount of people right out of the gate, some people might want to be a big fish in a (growing) small pound. Some projects might have so many (possibly non core) dependencies that it's too hard to start from scratch without already existing mature tools, some projects you might want to start from scratch anyway so might as well use a more modern language that will give it some edge.

I think the only globally optimal option in hobby open source projects is doing whatever seems more fun for you, and for many people is using that language that no one uses (or making your own language that no one uses).

[steveklabnik]

https://github.com/mystor/slag