First of all, thanks to everyone who put their time into reading my article(s).
🙏 ### On Experience I by no means pretend to be a person having deep knowledge in **any** programming language, nor programming concepts in general. I do not have a PhD in computer science nor did I commit a single line into LLVM. What I objectively have is an experience in a wide selection of programming applications from games to web frameworks and database drivers. Note that experience does not necessarily mean writing. Reading also gives knowledge. I can read other peoples' writings. Instead of fighting the borrow checker in person, I'd rather read about it and learn how it can be improved. I'd rather learn from others' mistakes. Or, I can read documentation to have a full understanding of a technology. Claiming that one is required to have practical experience in a technology in order to judge it is simply a gatekeeping because if I change my mind, it would then mean either initially poor documentation or emotional bias after use. ### On System Programming Languages Most technologies involved in the topic of system programming have good documentation. Therefore, I'm not required to have years of practical experience in either one to be able to see its downsides. Although, I do in Crystal. I did examine existing system programming languages, learned how machines work on the deepest level and came to a conclusion that right now there is a lack of human-friendly system programming languages able to reveal full machine potential. I see that ubiquity of suboptimal applications leads to waste of resources and thus stagnation of the human civilization. I believe that popularization of system programming by introducing a (more) human-friendly language would lead to an increase of system programming applications, such as medical researches. This, in turn, would improve my own quality of life, as well as move the entire civilization forward, faster. After more than a year spent on designing the language, I'm revealing my work in progress. Just to say "hey, I'm working on such a big thing, join me or support me financially". It is your choice either to follow me or to ignore me. ### On Nim I see Nim as an "ally" of Onyx, akin to Python and Ruby, as they are being orthogonally different in terms of concepts, syntax and overall mindset. In fact, Onyx is Crystal made right. And Crystal's friends with Nim, isn't it? So is Onyx. To be honest I'm surprised by the amount of effort some of you put into the replies. And these kind words... Thank you. I still believe that Nim is not suitable for real lower-level programming, though. All the examples by @mratsim imply wrapping C/C++ function calls, even aligned allocations. As I've already stated in the article, wrapping C/C++ (even inline, as in the CUDA kernel example) is not a solution, because it's still C/C++. Honestly, I could not understand @mratsim's argumentation regarding interfaces. Please, fix your punctuation. What I can say is that in Onyx, the language is a black box with export and import points, so any crazy stuff like complex types (which are related to interfaces implementation in Onyx) is allowed without any ABI constraints. > I don't see the point of mixins in OOP. That's a statement I don't agree with you on. The composition is a crucial feature allowing to have an expressive hierarchy of behaviour. I believe that OOP is must-have for big projects. FP is indeed fancy, but it is not usable in real-life applications. I understand that it is a holy war topic, but that's my opinion. As OOP is not a part of Nim, I do not find it fit the utopia language idea. Also thank you, @mratsim, for fancy-schmancy wording about safety. This is new to me. Maybe I take it less seriously. For me, safety is then a program behaviour is defined in given circumstances. In Onyx, `unsafe` means undefined behaviour, while `fragile` means possible data races in a multi-threaded environment. In Rust, there is `unsafe` keyword with similar semantics, am I wrong? Nevertheless, Nim lacks this semantic at all, and there is no way for a user to distinguish between "safe" and "unsafe" areas of code. And I do judge a language from a user's perspective. Nim allows me to shoot my legs, that's unsafe. Then, > You don't need to wrap C or C++ library to do GPU programming > > you can inline the C/C++ code fragments and then directly use them in actual > Nim Come on, isn't it the same thing about still having to write C/C++? I also do not understand why you pitched Nim's application in cryptography to me. With all the downsides I mentioned in this reply and the article, you'll still have to wrap C code to do basic tasks like alignment, which is crucial for performance. ### Fin In conclusion, I want to thank all those who responded again, and repeat myself in that Nim is great with its Python syntax and FP bias. Let it be. I, no doubts, have a bias towards OOP and C-family syntax. That's why, in my world, Nim is not ideal. And I want you to explore other solutions because exploring means development. Maybe you'll pick up something new for Nim from one of my articles, who knows?
