The comparison is terrible and almost every sentence is dubious. > Features like macros and OOP offer even more ways to solve problems and > increase complexity.
Maybe there is a reason why many other new languages like Julia, Elixir, Rust also have macros. > I'll post a detailed article about the power of immutable strings. Spare me, I know the advantages and disadvantages and mutability wins whenever you start to optimize the string handling and stop passing them around pointlessly like they are cheap. They are not. Yeah, yeah, I know, I know, you don't have a GC but "automatic MM", so you use atomic reference counting for strings ... which is slow: [https://jjacky.com/2013-03-16-strdup-free-vs-atomic-reference-counting](https://jjacky.com/2013-03-16-strdup-free-vs-atomic-reference-counting)/ On top of that the mutable strings give us consistent language _semantics_ , you know, this thing most programmers keep confusing with syntax. > Nim allows importing functions into global namespace. This becomes a huge > problem when working on large code bases. Explicit imports that V, Go, Oberon > have are much more practical: pkg.function() vs function(). You're free to write `pkg.function` everywhere. But not everybody spends the day musing about where stuff has been declared, some people can use an IDE effectively and actually fix bugs instead and work on new features. I dunno. > It's also possible to embed C code in Nim, which reduces safety and > portability. Sure, much like having legs is bad since you can break your legs. > This is a small segment copied from a simple hello world program: Sure, show something from a debug build and don't show us the produced assembler. > This must be one of the reasons it compiles almost 100 times slower than V. Or maybe it's because Nim is more effective than V at solving the problems it was designed to solve. Not everybody believes in programming language designer fascism. > V's syntax is a lot cleaner with much fewer rules. Lack of significant > whitespace improves readability and maintainability of large code bases and > makes generating code much easier. "Much easier"? No, and just one minute ago you indirectly claimed that producing "readable" C/machine code is an advantage so you better produce code with the whitespace anyway. > The list can go on and on. Yeah no shit, please go on since so far no convincing argument has been found.
