6 ms·

Side-by-side Nim and Go

57 points by meneses 12y ago

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 ago
  Yes, 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.
chachram 12y ago
So Nim is more expressive and concise than Go. OK.
- zamalek 12y ago
  To be fair, in some cases[1] the code in Go has error handling and the code in Nim doesn't. In other cases the Go code does more things[2]. Nim is no doubt more expressive and concise than Go, but this comparison is seriously unfair in some situations. In addition, although Go is concise on the absolute scale I don't think it ever set out to be the most concise - it solves the problems that it set out to solve. [1]: http://rosetta.alhur.es/compare/nimrod/go/#Read_entire_file http://rosetta.alhur.es/compare/nimrod/go/#Read_entire_file [2]: http://rosetta.alhur.es/compare/nimrod/go/#Zero_to_the_zero_power http://rosetta.alhur.es/compare/nimrod/go/#Zero_to_the_zero_...
  - deleted 12y ago
    [deleted]
  - voidlogic 12y ago
    Not only that, on LOC is the goal; the Go code isn't written in most terse form, there are numerous unnecessary newlines and they do things like: Examples: cmd.Stdout = os.Stdout cmd.Stderr = os.Stderr vs cmd.Stdout, cmd.Stderr = os.Stdout, os.Stderr and: if open == 0 { fmt.Println("ok") } else { fmt.Println("not ok") } vs. if open == 0 { fmt.Println("ok") return } fmt.Println("not ok")
    - jbooth 12y ago
      Your first example is a great counter-point to the talk above about "if more stuff can fit on the screen it's easier to understand". I personally really prefer the 2-line construction.
- pjmlp 12y ago
  As any language designed in the last decade.
  - nailer 12y ago
    Go is only eight years old.
nailer 12y ago
I know the common wisdom in our industry is still 'syntax is a personal thing', but there's also St Exupery: 'perfection is achieved when there's nothing left to remove'. Fitting more on screen, and having a higher signal/noise ratio is /objectively better/ than otherwise. Our industry loves to measure almost everything except human parsing efficiency. I'm fairly sure we could actually test this like we test anything else (and if the test says that's wrong then fair enough).
- dagw 12y ago
  Fitting more on screen, and having a higher signal/noise ratio is /objectively better/ than otherwise. Does that mean that J/K/APL are the objectively best programming languages?
  - deleted 12y ago
    [deleted]
  - mitchty 12y ago
    Depends, can we include whitespace in on the action too?
- NateDad 12y ago
  Fitting more on screen is not objectively better, otherwise people would be talking about minified javascript is so much easier to read than python, since python wastes all that horizontal space with its newlines. And defining what is signal and what is noise is pretty subjective. Pythonistas would say that braces are noise. Most people who use languages with braces would say they're signal.
  - nailer 12y ago
    You state your view as fact, but you haven't considered some very obvious things that would normally be prerequisites to having that level of confidence: - Minified code, including code written by humans that don't know how to name things, is quite obviously a separate issue, with a very different effect on parsing efficiency, than the use of unnecessary tokens. - Of course existing programmers have biases. Measure parsing efficiency using people who aren't already programmers. Responding to natedad below (rate limit): > There are a lot of tokens which are not strictly necessary, but which make a programmer's job easier. Which ones? > There's more to designing a language than making it use as few tokens as possible... Yes, but none of those things mean that efficiency is not important. Responding to reitanqild: My statement 'Minified code, including code written by humans that don't know how to name things, is quite obviously a separate issue' also neatly covers J/K/APL. If there's anything else you've think I've not responded to, please actually state exactly what it is.
notacoward 12y ago
This doesn't look like a good-faith apples to apples comparison. Consistently, the Nim example just includes the core functions while the Go example includes that plus main() plus file-level boilerplate. Those aren't functionally the same. The funny thing is that (AFAICT) the point about Nim's greater expressivity would be even clearer without those misleading differences, and without all of that spurious vertical whitespace too.
- rbehrends 12y ago
  It isn't. It's a rather mechanical comparison of Rosetta code fragments. It can be useful if your question is: "I know language A, how do I do the same thing in language B?" As a straight-up comparison of two languages, it seems to be fairly useless.
- jerf 12y ago
  Honest question, as I don't know Nim... does it require any more, or are those legal programs as-is? I know, for instance, that you can simply run a Python program, no boilerplate required, and Python answers to these questions would have 0 bytes of visible boilerplate to "run". It's a reasonable observation that Go does have a bit of mandatory boilerplate.
  - def- 12y ago
    Those are full, runnable programs. Nim's boilerplate is similar to Python's here.
    - jerf 12y ago
      Thank you.
