1. 15
  1.  

  2. 6

    One thing here is that the regex crate in Rust is great for pathological cases, but doesn’t fall back to a faster algorithm in non-pathological cases. That test ends up being more of a test of regex engines than languages. Another example is that \w is Unicode aware for us and not for Nim. The author of the crate posted elsewhere:

    When I switched \w+ to [a-zA-Z0-9_]+ in the Rust program, I saw a ~60% performance increase.

    Anyway, Nim is a really cool language. Benchmarks are hard.

    1. 2

      This one is pretty weak when discussing Nim:

      However, there is a flip side when leaning toward the writer’s freedom too much: the explicitness, clarity or even maintainability could be hampered. Let me give a small example: in Nim, import will bring in all module symbols to your namespace. A symbol of a module can be qualified with module.symbol syntax, or you can use from module import nil to force qualification, but really, who will bother doing this? And this seems not “idiomatic Nim” anyway. The result is, you often cannot tell which symbol comes from which module when reading others’ (or your) code. (Fortunately, there won’t be naming collision bugs because Nim compiler forces you to qualify in such cases.)

      In particular:

      A symbol of a module can be qualified with module.symbol syntax, or you can use from module import nil to force qualification, but really, who will bother doing this?

      The who will bother doing this? Anyone who cares about name space pollution.

      There’s a handful of things in the comparison that make it hard to take seriously even after it gets past the meaningless “benchmarks”. I love this one that is randomly thrown in without explanation:

      “let mut instead of var (small thing but matters)”

      I think people interested in both would be better served by doing a small project in each over the course of a few days and comparing for themselves.

      1. 3

        You can mark quotes from the article by putting “> ” at the beginning of their paragraph:

        > However, there is a flip side…
        

        The result:

        However, there is a flip side…

        1. 1

          A symbol of a module can be qualified with module.symbol syntax, or you can use from module import nil to force qualification, but really, who will bother doing this?

          The who will bother doing this? Anyone who cares about name space pollution.

          I think it was a valid criticism. People are too lazy for their own good, and sometimes won’t add safety features that require more typing unless the language forces them to do it. I heard that C++ has a similar problem, where const would be accurate to add to many variable declarations but many people don’t bother. The author claimed import qualification was “not ‘idiomatic Nim’”, meaning that he thinks that most Nim users don’t bother. And, indeed, the first Nim file I could find, koch.nim in the Nim compiler, does not qualify its imports.

          Still, I don’t think that criticism is very strong, since, as the author said, “there won’t be naming collision bugs because Nim compiler forces you to qualify in such cases”. I don’t imagine that figuring out the source of an imported method would be that hard when you read it. If necessary, someone could develop an IDE or editor plugin for Nim that shows the fully-qualified name of the current symbol as a tool-tip.

          the meaningless “benchmarks”

          Did you notice a problem with the methodology of the benchmarks? I thought they successfully demonstrated that Nim programs were slightly slower than Rust programs.

          I love this one that is randomly thrown in without explanation:

          let mut instead of var (small thing but matters)”

          I agree that the author should have explained it. But I think I can guess what he means. He is claiming that since let mut is harder to type than let, then in Rust, most people will use let, leading to better programs. But in Nim, declaring a variable is as simple as using var instead of let, and so he thinks some people will be lazy and just define everything as var like they are used to in other languages.

          Personally, I doubt that will be a problem, since let is just as easy to type as var. Nim tutorials just need to make sure they emphasize that you should use let by default.

          1. 4

            The case is actually more complex than that. For example, let takes a pattern, so you can do things like

            let (mut a, b) = ...
            

            A simple var doesn’t fix this kind of issue.

            1. 3

              Some code that someone whipped up and run on a single machine is not a good benchmark.

              Benchmarking is hard: https://www.youtube.com/watch?v=VZd2Jhkecrg