It's very hard to take the article seriously due to the deliberate misspellings, memes and introducing pop art in a technical culture. There is a line between the ice-breaker and and overdoing it and unfortunately this article is too much on the other side.
Now let's address your points Besides embedded developers working on AVR platforms or STM32: * <https://disconnected.systems/blog/nim-on-adruino> * <https://gitlab.com/jalexander8717/msp430f5510-nim> * <https://github.com/mwbrown/nim_stm32f3> * <https://github.com/gokr/ardunimo> * <https://gitlab.com/NetaLabTek/Arduimesp> I'm probably the one who used Nim low-level features the most so let's address your points: > It has a Python-like indentation-based syntax with less flexible import > semantics. The indentation syntax has been criticized or praised ad nauseam. Regarding the import semantics, less flexible compared to what? People have been crticizing it for being too flexible (i.e. allowing non-namespaced imports). > It lacks proper object-oriented features like interfaces and mixins. Arguably, a system language should be ABI compatible with C this means that OOP which contains runtime information is better replaced by contexts and/or callbacks field which Nim supports. That said, interfaces are a fair remark but not limiting for low-level system programming in Nim as: * either they are only use for types known at compile-time, in that case concepts and/or generics fit the bill. * or they involve runtime types and we are not C ABI compatible. I don't see the point of [mixins in OOP](https://en.wikipedia.org/wiki/Mixin). In Nim all functions are freestanding, they are not tied to an object, mixins seem to be an artificial construct due to how Java requires object for every function (which is a devolution from C). > It does not have lower-level features like pointer alignment, address spaces > etc. Not true, I require pointer alignment for SIMD programming like AVX512 or creating my own memory management scheme, see: <https://github.com/mratsim/weave/blob/2e528bd2/weave/memory/allocs.nim#L101-L122> > It does not have explicit safety concepts. The only language that has more safety concept than Nim is Ada/Sparks. I'd argue that while Rust is more safe on the memory front (borrow checker), it is less safe on the type front (distinct, range) and the future Z3 theorem prover integration is very exciting to bring Nim to Ada/Sparks level (<https://nim-lang.org/docs/drnim.html>) and also enable formal verification of Nim programs (<https://github.com/nim-lang/RFCs/issues/222>) > That said, you can relatively easily wrap a C/C++ library in Nim for > lower-level features such as GPU programming, but who writes that C/C++ > library? In that sense, Nim is similar to Python and other higher-level > languages with FFI. You don't need to wrap C or C++ library to do GPU programming. Arraymancer doesn't, you can inline the C/C++ code fragments and then directly use them in actual Nim: * <https://github.com/mratsim/Arraymancer/blob/88edbb67/src/arraymancer/tensor/private/incl_kernels_cuda.nim> (kernel fragment) You can even create a compiler that ensures Nim will generate valid Cuda code: * <https://github.com/jcosborn/cudanim/blob/338be782/demo3/ex1.nim#L1-L35> Beyond GPU computing, Nim is also the best language to write cryptography libraries in. Those are very stringent demand that make most of languages unsuitable: * No heap allocation allowed as a cryptographic library is working under unfriendly context and we should assume adversaries will try to exhaust your memory. Plus it's easier to dump secrets from heap. * Heavy use in embedded. Cryptographic libraries are even used in smart cards like bank cards and in many sensors, biometric devices, set-top boxes for Cable TV or Satellite. * Must be as fast as possible, cryptography is often a bottleneck for server and authentication, 1ms in page loading might translate to 10k+ of lost sales/impressions on commercial websites * A generic crypto library require genericity over enums and integers (i.e. dependent types) because prime numbers comes in various sizes: 254 bits, 256 bits, 381 bits, 2056 bits, 3072 bits ... and you have to stack allocate so you must be able to precompute your array sizes at compile-time otherwise the dev becomes a human compiler. * Assembly support: for both speed and security. Compilers are extremely bad at optimizing big integer arithmetic (compared to say floating point as used in scientific computing), also some of their "optimizations" like introducing branches compromises the security of a cryptographic library. As a simple example, it is impossible to ensure that a CMOV is emitted for constant-time conditional copy. I would be pleasantly surprised if there is a language besides Nim that has as flexible assembly support for generic cryptography. For example, here is a DSL for constant-time big integer multiplication. The Assembly code is generated by the Nim compiler, integrated in the rest of the library for any required bitwidth and use the latest MULX/ADCX/ADOX instructions that compilers never use: <https://github.com/mratsim/constantine/blob/9976ac70/constantine/arithmetic/limbs_asm_mul_x86_adx_bmi2.nim#L16-L197>.