moe 12y ago
Sadly my browser times out at "Waiting for cdnjs.cloudflare.com", so I only see a rather busted version of the page (or is the odd whitespace preceding the Nim-examples intentional?). But the little I can see looks very promising, thanks for compiling this! Will definitely check back when Cloudflare has their act together again.
aikah 12y ago
This has to be the worse performing webpage I ever visited. It looks like hljs has so much code highlighting to do it blocks the UI thread or something.
adwhit 12y ago
For those who are confused - this website is just a rendering of Rosetta Code snippets. You can change the URL to display any two language e.g. http://rosetta.alhur.es/compare/rust/c/ http://rosetta.alhur.es/compare/rust/c/ So it is not and is not meant to be 'fair', just a nice way to compare language idioms.
donatj 12y ago
The as you scroll syntax hilighting is not getting along with my iPad at all.
jryan49 12y ago
This website doesn't seem to render correctly for me. It's also the slowest thing ever.
- agumonkey 12y ago
  It's impressively random. Scrolling helps, sometimes. Sometimes slow, sometimes not. An interesting case.
- sirlantis 12y ago
  Switched from Chrome to Firefox, works there.
  - ricardobeat 12y ago
    This website only works in Firefox. A rare occurrence.
- dkuntz2 12y ago
  If you change the URL from nimrod to nim it works.
tromp 12y ago
Are these the only two programming languages that are also well-known games? http://en.wikipedia.org/wiki/Nim http://en.wikipedia.org/wiki/Nim http://en.wikipedia.org/wiki/Go_%28game%29 http://en.wikipedia.org/wiki/Go_%28game%29
- amaranth 12y ago
  Rust is also the name of a fairly popular video game.
  - steveklabnik 12y ago
    Fun quirk: the game has _also_ been in a pre-release state for a long time, there were a ton of people who rejoyced when they heard we hit beta, then realized it was the wrong Rust... I'm sure the final in five weeks is gonna be the same way.
- antisuji 12y ago
  Indeed, when I clicked on the link I irrationally expected some kind of comparison between Nim positions and Go endgames. Color me disappointed.
tempodox 12y ago
What are those zillions of empty lines under “Nimrod” for? No code needed?
- jmulho 12y ago
  Try Firefox.
  - tempodox 11y ago
    Even in Firefox, formatting looks broken. We should add consistent rendering in a browser to the Rosetta tasks.
phantom_oracle 12y ago
I always thought Nim would be a better systems language to invest time in, but when looking at the code-snippets side-by-side, the Nim code gets really confusing whereas the Go code has nicer 'flow' and is more readable (ironic, considering that Nim claims to be Pythonic). I'm definitely not going to bash Nim against Go, but to me, code like this: proc det[M,N](a: Matrix[M,N]): float = let n = toSeq 0..a.high is unreadable. There's about as much (if not more) types of brackets in the Nim code compared to the Go code and I am moving towards an opinion that Nim is very unlike Python in readability (it may take things like indentation, no ";" and no " { } ", but Nim code is definitely not like Python in many other ways). Also, apart from the brackets, it has things like: "(a: Matrix[M,N]): float = " which would not be clear to an average programmer unless he/she actually went out to "learn" the ways of Nim (whereas Python code is very readable, even if you just know basic programming). Maybe this is due to the way the writer of each snippet writes their code, but as far as readability goes, Go wins on this one.
- tuan5 12y ago
  Obviously NIM author was trying to compare lines of code is shorter than Go. The readability issue is really scared me off NIM.
- jeremyjh 12y ago
  Any programmer who understands generics can easily understand that signature.
- jaws- 12y ago
  http://rosetta.alhur.es/compare/nim/go/#Matrix_arithmetic http://rosetta.alhur.es/compare/nim/go/#Matrix_arithmetic Nim: proc det[M,N](a: Matrix[M,N]): float = let n = toSeq 0..a.high for sigma, sign in n.permutations: var x = sign.float for i in n: x *= a[i][sigma[i]] result += x Go: func determinant(m [][]float64) (d float64) { p := make([]int, len(m)) for i := range p { p[i] = i } it := permute.Iter(p) for s := it(); s != 0; s = it() { pr := 1. for i, σ := range p { pr *= m[i][σ] } d += float64(s) * pr } return } I don't know anything about Go or Nim, but the Nim version looks infinitely more readable to me.
