4 ms·

I have written a bit of both, recently re-wrote a command runner for a side-project https://gitlab.com/jarv/cmdchallenge https://gitlab.com/jarv/cmdchallenge in

by zoidb 5y ago

I have written a bit of both, recently re-wrote a command runner for a side-project https://gitlab.com/jarv/cmdchallenge https://gitlab.com/jarv/cmdchallenge in Nim and found it very pleasant and much less verbose, which was a nice change from GoLang while keeping type safety. A good example is parsing JSON https://nim-by-example.github.io/json/ https://nim-by-example.github.io/json/ as you can do a lot with fewer lines of code. I think the main disadvantage of Nim is that there is less out there in the ecosystem, libraries, and it's more likely you will run into quirks and bugs in the standard library.

andybak 5y ago
I really like the look of Nim but every time I dig into it I find a really strange syntax decision. For example: > The json module provides the %* operator which is used to create JSON objects I'm curious what the benefits are here of an operator over some more readable syntax. I have a dislike of languages where ascii noise seems to be favoured over readable english tokens.
- zoidb 5y ago
  Yeah, I tend to agree with you here especially after a take a break from writing Nim I need to re-learn a lot because it is impossible to hold it in my head for very long.
- k__ 5y ago
  This is interesting, especially for a language like Nim that favours familiarity with Python. Even Rust dropped most of its strange operators/sigils early on in the experimentation phase, because they confused people and Rust doesn't step back from confusing people lightly, haha.
  - elcritch 5y ago
    Probably because Rust already has too many ascii symbols! ;) I still get brain mush remapping Rust's & from C's &. But yah Nim's % is a bit strange at first, but becomes fairly handy in practice when dealing with lots a small bits of JSON. There's the % "to json" operator that mimics the $ "to string" operator for a single value. Then %* was added to handle multiple json items (I read it like apply % to all items). So it has a decent symmetry. Other than % and $ ascii operators are pretty rare in Nim code. Even bitops use or, and, shl, shr, etc over ascii operators.
- haxscramper 5y ago
  This way you can write json literals in the code, and it will look just like regular json. For serialization and deserialization stdlib uses `to/load/store` proc names. import std/json echo %*{ "key1": "value", "key2": 12, }
  - clusterfish 5y ago
    Could have just used a "JSON" keyword instead. Symbolic names are needlessly obscure and unfriendly. Hard to infer meaning, hard to pronounce, hard to search online, etc.
    - dunefox 5y ago
      As if "json" is any more searchable. Operators have a meaning that you learn quickly when learning the language. You wouldn't do math with "multiply" instead of "*", so why would you want that in a programming language?
      - dandellion 5y ago
        Because with a keyword the meaning is much more explicit, and I consider that to be more valuable. And I think "*" is a bad example because pretty much everyone who programs already knows it's multiplication.
        dunefox 5y ago
        It might not be the best example, but the point stands. Succinct notation is important. "JSON" instead of "%*" might not be the greatest of examples but still.
      - mkl 5y ago
        Multiply already has a symbol, and JSON already has a name. Making up a symbol %* to mean JSON is like making up a name Flurb to mean *. Sticking with what already exists seems much simpler.
      - clusterfish 5y ago
- vegai_ 5y ago
  That's really good point. Also, I don't think it's the only weird operator they introduce in the stdlib without any good reason.
- timotheecour 5y ago
  Checkout the newer std/jsonutils: https://nim-lang.github.io/Nim/jsonutils.html https://nim-lang.github.io/Nim/jsonutils.html let a = (1.5'f32, (b: "b2", a: "a2"), 'x', @[Foo(t: true, z1: -3), nil]) let j = a.toJson assert j.jsonTo(typeof(a)).toJson == j
- xigoi 5y ago
  The json module is old and probably wouldn't be designed this way today.
Thaxll 5y ago
That %* is really strange. Also in the example there is no notion of errors? Nim is exception based?
- timotheecour 5y ago
  yes, invalid JSON would raise an exception.

by zoidb 5y ago

andybak 5y ago

I really like the look of Nim but every time I dig into it I find a really strange syntax decision. For example: > The json module provides the %* operator which is used to create JSON objects I'm curious what the benefits are here of an operator over some more readable syntax. I have a dislike of languages where ascii noise seems to be favoured over readable english tokens.

zoidb 5y ago
Yeah, I tend to agree with you here especially after a take a break from writing Nim I need to re-learn a lot because it is impossible to hold it in my head for very long.
k__ 5y ago
This is interesting, especially for a language like Nim that favours familiarity with Python. Even Rust dropped most of its strange operators/sigils early on in the experimentation phase, because they confused people and Rust doesn't step back from confusing people lightly, haha.
- elcritch 5y ago
  Probably because Rust already has too many ascii symbols! ;) I still get brain mush remapping Rust's & from C's &. But yah Nim's % is a bit strange at first, but becomes fairly handy in practice when dealing with lots a small bits of JSON. There's the % "to json" operator that mimics the $ "to string" operator for a single value. Then %* was added to handle multiple json items (I read it like apply % to all items). So it has a decent symmetry. Other than % and $ ascii operators are pretty rare in Nim code. Even bitops use or, and, shl, shr, etc over ascii operators.
haxscramper 5y ago
This way you can write json literals in the code, and it will look just like regular json. For serialization and deserialization stdlib uses `to/load/store` proc names. import std/json echo %*{ "key1": "value", "key2": 12, }
- clusterfish 5y ago
  Could have just used a "JSON" keyword instead. Symbolic names are needlessly obscure and unfriendly. Hard to infer meaning, hard to pronounce, hard to search online, etc.
  - dunefox 5y ago
    As if "json" is any more searchable. Operators have a meaning that you learn quickly when learning the language. You wouldn't do math with "multiply" instead of "*", so why would you want that in a programming language?
    - dandellion 5y ago
      Because with a keyword the meaning is much more explicit, and I consider that to be more valuable. And I think "*" is a bad example because pretty much everyone who programs already knows it's multiplication.
      - dunefox 5y ago
        It might not be the best example, but the point stands. Succinct notation is important. "JSON" instead of "%*" might not be the greatest of examples but still.
    - mkl 5y ago
      Multiply already has a symbol, and JSON already has a name. Making up a symbol %* to mean JSON is like making up a name Flurb to mean *. Sticking with what already exists seems much simpler.
    - clusterfish 5y ago
vegai_ 5y ago
That's really good point. Also, I don't think it's the only weird operator they introduce in the stdlib without any good reason.
timotheecour 5y ago
Checkout the newer std/jsonutils: https://nim-lang.github.io/Nim/jsonutils.html https://nim-lang.github.io/Nim/jsonutils.html let a = (1.5'f32, (b: "b2", a: "a2"), 'x', @[Foo(t: true, z1: -3), nil]) let j = a.toJson assert j.jsonTo(typeof(a)).toJson == j
xigoi 5y ago
The json module is old and probably wouldn't be designed this way today.

Thaxll 5y ago

That %* is really strange. Also in the example there is no notion of errors? Nim is exception based?

timotheecour 5y ago
yes, invalid JSON would raise an exception.