Static typing aside, I don't find it any more verbose (noisy) than Python. In fact I find it strikes a perfect balance.

Can you give an example of noisy syntax? Is it in relation to the type system?

I'm writing Nim every day recently; I haven't experienced it being noisy, but I also don't have extensive or recent experience with Python.

Sure.

I'm on phone, so hopefully this paste doesn't look awful, but it's right from the website homepage

iterator oddNumbers[Idx, T](a: array[Idx, T]): T = for x in a: if x mod 2 == 1: yield x

The three different sets of brackets, the mixed : and =, it just seems inelegant to me.

I don't really know how I'd improve it, so it's just pointless, ignorant complaining on my part. Pay me little mind.

The equivalent in Python would be:

  T = TypeVar("T")
  def odd_numbers(a: list[T]) -> Iterator[T]:
      # implementation

I don't really find that less verbose, in terms of brackets and symbols…

Yeah, I guess you're right.

Does Nim have comprehensions? Even if you're striving for equivalent signatures the inner body of the function can be expressed as a comprehension in Python:

  T = TypeVar("T")
  def odd_numbers(a: Iterable[T]) -> Iterator[T]:
    yield from (n for n in a if n % 2 == 1)

See collect: https://nim-lang.org/docs/sugar.html#collect.m%2Cuntyped%2Cu...

I think the "full" version is easier to read:

    T = TypeVar("T")
    def odd_numbers(nums: Iterable[T]) -> Iterator[T]:
        for n in nums:
            if n % 2 == 1:
                yield n

Although yet another option is to just return the generator instead of immediately yielding from it:

    T = TypeVar("T")
    def odd_numbers(nums: Iterable[T]) -> Iterator[T]:
        return (n for n in a if n % 2 == 1)

Unfortunately, Nim doesn't have `yield from`, which would make a comprehension useless here. That's one of the things I'm missing in the language.

That's an obscure/not optimal way to write this code though. I mean why would you use LIST comprehension if you are going to yield each element.

It's not list comprehension, it's generator comprehension, which is lazily computed. However it's still an unnecessary layer of iteration, when you could just return the comprehension instead.

I can't get used to the fact that for builtin types grow methods, you need to import corresponding modules everywhere.

You import module X, which gets you objects as defined in the module Y. To use methods defined for that type, you need to import Y yourself. Python, of course, by virtue of binding objects to methods, doesn't need it.

There are some more namespacing quirks that may require one to give up on that sweet syntactic sugar to disambiguate things (two unrelated modules defining methods on a single type, with the same signature but different behaviors, and you need both modules imported for some reason?), but this is, again, something one would have to get used to. It's not a different world like Rust or Prolog.

It's not a complete showstopper, just something I keep bumping my head into now and then.

> you need to import corresponding modules everywhere

It's a good practice to re-export "all modules whose types appear in public symbols of the current module".

For that and other good advice, see The Status Nim style guide:

https://status-im.github.io/nim-style-guide/03_language.html...

I love python as well, and I literally just started exploring Nim yesterday, so this is very timely.

The one thing that stuck out to me like a sore thumb is the camelCase convention. I know it's a minor thing (and a personal preference), but I'm a bit biased against languages that use camelCase (Java, JavaScript, etc). There's something uneasy about it IMHO.

Nim is partially case-insensitive:

https://nim-lang.github.io/Nim/manual.html#lexical-analysis-...

my_foo, myfoo, and myFoo are interchangeable. MyFoo is different because the first letter is capitalized.

If it's not clear, what I mean is that if you've imported a module that exports myFoo, you can refer to it in your code as my_foo, if you prefer.

Some people love this aspect of Nim, others loathe it. I don't have strong feelings about it, though one has to be mindful of it when searching through a codebase with e.g. the_silver_searcher.

Good to know. Although I'd argue that this is something that I'd count _against_ the language. I'm also biased against languages that allow you to do the same thing in multiple ways (hint: Scala). Code bases tend to vary according to the team's own conventions, so you have to keep adapting to whatever code base you happen to be reading.

Your bias is your own problem. There's clearly a solution that allows you to use snake_case and those that potentially import your library to seamlessly use all exports as camelCase, yet you're still bothered by that. It's nonsensical, Nim literally came up with the absolute most elegant solution to this.

Nope. Its solution is "we made things uglier therefore you can mangle them in a way you like".

Strong convention is much better than pleasure of everyone.

> we made things uglier

That's unfounded, please try it at least once in the playground play.nim-lang.org/. To me it's very cool that wrapped C libs with identifiers like ATOMIC_RELEASE can be written as AtomicRelease without any trouble.

I get what you're at with the multiple ways to do stuff, but in Nim it actually makes it more consistent (imo).

If my codebase enforces camelCase and a library uses snake_case, then I can still use that library using camelCase, and Nim has nimgrep to make this easier all the way.

--styleCheck:on to enforce the style every identifier is declared in your code base.

Me too. I do a lot of grepping on codebases and this seems like it could bite me at some point. But it is a very interesting approach to solving the naming convention problem.

> I'm also biased against languages that allow you to do the same thing in multiple ways

So you oppose languages supporting both recursion and iteration?

recursion vs. iteration, inheritance vs. composition, interfaces vs. abstract classes, etc. are design choices that depend on the problem being solved. Language syntax is different; it's an opinion of the language designer which gives the language its distinctive style, and IMO shouldn't have much leeway in expressing the same thing in multiple ways. It's what gives the language its identity.