federico3 12y ago
Regardless of the website, I'm amazed to see Nim once again on HN. The language looks really underrated to me.

57 points by meneses 12y ago

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 ago
Yes, 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.

chachram 12y ago

So Nim is more expressive and concise than Go. OK.

zamalek 12y ago
To be fair, in some cases[1] the code in Go has error handling and the code in Nim doesn't. In other cases the Go code does more things[2]. Nim is no doubt more expressive and concise than Go, but this comparison is seriously unfair in some situations. In addition, although Go is concise on the absolute scale I don't think it ever set out to be the most concise - it solves the problems that it set out to solve. [1]: http://rosetta.alhur.es/compare/nimrod/go/#Read_entire_file http://rosetta.alhur.es/compare/nimrod/go/#Read_entire_file [2]: http://rosetta.alhur.es/compare/nimrod/go/#Zero_to_the_zero_power http://rosetta.alhur.es/compare/nimrod/go/#Zero_to_the_zero_...
- deleted 12y ago
  [deleted]
- voidlogic 12y ago
  Not only that, on LOC is the goal; the Go code isn't written in most terse form, there are numerous unnecessary newlines and they do things like: Examples: cmd.Stdout = os.Stdout cmd.Stderr = os.Stderr vs cmd.Stdout, cmd.Stderr = os.Stdout, os.Stderr and: if open == 0 { fmt.Println("ok") } else { fmt.Println("not ok") } vs. if open == 0 { fmt.Println("ok") return } fmt.Println("not ok")
  - jbooth 12y ago
    Your first example is a great counter-point to the talk above about "if more stuff can fit on the screen it's easier to understand". I personally really prefer the 2-line construction.
pjmlp 12y ago
As any language designed in the last decade.
- nailer 12y ago
  Go is only eight years old.

nailer 12y ago

I know the common wisdom in our industry is still 'syntax is a personal thing', but there's also St Exupery: 'perfection is achieved when there's nothing left to remove'. Fitting more on screen, and having a higher signal/noise ratio is /objectively better/ than otherwise. Our industry loves to measure almost everything except human parsing efficiency. I'm fairly sure we could actually test this like we test anything else (and if the test says that's wrong then fair enough).

dagw 12y ago
Fitting more on screen, and having a higher signal/noise ratio is /objectively better/ than otherwise. Does that mean that J/K/APL are the objectively best programming languages?
- deleted 12y ago
  [deleted]
- mitchty 12y ago
  Depends, can we include whitespace in on the action too?
NateDad 12y ago
Fitting more on screen is not objectively better, otherwise people would be talking about minified javascript is so much easier to read than python, since python wastes all that horizontal space with its newlines. And defining what is signal and what is noise is pretty subjective. Pythonistas would say that braces are noise. Most people who use languages with braces would say they're signal.
- nailer 12y ago
  You state your view as fact, but you haven't considered some very obvious things that would normally be prerequisites to having that level of confidence: - Minified code, including code written by humans that don't know how to name things, is quite obviously a separate issue, with a very different effect on parsing efficiency, than the use of unnecessary tokens. - Of course existing programmers have biases. Measure parsing efficiency using people who aren't already programmers. Responding to natedad below (rate limit): > There are a lot of tokens which are not strictly necessary, but which make a programmer's job easier. Which ones? > There's more to designing a language than making it use as few tokens as possible... Yes, but none of those things mean that efficiency is not important. Responding to reitanqild: My statement 'Minified code, including code written by humans that don't know how to name things, is quite obviously a separate issue' also neatly covers J/K/APL. If there's anything else you've think I've not responded to, please actually state exactly what it is.

notacoward 12y ago

This doesn't look like a good-faith apples to apples comparison. Consistently, the Nim example just includes the core functions while the Go example includes that plus main() plus file-level boilerplate. Those aren't functionally the same. The funny thing is that (AFAICT) the point about Nim's greater expressivity would be even clearer without those misleading differences, and without all of that spurious vertical whitespace too.

rbehrends 12y ago
It isn't. It's a rather mechanical comparison of Rosetta code fragments. It can be useful if your question is: "I know language A, how do I do the same thing in language B?" As a straight-up comparison of two languages, it seems to be fairly useless.
jerf 12y ago
Honest question, as I don't know Nim... does it require any more, or are those legal programs as-is? I know, for instance, that you can simply run a Python program, no boilerplate required, and Python answers to these questions would have 0 bytes of visible boilerplate to "run". It's a reasonable observation that Go does have a bit of mandatory boilerplate.
- def- 12y ago
  Those are full, runnable programs. Nim's boilerplate is similar to Python's here.
  - jerf 12y ago
    Thank you.

