3 ms·
This uses the code snippets from http://rosettacode.org/wiki/Rosetta_Code http://rosettacode.org/wiki/Rosetta_Code . I wrote many of the Nim ones and collected
by def- 12y ago
This uses the code snippets from http://rosettacode.org/wiki/Rosetta_Code http://rosettacode.org/wiki/Rosetta_Code . I wrote many of the Nim ones and collected them over at http://github.com/def-/nim-unsorted/ http://github.com/def-/nim-unsorted/ . But since the Rosetta Code tasks are often not 100% specified, I'm not sure how useful this comparison is. For what it's worth I mostly oriented on Python and C when writing the Nim ones. I also don't know why this comparison uses the old Nimrod name, seems to work with Nim as well: http://rosetta.alhur.es/compare/nim/go/# http://rosetta.alhur.es/compare/nim/go/#
- jerf 12y agoYes, the more I look at these, the less similar the two sides often seem to be. Not that I'd ever challenge the claim that Nimrod generally focuses on concision whereas Go is intended for environments in which such concision is generally discouraged and the two languages have perfectly predictable line counts on this sort of task after that, but the comparisons are definitely less meaningful than a first glance indicates for a lot of these. For instance, see "Box the Compass"; codewise the two aren't that different (Go is both slightly longer and appears to carry more information, it has more numbers in it for whatever reason), but the eye is initially misled by the fact that Go has a standardized formatting and the definition of a string array is rigidly required by the formatting rules to have one string per line, whereas Nim happily puts them on just a few lines. Neither is wrong, and, well, it goes back to that context I mentioned. Both languages have their reasons for that. Others, such as the matrix arithmetic, are pretty accurate... I think you're crazy to pick up Go and immediately start trying to do serious math, personally, but YMMV.