

Side-by-side Nim and Go - meneses
http://rosetta.alhur.es/compare/nimrod/go/#

======
adwhit
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.

------
def-
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
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.

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

~~~
sirlantis
Switched from Chrome to Firefox, works there.

~~~
ricardobeat
This website only works in Firefox. A rare occurrence.

------
notacoward
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.

~~~
jerf
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-
Those are full, runnable programs. Nim's boilerplate is similar to Python's
here.

~~~
jerf
Thank you.

------
aikah
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.

------
phantom_oracle
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.

~~~
jaws-
[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.

------
tromp
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
Rust is also the name of a fairly popular video game.

~~~
steveklabnik
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.

------
nailer
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
_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?

~~~
mitchty
Depends, can we include whitespace in on the action too?

------
moe
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.

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

~~~
jmulho
Try Firefox.

~~~
tempodox
Even in Firefox, formatting looks broken.

We should add consistent rendering in a browser to the Rosetta tasks.

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

~~~
zamalek
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_...](http://rosetta.alhur.es/compare/nimrod/go/#Zero_to_the_zero_power)

~~~
voidlogic
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
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.

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

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

