5 ms·
People complain about lack of generics and proper try/except/finally in Go. Nim has both.
by lactobacillis 6y ago
People complain about lack of generics and proper try/except/finally in Go. Nim has both.
- sagichmal 6y agoAnd no native concurrency.
- throwaway_pdp09 6y agoIt's not my area but, surely concurrency can be added, and why does it need to be native? Surely a library is fine. (I chose not to learn go because of it's lack of generics and exceptions. It seemed like a huge step backwards)
- PMunch 6y agoNim has thread support natively. And an async implementation in it's standard library which is made entirely as a library, so you're free to write your own, in fact there exists alternative implementations of async/await in Nim. Just the fact that a feature like this _can_ be implemented as a library is a testament to how powerful of a language Nim is.
- navdb 6y agoRelated article on Nim concurrency: https://onlinetechinfo.com/concurrency-and-parallelism-in-nim/ https://onlinetechinfo.com/concurrency-and-parallelism-in-ni...
- beagle3 6y agoWhy do you say that? It's far from perfect but it does work (and has for a few years), and it helps you by requiring proof that actions are disjoint. There is work now on including Z3 which would work this much smarter. https://nim-lang.org/docs/manual_experimental.html#parallel-amp-spawn-parallel-statement https://nim-lang.org/docs/manual_experimental.html#parallel-...
- benibela 6y agoThen let's ask instead, why use Nim over Pascal?
- pjmlp 6y agoActually type safe, with support for various kinds of automatic memory management. Pascal dialects, while much safer than C, suffer from use-after-free and possible memory leaks, also you don't need to mark unsafe code as such. This includes any modern Pascal variant.
- The_rationalist 6y agoWhy use nim over Kotlin with AOT?
- beagle3 6y agoI'm not familiar enough with Kotlin to give a real answer, but from what I do know the following might be relevant: * Backends: Nim compiles to JS both directly, and indirectly (emscripten) with various trade-offs (e.g. 64 bit ints require emscripten). It also compiles to C, C++ and Objective C giving you the simplest most efficient FFI to those languages one can hope for (including e.g. exception handling) while at the same time addressing the largest set of platforms (got a C compiler? you can use Nim). And you also have (almost but not yet quite production quality) native code compiler NLVM. What's the platform range of Kotlin's AOT? * Metaprogramming: Nim's metaprogramming ability is second only to Lisp[0], I think, and only because Lisp has reader-macros (whereas you can't ignore Nim's syntax with macros, as flexible as it is). For example, Nim's async support (comparable to Python and C#) is a user-level library. So is, for example, pattern matching. Can Kotlin do that? * Size: Nim compilation through C produces standalone and (relatively) tiny executables; it matters for embedded platforms. How does Kotlin fair in this respect? [0] Lisp, scheme and other Lisp derived languages, of course.
- draegtun 6y ago>> Metaprogramming: Nim's metaprogramming ability is second only to Lisp[0], ... There are some other languages that have metaprogramming abilities equal to Lisp. For eg. Rebol, Red & Forth. I think some people would also consider Prolog and Smalltalk to be in the same ballpark. And there are languages that would also claim to be second only to Lisp, for eg. Julia, Elixir, Raku/Perl6 and probably some others to!