4 ms·

> python 3 (without any library or optimization) was faster than compiled nim to count words on a moderately large text. I'm not a fan of Nim because types go

> python 3 (without any library or optimization) was faster than compiled nim to count words on a moderately large text. I'm not a fan of Nim because types go after the variable. But the fact that you did not consider that you may have messed something up and just thought "yeah totally, a language built to compete with C++ is slower than python", really discredits your entire post.

nudpiedo 8y ago
I do not go often for ad-hominem... but your nickname has "Nim" within it and python's IO and runtime is programmed in C which discredits nothing since we are not scoring anything, really
hellofunk 8y ago
That’s quite a trivial reason to dislike a language! There are quite a few languages, including some very popular ones, like Kotlin, where the type comes after the variable.
bluejekyll 8y ago
Have you considered that in instances where type inference (I haven’t used Nim, but this is true of Rust, Kotlin, Swift, etc) can be used, having the type follow the variable is vastly superior from a readability point of view? It didn’t take me long to prefer this syntax to that of Java, C, C++, etc.
- Nimitz14 8y ago
  I do not understand how having it on the right should help where type inference is used, as in that case you do not write the type at all! There's absolutely no difference in readability. How about we consider the normal case (where you write out the types): int num_entries = .. float div = .. float result = num_entries // div vs num_entries: int = .. div: float = .. result: float = num_entries // div Because they are on the right, they aren't aligned which makes it harder to parse (imo). It gets even worse with more complicated types (lists etc).
  - bluejekyll 8y ago
    You left out a type inference example: let foo = Bar(); Anyway, these are all subjective perspectives, but I was personally won over to them, especially as I started using type inference more often.
- a1369209993 8y ago
  > having the type follow the variable is vastly superior from a readability point of view? [citation needed] The way Nim, Rust, etc do it, with a useless 'var' keyword even when a type is present, is clearly needlessly verbose (ie, inferior, though I'd hesitate to say vastly), but I'd be interested to see a analysis of the merits of something like "Foo[2] foo = bar()" vs "foo Foo[2] = bar()" (or maybe that should be "foo [2]Foo = bar()"?), since it hadn't actually occurred to me to use the latter order seperate from the useless keyword.
  - steveklabnik 8y ago
    It’s not useless in Rust, it significantly simplies the grammar. This is good for both humans and tooling.
  - mratsim 8y ago
    var isn't useless, it indicates mutability.
    - a1369209993 8y ago
      Ah, that makes sense, thanks. (Although I think that's specific to Nim?)

nudpiedo 8y ago

I do not go often for ad-hominem... but your nickname has "Nim" within it and python's IO and runtime is programmed in C which discredits nothing since we are not scoring anything, really

hellofunk 8y ago

That’s quite a trivial reason to dislike a language! There are quite a few languages, including some very popular ones, like Kotlin, where the type comes after the variable.

bluejekyll 8y ago

Have you considered that in instances where type inference (I haven’t used Nim, but this is true of Rust, Kotlin, Swift, etc) can be used, having the type follow the variable is vastly superior from a readability point of view? It didn’t take me long to prefer this syntax to that of Java, C, C++, etc.

Nimitz14 8y ago
I do not understand how having it on the right should help where type inference is used, as in that case you do not write the type at all! There's absolutely no difference in readability. How about we consider the normal case (where you write out the types): int num_entries = .. float div = .. float result = num_entries // div vs num_entries: int = .. div: float = .. result: float = num_entries // div Because they are on the right, they aren't aligned which makes it harder to parse (imo). It gets even worse with more complicated types (lists etc).
- bluejekyll 8y ago
  You left out a type inference example: let foo = Bar(); Anyway, these are all subjective perspectives, but I was personally won over to them, especially as I started using type inference more often.
a1369209993 8y ago
> having the type follow the variable is vastly superior from a readability point of view? [citation needed] The way Nim, Rust, etc do it, with a useless 'var' keyword even when a type is present, is clearly needlessly verbose (ie, inferior, though I'd hesitate to say vastly), but I'd be interested to see a analysis of the merits of something like "Foo[2] foo = bar()" vs "foo Foo[2] = bar()" (or maybe that should be "foo [2]Foo = bar()"?), since it hadn't actually occurred to me to use the latter order seperate from the useless keyword.
- steveklabnik 8y ago
  It’s not useless in Rust, it significantly simplies the grammar. This is good for both humans and tooling.
- mratsim 8y ago
  var isn't useless, it indicates mutability.
  - a1369209993 8y ago
    Ah, that makes sense, thanks. (Although I think that's specific to Nim?)