The advanced features Nim offers is in stark contrast with Go where simplicity is valued. But the power those features give you when you really need them is undeniable. There's no need to dance around certain problems.
I did move to Go from Python briefly for performance reasons but once I found Nim, there's just no going back. Simplicity might have real value in large projects but I just don't like my hands tied.
Nim is written in Nim and no one has run into this style insensitivity confusion despite many people contributing. If your project is smaller or fewer people and you still think this is a big issue, good luck. And if it is larger, this is the least of your concerns.
Think in reverse, is it a useful language feature to have MyNimName, mynimname, MY_NIM_NAME, My_Nim_Name, __MYNIM___name_ be different? When did you need this flexibility recently? Are we really so limited at naming things appropriately?
It's fine to make a big deal about something in theory but if it really was such a dumb idea it would have died over the decade Nim has been around. It was debated again prior to 1.0 and persisted, several good reasons are also mentioned in this thread. And it isn't even an original idea as brought up by several others.
If this is the reason someone doesn't try Nim then it's only unfortunate for them. Add this to the tabs vs. spaces, curlies vs. whitespace indentation or other so called concerns which make no difference in the grand scheme of things.
This precisely. Try getting help from the creator of Go, it's next to impossible unless you work at Google or are a core Google dev. The Nim author on the other hand is very active on IRC and the Nim forum.
Every language has faced challenges with change, nothing specific to Nim. And 1.0 is a distraction, if the language version has all the features you want, you can use it as long as you want. The code is also open and an unbearable bug can be easily backported.
If you do want the new cooler features, then ya, you may need to port your code but that's the case with any compiler update - you need to run a full regression at the very least.
1.0 _may be_ a distraction but I think it's a fair one. It's a common enough convention that pre-1.0 versions are the developer's way of saying, "please please please don't treat this as ready and production quality. We're still figuring some things out and haven't settled on some key choices."
If that's not what the developers are trying to communicate with a pre-1.0 version I do wonder what they're gating 1.0 on. What needs finalization? Documentation?
Totally feasible, I ported Python code to Nim and it was super easy and I got a huge performance boost.
If performance isn't a big deal, the other thing I've noticed is that compilation guarantees a much higher quality of code compared to interpretation. At least compared to Python, I have been hit by bad code which didn't get caught because there was no test for it. I've not faced that with Nim yet.
No doubt you can still have issues but it's one less thing to worry about.
I did move to Go from Python briefly for performance reasons but once I found Nim, there's just no going back. Simplicity might have real value in large projects but I just don't like my hands tied.