Too bad nim uses a whitespace-sensitive syntax like python, something I personally dislike.
BTW, if we are talking about things that really goes on nerve for me it is the fact that Golang doesn't compile when there is unused imports in the module, so I can't simple comment a random line and try to compile it again. But I know people that like this because they editor are configured so the import is automatically removed. Ok I guess, but I still find this behavior annoying (I would much prefer that this was a compiler warning).
I wish more languages cared about readability.
So yeah, for me it makes the language less readable, that is, it makes it harder to parse the code as I read it.
Your mileage may vary indeed...
Python using whitespace doesn't allow me to mess up and have my formatter autoformat it. Js and others with {} have way too many symbols flying around for easy parsing.
Thats why I really like crystal! Do/end, low level, elegant. Wish the devs would focus more on wasm and other features that would put it more in the spotlight.
(I still use Python, and I'm still going to try Nim some day. Syntactic whitespace is a pain, and, in my opinion, a bad design decision, but it isn't everything.)
Nim has a great feature set and will be a good fit for Python or Ruby teams wanting a more performant language. At the same time, it's more expressive than Golang and will fill a niche Golang couldn't meet.
I like that we now have Golang, Rust, Swift, Nim, and Kotlin. They're all doing new things and excelling at their own niches.
Anyways, I'm just voicing my personal gripe with the use of whitespace-sensitive syntax. Nim is a overall a good language to use.
Ideally you shouldn't need to use UI threads and instead integrate the async loop into the UI's event loop or vice versa. Happy to advise more if you can let me know which UI framework you are using :)
This being said, I am hoping to implement better support for using `spawn` and channels with async, i.e. the ability to await the result of `spawn` or a channel. I think that will make a lot of use cases much easier.
It was a bold choice by Python, but in my experience it turned out to be a poor choice, and not one to be copied.
That being said, it looks like a very exciting language and like Python I think I'd manage to enjoy it overall despite of that choice.
> It was a bold choice by Python, but in my experience it turned out to be a poor choice
Could you explain why? I've heavily used languages with explicit block delimiters as well as Python, in collaborative environments, and the significant whitespace in Python does not really cause me any trouble. There is some slight overhead of making sure of the indentation when copy-pasting, but a decent text editor will make fixing things simple.
As for the theoretical mixing of or trade-offs between tabs and spaces - that's just not a practical concern that exists in my experience.
Of course that's a matter of taste, but the whole thing just seems like a minor detail to me - especially when we have the option of code autoformatting now.
Am I missing something here that makes other people's experiences much worse?
To take the most subjective part first, for me, I just find implicit blocks much harder to parse than with explicit start/stop symbols/keywords. My eyes and brain just seem to have an easier time identifying the explicit blocks. It's like writing sentences without using a period to end them, but just three spaces say.
Yes it's a bit more verbose, but I find it really helps readability for me. This of course might very well be the way my brain works, or the way my brain learned to work as a result of my first programming experiences, hence being subjective.
A bit more objectively, in my experience it seems easier for myself and others to make mistakes at the end of implicit blocks, either having a line indented that shouldn't be or vice versa. It is my experience that with explicit blocks those faults tend to stick out like a sore thumb.
I even have an add-on for my current IDE which, amongst other issues, complains loudly about that. If the language had had implicit blocks it couldn't really do that to the same degree.
I also find explicit blocks is easier to use with tools, especially when diffing. When using a language with explicit blocks I can enable the ignore whitespace feature of the diff tool and if say an outer "if" was added, you get about two lines that changed. With implicit blocks all the lines of the block change, so you got to scan through them to make sure no "real" changes were made. I tended to spend a lot longer on non-trivial Python merges compared to say C++ due to this.
I've also had the misfortune to have to edit Python code using only simple tools, without any Python-magic or similar. It's a royal pain if you have to copy/paste code around.
But yeah, I accept it mostly boils down to preference. I mean clearly there are some more objective metrics, but how you weigh those will be subjective so, yeah...
I often find myself wondering why other languages haven't implemented support for an alternative syntax. I suspect the answer is that simply no one cares enough to put the work in, but perhaps there is a better reason.
¹ https://en.m.wikipedia.org/wiki/Vala_programming_language
² https://en.m.wikipedia.org/wiki/Genie_(programming_language)