For example, here's how you can iterate over a list in scala to print each element:

    List(1, 2, 3).foreach(element => println(element))
    List(1, 2, 3) foreach { element => println(element) }
    List(1, 2, 3).foreach(println(_))
    List(1, 2, 3).foreach { println(_) }
    List(1, 2, 3).foreach { println _ }
    List(1, 2, 3).foreach(println)
    List(1, 2, 3) foreach (println)
    List(1, 2, 3) foreach { println }
    List(1, 2, 3) foreach println

I'm having trouble contrasting that to the many ways I can add 2 and 3, and this doesn't bother me:

    x = 2 + 3
    x = 3 + 2
    x = (2 + 3)
    x = (3 + 2)
    x = 2; x += 3
    x = 3; x += 2
    x = 2; x = x + 3
    x = 3; x = x + 2

> recursion vs. iteration, inheritance vs. composition, interfaces vs. abstract classes, etc. are design choices that depend on the problem being solved.

Recursion and inheritance are interchangeable (in fact, either can be implemented as syntax sugar over the other); while some people find one or the other more natural for a particular problem, there is considerable disagreement among people over which is more natural for which problems. In practice people choose between them based on personal preference and what the language they are using favors (e.g., you probably [0] don’t use recursion unless it is of fairly tightly bounded depth in a language like Python that doesn’t optimize tail calls.

> Language syntax is different; it's an opinion of the language designer which gives the language its distinctive style, and IMO shouldn't have much leeway in expressing the same thing in multiple ways.

As noted, recursion vs. iteration is exactly a syntax-preference decision, and one on which some languages are highly opinionated (Python) forming an important part of their distinctive style, while others are not.

[0] though you could use a tail call optimization decorator

> Recursion and inheritance are interchangeable (in fact, either can be implemented as syntax sugar over the other)

Did you mean Recursion and Iteration?

Some recursion could be translated into iteration only if there is stack managed by hands. It decreases readability significantly.

Simplest example: Ackermann function.

And it works both way: some algorithms are better read as iteration.

> my_foo, myfoo, and myFoo are interchangeable. MyFoo is different because the first letter is capitalized.

God, that's horrible.

>my_foo, myFoo, and myFoo are interchangeable.

I'm confused, two of those are myFoo, so I hope they are interchangeable!

I think it intended my_foo, myFoo, and myfoo.

Fixed. The second or third one should have been all lowercase.

One thing that’s always bugged me about snake case is that people are so averse to the additional length of strings that they just omit the underscores. So you end up with methods like array.tolist() and itertools.ziplongest(*lists, fill_value=None) — that last one isn’t even internally consistent. In an ideal world I would find snake case more readable, but people actually adhere to camel case, which makes it more readable than snake case overall.

Camel case consistent? You must be reading different code than me: Ue/UE, Subcell/SubCell, cellgroup, cellGroup all seen in the codebase I work..

Even though it's not according to the styleguide, you can just use snake_case whenever and wherever you want, consumers of your libraries or other way around will never notice!

Then you end up with an ecosystem with mixed conventions. Not good IMO.

You can literally do whatever you want with any library you use in your own codebase and have a consistent convention in your own code regardless of what your dependencies' authors preferences are. In other words, if the library authors used camelCase but you want to use snake_case in your code, you just do it.

It's very strange at first, and I had the same reaction as you, but it's actually quite nice. (I say that as somebody who strongly dislikes snake_case :) )

You mean the language is case insensitive and drops _'s or something? Doesn't that break searchability with command line tools (or make for much more complicated regexes)?

Or do you just mean use a mixture just like you could in most other languages?

Same here, at first making camelCase and snake_case interchangeable seemed like a terrible idea. But in practice I can read and grok libraries that use either and in your code call it using your preference. It just kinda works.

Actually, in Nim "functionName", "function_name" and "functionname" are equivalent and interchangeable

So one needs to grep 3 times instead of once in a code-base. Why did the authors chose this abominable convention ? It makes maintenance a nightmare.

I never had this issue: do not mix different stiles across the same project.

Instead, you can import and use libraries that use a different stile without breaking your convention.

nimgrep solves this, you might not like it, but people who have actually tried it are fond of it.

It matches identifiers style-insensitively so you can actually use other conventions if you want. Although the online docs are still camelcased.

If you want a statically typed language with Python-alike syntax but Nim is too "noisy" for you, then Lobster (http://strlen.com/lobster/) is likely spot-on.

You probably won't see this, but in fact I've really enjoyed playing with Lobster!

Thanks for telling me about it, I hadn't taken it seriously before.

I did see it! Let me know if you have feedback to improve it.

Do you have examples of what you mean with unnecessarily noise? For me it's the JSON operators. `@[]` for sequences could also be a thing, but it's really minor(for me).

If you prefer python syntax, you can code in python and transpile? Py2many supports nim.

I wonder if there is sufficient interest in having a python stdlib compatible library for nim.

I agree. The syntax is the main reason I don't use it.

Completely fair, syntax is something that resonate differently from person to person. I love the idea of Rust, it’s speed, capabilities, it’s politics and it’s independence, but I cannot stand it’s syntax.

That’s fine, I can use other languages and it doesn’t take anything away from Rust or the people who love the syntax.