Side-by-side Nim and Go | Hacker News Reader

Side-by-side Nim and Go

rosetta.alhur.es

57 pointsmeneses47 comments

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/

So it is not and is not meant to be 'fair', just a nice way to compare language idioms.

This uses the code snippets from http://rosettacode.org/wiki/Rosetta_Code . I wrote many of the Nim ones and collected them over at 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/#

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.

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

It's impressively random. Scrolling helps, sometimes. Sometimes slow, sometimes not. An interesting case.

If you change the URL from nimrod to nim it works.

Switched from Chrome to Firefox, works there.

This website only works in Firefox. A rare occurrence.

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.

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.

Those are full, runnable programs. Nim's boilerplate is similar to Python's here.

Thank you.

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.

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.

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.

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.

Any programmer who understands generics can easily understand that signature.

These aren't exactly fair comparisons.

That's a (simple, standard) generic implementation, Go's is limited to a single type.

Is there anything else beyond the generic type signature that makes this less readable to you?

Also, if you like, you could change that first sequence initialization to: (0..a.high).toSeq to keep it consistent with other 'method' calls.

Are these the only two programming languages that are also well-known games?

http://en.wikipedia.org/wiki/Nim

http://en.wikipedia.org/wiki/Go_%28game%29

Indeed, when I clicked on the link I irrationally expected some kind of comparison between Nim positions and Go endgames. Color me disappointed.

Rust is also the name of a fairly popular video game.

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.

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

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?

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

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.

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.

There are a lot of tokens which are not strictly necessary, but which make a programmer's job easier. There's more to designing a language than making it use as few tokens as possible. A programmer's job involves a lot of different things - merging two pieces of code, reading and editing someone else's code, viewing diffs of code, moving code from one place to another, searching large amounts of files for specific code.

A lot of the choices in Go (and its standard formatting with gofmt) were made with all of these things in mind, not just the raw textual efficiency in mind.

Measurement is a tricky problem. You wouldn't measure efficiency in various human languages by testing using people who don't know the language. Similarly we would need to use people who have a basic competency (at least) in the same computing language being tested.

But then you still need to adjust for skill levels, and that seems a bit circular.

I think we're far from being able to measure this accurately.

Assuming the people being tested are English speakers, code has key words, which are already in your native language, and symbols, which to some extent echo their use in English.

Japanese does not have key words that are already in English. This is why it's generally considered harder for an English speaking person to read Japanese than to read some simple code.

There are orders of magnitude more people who will program in future than which program now. We should absolutely design things around those people.

Edit for natedad: 100% of people that fixed a bug were non-programmers at some point.

I agree that how easy something is to learn depends on what you're previously familiar with. English certainly helps. Also, if you're already comfortable with math then you'll be more comfortable with symbol manipulation.

But that's a separate question from how easy it is to use a language after you've already learned it. The studies to measure these questions would need to be designed differently.

On the other hand, these questions do overlap. People who know a language don't stop learning; they get better at using it with practice. Also, people who use a language occasionally need to switch gears going back to it and need to relearn things.

+1 when non-programmers start fixing bugs, I'll worry about how hard it is for them to read the language.

>> nailer: Fitting more on screen, and having a higher signal/noise ratio is /objectively better/ than otherwise.

> NateDad: 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:

Careful. You might be the one here who haven't considered some obvious things.

I think parent as well as dagw's comment (Does that mean that J/K/APL are the objectively best programming languages?) explaint perfectly well why what you wrote where flawed.

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.

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

Try Firefox.

Even in Firefox, formatting looks broken.

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

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

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 [2]: http://rosetta.alhur.es/compare/nimrod/go/#Zero_to_the_zero_...

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

    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")

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.

As any language designed in the last decade.

Go is only eight years old.

Fair enough, but syntax-wise it looks like it was designed in the 80's or 90's. Some people see that as a good thing.

Many programmers don't like indentation blocks.

Can't tell why. I think it's awesome. Languages like Ruby suddenly seem like they got a bunch of strange ends dangling all over the place.

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

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

Reply on news.ycombinator.com