3 ms·

I do like Nim also. The only problems are the usual ones plus one: - IDEs ecosystem (both for D and Nim) - libraries Additionally, Nim departs quite a bit fro

I do like Nim also. The only problems are the usual ones plus one: - IDEs ecosystem (both for D and Nim) - libraries Additionally, Nim departs quite a bit from C/C++ to look more than Python. As nice as it looks, Nim is not Python, it has a ton more qualifiers and others. It is fast, but it departs from C/C++ a lot and there is much more than it is apparent to relearn. D's path is smoother in that sense. Also, C/C++ compatibility is a problem. Yes, I know you could say Nim is very compatible with C. But at the end of the day is a considerable investment of extra work. If it does not work, if it works half-way even if compatible in theory. I have been there many times, I code hybrid in many occassions with scripting layers that are supposed to work, and at the end, there is extra work...

cb321 4y ago
Sorting out your edit/IDE/lib situation & re-learning is part of any PL switch in my experience (& just varies). Trade offs abound in most things. D is undeniably syntactically closer to C if that is the priority. I knew people in the initial Java era who insisted their next PL had to look like C. I know others who prefer Pythonic brevity and Nim is even more brief & to the point in many ways. Compatibility-wise, Nim can also just `emit` C/C++/Javascript (like D|Nim can just emit inline assembly) - arguably max compatibility that can even work with arbitrary non-portable backend compiler pragmas, `__int128` extensions, etc. OTOH, that also ties it to limitations of backends. Possibly relevant is https://github.com/nim-lang/c2nim https://github.com/nim-lang/c2nim & https://github.com/PMunch/futhark https://github.com/PMunch/futhark & the rather old/probably partly stale in both columns https://github.com/timotheecour/D_vs_nim https://github.com/timotheecour/D_vs_nim . There are many choices in Nim. Sometimes https://en.wikipedia.org/wiki/The_Paradox_of_Choice https://en.wikipedia.org/wiki/The_Paradox_of_Choice can be a real problem - in both software or in life - and at many, many levels. :) I am not trying to challenge your own priorities or push choices on you, but to add information others may be unaware of.
- germandiago 4y ago
  > I am not trying to challenge your own priorities or push choices on you, but to add information others may be unaware of. Not at all. I enjoy researching this topic. Thank you!

cb321 4y ago

Sorting out your edit/IDE/lib situation & re-learning is part of any PL switch in my experience (& just varies). Trade offs abound in most things. D is undeniably syntactically closer to C if that is the priority. I knew people in the initial Java era who insisted their next PL had to look like C. I know others who prefer Pythonic brevity and Nim is even more brief & to the point in many ways. Compatibility-wise, Nim can also just `emit` C/C++/Javascript (like D|Nim can just emit inline assembly) - arguably max compatibility that can even work with arbitrary non-portable backend compiler pragmas, `__int128` extensions, etc. OTOH, that also ties it to limitations of backends. Possibly relevant is https://github.com/nim-lang/c2nim https://github.com/nim-lang/c2nim & https://github.com/PMunch/futhark https://github.com/PMunch/futhark & the rather old/probably partly stale in both columns https://github.com/timotheecour/D_vs_nim https://github.com/timotheecour/D_vs_nim . There are many choices in Nim. Sometimes https://en.wikipedia.org/wiki/The_Paradox_of_Choice https://en.wikipedia.org/wiki/The_Paradox_of_Choice can be a real problem - in both software or in life - and at many, many levels. :) I am not trying to challenge your own priorities or push choices on you, but to add information others may be unaware of.

germandiago 4y ago
> I am not trying to challenge your own priorities or push choices on you, but to add information others may be unaware of. Not at all. I enjoy researching this topic. Thank you!