Hacker News Reader

Comment by enitihas | Hacker News Reader

I too was enthusiastic about using Nim, as it is clearly a much superior language to go. However, the ecosystems are not at all comparable. Even without considering the huge amount of 3rd party packages for go, the go stdlib itself is too good and has almost all batteries included. For Nim, if you are going to develop any non trivial program, it is going to be really difficult to find the relevant libraries.

View on HN

I thought so too about Nim, but then I realized how easy it is to call c libs from nim. There is infinate amount of c and c++ libs out there.

Does calling C++ libs work in the latest version of Nim though? I mean real C++ interfaces, not C ones that just happen to use C++ in their implementation.

Works for me:

Wrapping a C++ header-only template library: https://github.com/status-im/nim-ttmath

Generating Cuda C++ Functor: https://github.com/mratsim/Arraymancer/blob/master/src/tenso...

Yes, and as far as I'm concerned Nim has one of the best C++ interop capabilities out of any language bar C++ itself.

I disagree. Nim is very much a batteries included language and has a very healthy range of libraries available in the set of standard libraries. The lack of of 3rd party modules is a little problematic, but the large number of standard libraries and good C FFI can help mitigate this. Go is definitely the more supported and mature language, but Nim still has a lot going for it.

i don't understand why people make these kinds of criticisms. everyone already understand that the assumption for a new language that the ecosystem won't be as rich. you're basically saying something akin to "x high school football player is much worse than y professional football player in a professional game". of course. judge them in context.

>i don't understand why people make these kinds of criticisms.

Because language age doesn't make a difference. People have to actually use the language, and this is a practical concern.

If you were choosing to put a high school football player or an NFL player on your team right now it'd be an easy choice, wouldn't it?

Go has a wealthy patron and a "rockstar" principal dev so it wins the popularity contest. Vue has also been playing third fiddle to the big boys for some time but people are coming around. There is no reason why Nim can't have its moment in the sun too.

>People have to actually use the language, and this is a practical concern.

do they? is it in the rules of building languages and ecosystems that every new language has to be production ready from day 1? it is also possible that you can use it for hobby projects and that that's sufficient merit to talk about it and have posts about it too.

What on earth are we comparing when discussing Nim vs. other languages, if not the language itself, in practice? Are we just discussing how good you feel about it?

My point is, this is an actual deficiency that you need to consider when evaluating Nim, that isn't just a function of the language being new. For example, Zig is another option which puts any C libraries at your fingertips, without requiring bindings. If Nim had better interop (not just relatively good, but zero effort) this would no longer be a concern and you wouldn't need all of your libraries to be in Nim.

>if not the language itself, in practice?

...

>However, the ecosystems are not at all comparable.

......?

Not sure what you're getting at. People in this thread are discussing what it's like to use Nim, including its ecosystem, vs. other languages and ecosystems. You don't seem to have anything substantive to add to that other than that Nim is "new" which as I mentioned isn't relevant to the experience of actually using it.

you asked about merits of the language itself. what does the ecosystem have to do with the language /itself/

If we're using that logic, then nim is only ready for high school level applications?

Objectively, it's very hard to say. But practically, yes. Smart people building critical systems do not run to relatively untested languages, no matter how good they may look.

But... there's a loooooot of "high school level" applications out there in the world. And the way a language graduates up to the higher classes is getting tried out in the "lower criticality" systems, and getting experience.

I wouldn't try to build an S3 competitor in Nim right now, no matter how good it may look. But even a company building an S3 competitor in some other language could still have tons of other places Nim would be a fit.

> Smart people building critical systems do not run to relatively untested languages, no matter how good they may look.

Except they do, if the new untested language is qualitatively better than the old one. For example, a critical crypto algorithm in Firefox is written in F* and compiled to C: https://blog.mozilla.org/security/2017/09/13/verified-crypto... . The new implementation is formally verified free of certain classes of bugs (like buffer overflows), and significantly faster than the hand-written C implementation.

Nim generates C and compiles it using GCC. It does not inject a runtime that runs its own threads or any other magic.

All the usual static analysis tools, debuggers and even formal methods can be used on the generated C code.

>If we're using that logic, then nim is only ready for high school level applications?

i see no problem with this but i think JS is only ready for high school level applications too.

Nim has been around since 2008, Go since 2009.

Go has had Google's money behind it since 2009, Nim was developed fully by volunteers since 2008.

> However, the ecosystems are not at all comparable.

Really?

https://github.com/VPashkov/awesome-nim

You can install Nim packages easily with nimble.

https://github.com/nim-lang/nimble

Not a fan of Go and actually like nim but https://github.com/avelino/awesome-go

Also for people actually targeting production there is hufe dif. between say DB driver that is used in literally millions of projects and has a large number of active maintainers and DB driver written by 1 dude that has not commited any fixes in 12 month

Looks impressive. However, since Nim has such an easy C/C++ FFI you have to consider also all C and C++ APIs. That looks superior even to Go, unless Go's C FFI is as easy as Nim's.

https://github.com/kozross/awesome-c

https://github.com/aleksandar-todorovic/awesome-c

https://cpp.libhunt.com/

https://github.com/fffaraz/awesome-cpp

That is true but up to a point say I want production ready async PG driver FFI does not help me much

For a while (before I found zig) I was looking for a language to do my hobby development in. Most newer languages lack a comprehensive library ecosystem, but I'm not a fan of having a giant web of dependencies anyway so one of my criteria was "how much would I dread writing my own X?". You always take a productivity hit when starting out in a language anyway, and making your own libs that interact with real code and data gives you a much better feel for how a language is going to work in the real world than more common "hello world"-like exercises do in my opinion.

Reply on news.ycombinator.com