6 ms·
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 conside
by enitihas 8y ago
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.
- treeform 8y agoI 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.
- jhasse 8y agoDoes 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.
- mratsim 8y agoWorks for me: Wrapping a C++ header-only template library: https://github.com/status-im/nim-ttmath https://github.com/status-im/nim-ttmath Generating Cuda C++ Functor: https://github.com/mratsim/Arraymancer/blob/master/src/tensor/private/incl_kernels_cuda.nim https://github.com/mratsim/Arraymancer/blob/master/src/tenso...
- dom96 8y agoYes, and as far as I'm concerned Nim has one of the best C++ interop capabilities out of any language bar C++ itself.
- nepeckman 8y agoI 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.
- mlevental 8y agoi 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.
- overcast 8y agoIf we're using that logic, then nim is only ready for high school level applications?
- mlevental 8y ago>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.
- jerf 8y agoObjectively, 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.
- nimmer 8y agoNim 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.
- yawaramin 8y ago> 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-cryptography-firefox-57/ 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.
- AnIdiotOnTheNet 8y agoFor 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.
- progman 8y ago> However, the ecosystems are not at all comparable. Really? https://github.com/VPashkov/awesome-nim https://github.com/VPashkov/awesome-nim You can install Nim packages easily with nimble. https://github.com/nim-lang/nimble https://github.com/nim-lang/nimble
- qaq 8y agoNot a fan of Go and actually like nim but https://github.com/avelino/awesome-go 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
- progman 8y agoLooks 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/kozross/awesome-c https://github.com/aleksandar-todorovic/awesome-c https://github.com/aleksandar-todorovic/awesome-c https://cpp.libhunt.com/ https://cpp.libhunt.com/ https://github.com/fffaraz/awesome-cpp https://github.com/fffaraz/awesome-cpp
- qaq 8y agoThat is true but up to a point say I want production ready async PG driver FFI does not help me much