moe 12y ago

Sadly my browser times out at "Waiting for cdnjs.cloudflare.com", so I only see a rather busted version of the page (or is the odd whitespace preceding the Nim-examples intentional?). But the little I can see looks very promising, thanks for compiling this! Will definitely check back when Cloudflare has their act together again.

aikah 12y ago

This has to be the worse performing webpage I ever visited. It looks like hljs has so much code highlighting to do it blocks the UI thread or something.

adwhit 12y ago

For those who are confused - this website is just a rendering of Rosetta Code snippets. You can change the URL to display any two language e.g. http://rosetta.alhur.es/compare/rust/c/ http://rosetta.alhur.es/compare/rust/c/ So it is not and is not meant to be 'fair', just a nice way to compare language idioms.

donatj 12y ago

The as you scroll syntax hilighting is not getting along with my iPad at all.

jryan49 12y ago

This website doesn't seem to render correctly for me. It's also the slowest thing ever.

agumonkey 12y ago
It's impressively random. Scrolling helps, sometimes. Sometimes slow, sometimes not. An interesting case.
sirlantis 12y ago
Switched from Chrome to Firefox, works there.
- ricardobeat 12y ago
  This website only works in Firefox. A rare occurrence.
dkuntz2 12y ago
If you change the URL from nimrod to nim it works.

tromp 12y ago

Are these the only two programming languages that are also well-known games? http://en.wikipedia.org/wiki/Nim http://en.wikipedia.org/wiki/Nim http://en.wikipedia.org/wiki/Go_%28game%29 http://en.wikipedia.org/wiki/Go_%28game%29

amaranth 12y ago
Rust is also the name of a fairly popular video game.
- steveklabnik 12y ago
  Fun quirk: the game has _also_ been in a pre-release state for a long time, there were a ton of people who rejoyced when they heard we hit beta, then realized it was the wrong Rust... I'm sure the final in five weeks is gonna be the same way.
antisuji 12y ago
Indeed, when I clicked on the link I irrationally expected some kind of comparison between Nim positions and Go endgames. Color me disappointed.

tempodox 12y ago

What are those zillions of empty lines under “Nimrod” for? No code needed?

jmulho 12y ago
Try Firefox.
- tempodox 11y ago
  Even in Firefox, formatting looks broken. We should add consistent rendering in a browser to the Rosetta tasks.

phantom_oracle 12y ago

I always thought Nim would be a better systems language to invest time in, but when looking at the code-snippets side-by-side, the Nim code gets really confusing whereas the Go code has nicer 'flow' and is more readable (ironic, considering that Nim claims to be Pythonic). I'm definitely not going to bash Nim against Go, but to me, code like this: proc det[M,N](a: Matrix[M,N]): float = let n = toSeq 0..a.high is unreadable. There's about as much (if not more) types of brackets in the Nim code compared to the Go code and I am moving towards an opinion that Nim is very unlike Python in readability (it may take things like indentation, no ";" and no " { } ", but Nim code is definitely not like Python in many other ways). Also, apart from the brackets, it has things like: "(a: Matrix[M,N]): float = " which would not be clear to an average programmer unless he/she actually went out to "learn" the ways of Nim (whereas Python code is very readable, even if you just know basic programming). Maybe this is due to the way the writer of each snippet writes their code, but as far as readability goes, Go wins on this one.

tuan5 12y ago
Obviously NIM author was trying to compare lines of code is shorter than Go. The readability issue is really scared me off NIM.
jeremyjh 12y ago
Any programmer who understands generics can easily understand that signature.
jaws- 12y ago
http://rosetta.alhur.es/compare/nim/go/#Matrix_arithmetic http://rosetta.alhur.es/compare/nim/go/#Matrix_arithmetic Nim: proc det[M,N](a: Matrix[M,N]): float = let n = toSeq 0..a.high for sigma, sign in n.permutations: var x = sign.float for i in n: x *= a[i][sigma[i]] result += x Go: func determinant(m [][]float64) (d float64) { p := make([]int, len(m)) for i := range p { p[i] = i } it := permute.Iter(p) for s := it(); s != 0; s = it() { pr := 1. for i, σ := range p { pr *= m[i][σ] } d += float64(s) * pr } return } I don't know anything about Go or Nim, but the Nim version looks infinitely more readable to me.

federico3 12y ago

Regardless of the website, I'm amazed to see Nim once again on HN. The language looks really underrated to me.