> I don't think the doc for getAppFileName is confusing per se, it just doesn't > have sufficient detail on semantics to be sure what the output is going to be > before trying it out. So it leads to surprises. Not a big one, but if there > are a lot of little things like that, you end up with people feeling "death > by 1000 paper cuts".
I am not saying that I am a seasoned programmer but I do know quite a few of those languages. Do you know what languages can cause "death by 1000 paper cuts"? C++ of course, and Rust, which is C++ 2.0, these languages kill lots of guys day by the day. And we all know why they kill people. It's because of history! Why did UNIX took off? Was UNIX excellent and secure? No, but it worked. And that is why C took off as well. I've got nothing against C, but today everyone can see the downsides of C. Manual memory management was not very clever, especially when you have a large code base. Yes, you can do clever tricks with C, but when you need to modify your own trick later on, you ask yourself WTF. And this counts for everything that I have seen so far, all programming languages suck in one way or the other. I am still learning Nim but so far I haven't seen that many things that sucks. If you want to have a proper rationale of why to use Nim, go read this: <https://forum.nim-lang.org/t/9655> But I agree that documentation of Nim could be a lot improved. That is also a problem of the networking effect. When you don't know the language you don't know it. So you also don't hear a lot about it. The number of articles that discuss Nim is small. When you go into Youtube there is not a lot about Nim. There is plenty of stuff around Rust and Python, but no Nim. That is the unfortunate truth. But when people are searching for it and find out the possibilities, then they discover soon enough that it's not a hoax. Nim is very clever engineering, and that counts for the tooling as well. So I think that the future of Nim looks very good.
