8 ms·

I stopped trying Nim in 2017 when I found out that the only worth feature were the macros. Red flags I saw: * A return variable within procedures that works in

I stopped trying Nim in 2017 when I found out that the only worth feature were the macros. Red flags I saw: * A return variable within procedures that works in the same fashion as an assembly routine with a registry * Mutable strings * Mutable everything * Hate speech against functional concepts in the community (with all the related biases that this brings) * Some arrogant community members were tolerated just because they wrote popular blog posts on Nim implementing a fashionable pet project. * no clear consistent design direction * too many pragmas * too many pascal syntax mixed with other language syntaxes * no module namespacing * modules worked not much better than C libraries... (I am generalizing) * poor ecosystem made out of incomplete mutable libraries * python 3 (without any library or optimization) was faster than compiled nim to count words on a moderately large text. After I realized about python was easily beating Nim in spead and readability only with the standard library without any optimisation on python's side (and Nim being fully compiled), my interest on Nim went down to 0. I thought there were other places were I thought I could better invest my time. Did something from that list changed? is there any reason to look at Nim again in 2019? did someone here had a better or different experience than mine? EDIT: format, reworded sentences, expanded opinions

Nimitz14 8y ago
> 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.
coldtea 8y ago
So basically not even one substantial issue (not to mention most of these don't even hold). Contrary to hipster belief "Mutable strings", "Mutable everything" is not some accusation against a language...
- nudpiedo 8y ago
  it's a mainstream design choice on most of programming languages for several reasons, like security or heavy optimizations. If the language is so focused on constrained environments that might make no sense since the developer will be anyway counting bytes in their minds.
ilitirit 8y ago
> * python 3 (without any library or optimization) was faster than compiled nim to count words on a moderately large text. I'm sure many other commenters have singled out this comment, but do you have an example? I find this quite hard to believe. Surely this would have manifested elsewhere and people would have pointed it out ages ago? Nim compiles (or transpiles, if you prefer) to C/C++, after all.
- nudpiedo 8y ago
  It was very straightforward code looping, counting and storing strings in memory and writing to a file, after 2 years or more I do not keep the code anymore, sorry. Looking in perspective my guess is that the optimized C runtime of python (IO and optimized string references) competed against Nim's bare strings.
gameswithgo 8y ago
>After I realized about python was easily beating Nim in [speed] It is certainly not generally the case that Python beats Nim in speed, not even close. I would imagine something was wrong with your implementation or you hit some weird Nim bug or edge case.
- nudpiedo 8y ago
  It could be, but remember that python optimizes a lot IO and string manipulation (runtime in C). Based on how the feature list has changed perhaps I tried Nim even earlier than what I said. I also did not want to look for any optimizations since I just used bare constructs and no libs.
  - beagle3 8y ago
    Hash tables in nim require pulling in the standard library and are built-in in Python. If you didn’t even “import tables”, you were likely comparing O(1) apples to O(n) oranges.
  - nudpiedo 8y ago
    however I did it I am sure I used (imported or not) hash tables or similar from stdlib (no algorithm complexity difference in this regard). But based on the comments from everyone it is reasonable to say that my implementation had something wrong or the test was off in some regard.
sharmi 8y ago
I have not programmed in Nim and I am a Pythonista. Having said that, I had to parse the whole wikipedia dump xml file once and extract just the text. The python code for the same was so slow and would have taken days to go through the whole xml file. In my quest to find something faster, I came across a nim program that would take the xml in and dump a plain text file (or markdown?) file. It did the work within 2 hours. So I don't believe it was slower than python. Nim certainly has it's place and it is more comparable to go in speed.
- nudpiedo 8y ago
  It was very straightforward code looping, counting and storing strings in memory and writing to a file. Looking in perspective my guess is that the optimized C runtime of python (IO and optimized string references) competed against Nim's bare strings. If you are a pythonista I have a question for you, especially since I could still give Nim a try, how much effort would be for you to add 2 or 3 generators and asyncs in the python code and put in place a better architecture without any macros? how easy is the same thing in Nim without any library our of the standard library? This speed of prototyping and bringing a better architecture to the solution sooner matters a lot more to me than raw speed (that comparison against python in speed was the last drop). I believe you when you say that Nim won, after all they promose that some parsers such as csv parser could fit in the L2 cache and so on... hopefully the language and quality of libraries has improved. P.S. how big was the whole wikipedia as XML? all languages?
  - kungtotte 8y ago
    Python is intentionally a kitchen-sink type language that provides everything in its standard library, whereas Nim is intentionally the opposite. More and more things are moved out of its standard library to the package repository (Nimble). Thus, asking someone to write a stdlib-only solution in Nim is a bit of a trick question...
StreamBright 8y ago
+1 I would like to add 2 more things: - there are at least 3 incomplete logging and http server libraries (please provide documentation if you want anybody to use your library) - documentation is not always clear how to use the language
- pathsjs 8y ago
  As the author of at least one HTTP server library ( https://github.com/andreaferretti/rosencrantz https://github.com/andreaferretti/rosencrantz ) do you find anything missing in its documentation?
  - StreamBright 8y ago
    It is actually really nice. Thanks for the link!
- nudpiedo 8y ago
  I agree also on the point about documentation, this practice was also extended to the community modules (but everything was new and hacky so I thought it was OK, but it ended up being the rule a the ecosystem).
  - StreamBright 8y ago
    If you develop a new piece of software, especially a new language, documentation should be there so that the users can get in as fast as possible. I think Elixir is a great example in this regard that Jose paid attention to this feedback early and there is decent documentation for most of the things nowadays (minor exceptions). I have limited time and there are so many new languages, I will go with the one which has the lowest entering barrier.
- sp33der89 8y ago
  - As far as I know Jester is the go-to for your webservers and you could use the httpclient in the standard library. - This is true and there are plans to improve it, if you have any feedback on what could be clearer, you can share your thoughts here: https://forum.nim-lang.org/t/4523 https://forum.nim-lang.org/t/4523
detaro 8y ago
> python 3 (without any library or optimization) was faster than compiled nim to count words on a moderately large text. Do you still have examples around? I haven't used Nim yet, but it could be interesting to take a look at something like this to understand what happened.
- nudpiedo 8y ago
  I can check it later when I am back at home but since I regularly clean my projects & prototypes folder I do not think I kept it. The implementation was quite straight forward in both languages: count words and then some statistic counting. It made me think that Nim will end up making me think all the time in the CPU and the compiler in the same way I did when I programmed C (and still high level languages beat the things by achieving much faster cleaner designs/prototypes/high level patterns, etc). To be fair in my initial criticism, I guess a highly skilled Nim developer could beat python on a restricted environment, and in high level async processes both might differ in less than 1% in performance matters; but my code was really trivial and a straight forward iteration.
SolitudeSF 8y ago
> Hate speech against functional concepts in the community are you trolling? > Some arrogant community members were tolerated just because they wrote popular blog posts on Nim implementing a fashionable pet project. for example?
- nudpiedo 8y ago
  No, I am not trolling, read my other comment on the "hate speech". It was an opinion, do not take it too serious, if you like the language go for it.
dom96 8y ago
Nice list, thank you for compiling it. I'm one of the Nim core devs so I naturally disagree. A lot on the list is painted as a negative, whereas I see it as a positive, in particular: > * A return variable within procedures that works in the same fashion as an assembly routine with a registry Not sure I see the parallels between assembly and I don't understand why you think this feature is negative, can you elaborate? > * Mutable strings I love these! No need for messing around with `StringBuilder` and the like. > * Mutable everything That's simply false. You can choose between mutability and immutability, in fact you can even have an immutable `string` if you really want one: `let x = "asd"`. Now let me discuss some of your other points: > * Hate speech against functional concepts in the community (with all the related biases that this brings) Communities are large. A lot of us love functional programming and are bringing more and more of it into Nim. > * Some arrogant community members were tolerated just because they wrote popular blog posts on Nim implementing a fashionable pet project. Can you elaborate on who this was and how/where they were tolerated? > * no clear consistent design direction > * too many pragmas > * too many pascal syntax mixed with other language syntaxes These are mostly subjective so there isn't much I can say. Perhaps Nim just isn't for you due to its syntax, but many out there love it. > * no module namespacing > * modules worked not much better than C libraries... (I am generalizing) This is false too. Every imported module is in its own namespace. > * python 3 (without any library or optimization) was faster than compiled nim to count words on a moderately large text. Did you compile with -d:release? :)
- nudpiedo 8y ago
  Hi Dom96, thanks for answering point by point. Unfortunately I cannot answer all of these things since I got this impression about two years ago, and things might have changed or perhaps I got them wrong (as you say some of them are subjective). For example, I cannot tell what compilation option I used but I remember I went for the max speed I could and that I used default Nim language constructs and default python constructs (no libs), the compilation was one of the most sold features so I believe I used the release mode and that there was a marginal difference in favouring of python (subsecond). Think However that python has also many optimizations for string manipulation and that under the cover all runtime objects are references whereas in compiled languages developers are naked in front of the CPU. Knowing that you are core-dev I must say that building a language is very hard, and that by not bringing much to the state of the art and overselling too early it is easy to get compared and valued by subjective aspects or mere impressions. Heads up, keep it with the great work and do not take it personally, make the language shine in some unique aspect. Also do not forget that my comment was just an unfavourable opinion based on some observations I made years ago; I could change my opinion on the language anytime and give it again a chance if it brings me any benefit for my development, or it is fun, or it has some solutions for the problems I need to solve. Thanks for answering.
alehander42 8y ago
Honestly, I feel like you just want different things from your language, and you'd prefer something like Scala or Haskell. I've never heard "hate speech" against functional concepts: I've worked on functional-ish/pattern matching libs and i know other people from the community that love functional lang ideas. However those ideas are not as prevalent as in functional languages tho(obviously). I'd say a lot of those points are very subjective(syntax/pragmas/modules etc). It's true that the ecosystem is still small and documentations is not good enough sometimes: this is something that probably can't change without a stable 1.0 first(and serious doc efforts started last month).
- nudpiedo 8y ago
  I never used Scala, Haskell or a functional language other than a small pet project on clojure I usually write small functional snippets within OOP for python (so my job colleagues can still understand most of my code/structure). "Hate speech against functional concepts" was a metaphor for repetitive comments without foundation against some concepts and highly respectable design choices, where I often saw people pretending these to be dumb without really discuss the points properly, or exploring choices or constructs without acknowledging any single good thing from it. You can consider that a subjective, generalized opinion if you want. Think that "that functional approach" has a lot to borrow from, even when still working within a mostly imperative language. Perhaps it is not a true red flag but in my eyes it was an involution. Totally subjective if the focus of the language is becoming a better and more advanced C (rival of Golang for example)
  - vips7L 8y ago
    That's not hate speech.
    - nudpiedo 8y ago
      No, it is not. It was a metaphor.
      - klibertp 8y ago
narimiran 8y ago
> python was easily beating Nim in speed I'm just guessing here, but did you compile Nim in debug mode? (nim c filename.nim) From my experience, compiling files in release mode (nim c -d:release filename.nim) makes similar tasks run 10-100x faster than Python (usually around 30x for my use cases), and it doesn't require "highly skilled Nim developer" as you mention in your reply.
- nudpiedo 8y ago
  sorry, I cannot tell it anymore since that was long time ago, the python version probably had a generator; also remember that python's IO and string optimizations are written all in C.
mratsim 8y ago
There are plenty of functional libs in the Nim ecosystem, the prominent ones being: * NimFP[1] * Zero-Functional[2] Disclaimer: my very first language was Haskell and I'm now a Nim core contributor. Mutability: just like Ocaml, Nim has `let` and `const` and mutable function parameters and mutable variable need `var`. Caveat: for reference types, immutability is shallow (you cannot change the reference but you can mutate the reference content). Also many people in Nim community are pushing for more control on mutability, you can see for example the proposition on writetracking[3]. * [1] https://github.com/vegansk/nimfp * [2] https://github.com/zero-functional/zero-functional * [3] https://nim-lang.org/araq/writetracking.html
- nudpiedo 8y ago
  In my humble opinion on language design, if the main language favours a paradigm or style, the libs will do it even worse although some programming languages gave weird reimplementations of their whole stdlib in a different paradigm it is not the rule. C will be C no matter how much MISRA certifications are sold. For example, kotlin is very promising language on the paper, but in the reality it is being developed by people who kept a Java mindset and way to structure problems and code (and they repeat same concepts and ideas as they do in java, for example calling DSL to every single piece of nested code).
- electrograv 8y ago
  > Caveat: for reference types, immutability is shallow (you cannot change the reference but you can mutate the reference content). “Shallow immutability” is not just a “caveat” — it’s a complete abuse of the word “immutability”. If you can in-place modify the interior of a so-called immutable value in any way (possibly excepting code within some kind of “unsafe” blocks), it is by definition not immutable. Immutability is a pure, all or nothing kind of thing. That you are trying to present immutability as synonymous with C++ style “const”ness perhaps reinforces the parents’ post that Nim is not friendly or even aware of the functional paradigm of programming. But unlike others, I think it’s okay that it doesn’t support immutable variables. It certainly doesn’t outright condemn the language. However, let’s not pretend it’s something that it’s not.
nepeckman 8y ago
Wow we have had some different experiences. Going down your list, the only thing that has been a problem for me is the ecosystem issues, and that comes with the territory with smaller languages. The most surprising was your issues with speed, which I feel like had to have been a compiler or standard library bug of some sort. I use Nim on a side project with moderate calculations, and it finishes in about the time it takes nodejs to do Hello World. I think most of your list comes down to preference though. Nim isn't a fully FP, immutable language. It supports FP more than Python though, and probably as much as JavaScript does.
beagle3 8y ago
your recollection of your experience with Nim performance is what it is, but it is at odds with just about every other account of Nim, including by people who really dislike it. Your “it was a long time ago, I don’t remember” doesn’t make it credible either. Other comments are more a matter of opinion or view, but with respect to speed or memory use - Nim competes favorably with C++, D, Zig and friends. Neither CPython nor PyPy is in the same league.
- Symmetry 8y ago
  It's really easy to make C++ code that's slower at reading or writing files than Python if you go about it in an innocent way. https://stackoverflow.com/questions/30197068/why-is-my-c-text-file-parsing-script-so-much-slower-than-my-python-script?rq=1 https://stackoverflow.com/questions/30197068/why-is-my-c-tex... https://stackoverflow.com/questions/9371238/why-is-reading-lines-from-stdin-much-slower-in-c-than-python https://stackoverflow.com/questions/9371238/why-is-reading-l... So I wouldn't be at all surprised if you could make the same mistakes in Nim. But of course it would be unfair to claim that that means Nim is slow in general.
cryptonector 8y ago
All red flags except for this: > * Some arrogant community members were tolerated just because they wrote popular blog posts on Nim implementing a fashionable pet project. Arrogance is a problem, but kicking out a participant should require a bit more than their being arrogant.
rafaelvasco 8y ago
Mutable strings: That depends on the type of application you're doing. In my area, gamedev, it is better that everything is mutable by default and you optin for immutable, since games normaly deal with structures the mutate every frame. In that scenario it is normal to have immutable things getting in your way more than the other way around.
shevegen 8y ago
What a terrible non-sensical list that you gave here. Even more so your claim how python3 is faster. What is wrong with you lying to the people here? Why does ycombinator not outright forbid statements like this? Because this is not an "opinion" - this is a flat out lie from you here.

Nimitz14 8y ago

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

coldtea 8y ago

So basically not even one substantial issue (not to mention most of these don't even hold). Contrary to hipster belief "Mutable strings", "Mutable everything" is not some accusation against a language...

nudpiedo 8y ago
it's a mainstream design choice on most of programming languages for several reasons, like security or heavy optimizations. If the language is so focused on constrained environments that might make no sense since the developer will be anyway counting bytes in their minds.

ilitirit 8y ago

> * python 3 (without any library or optimization) was faster than compiled nim to count words on a moderately large text. I'm sure many other commenters have singled out this comment, but do you have an example? I find this quite hard to believe. Surely this would have manifested elsewhere and people would have pointed it out ages ago? Nim compiles (or transpiles, if you prefer) to C/C++, after all.

nudpiedo 8y ago
It was very straightforward code looping, counting and storing strings in memory and writing to a file, after 2 years or more I do not keep the code anymore, sorry. Looking in perspective my guess is that the optimized C runtime of python (IO and optimized string references) competed against Nim's bare strings.

gameswithgo 8y ago

>After I realized about python was easily beating Nim in [speed] It is certainly not generally the case that Python beats Nim in speed, not even close. I would imagine something was wrong with your implementation or you hit some weird Nim bug or edge case.

nudpiedo 8y ago
It could be, but remember that python optimizes a lot IO and string manipulation (runtime in C). Based on how the feature list has changed perhaps I tried Nim even earlier than what I said. I also did not want to look for any optimizations since I just used bare constructs and no libs.
- beagle3 8y ago
  Hash tables in nim require pulling in the standard library and are built-in in Python. If you didn’t even “import tables”, you were likely comparing O(1) apples to O(n) oranges.
- nudpiedo 8y ago
  however I did it I am sure I used (imported or not) hash tables or similar from stdlib (no algorithm complexity difference in this regard). But based on the comments from everyone it is reasonable to say that my implementation had something wrong or the test was off in some regard.

sharmi 8y ago

I have not programmed in Nim and I am a Pythonista. Having said that, I had to parse the whole wikipedia dump xml file once and extract just the text. The python code for the same was so slow and would have taken days to go through the whole xml file. In my quest to find something faster, I came across a nim program that would take the xml in and dump a plain text file (or markdown?) file. It did the work within 2 hours. So I don't believe it was slower than python. Nim certainly has it's place and it is more comparable to go in speed.

nudpiedo 8y ago
It was very straightforward code looping, counting and storing strings in memory and writing to a file. Looking in perspective my guess is that the optimized C runtime of python (IO and optimized string references) competed against Nim's bare strings. If you are a pythonista I have a question for you, especially since I could still give Nim a try, how much effort would be for you to add 2 or 3 generators and asyncs in the python code and put in place a better architecture without any macros? how easy is the same thing in Nim without any library our of the standard library? This speed of prototyping and bringing a better architecture to the solution sooner matters a lot more to me than raw speed (that comparison against python in speed was the last drop). I believe you when you say that Nim won, after all they promose that some parsers such as csv parser could fit in the L2 cache and so on... hopefully the language and quality of libraries has improved. P.S. how big was the whole wikipedia as XML? all languages?
- kungtotte 8y ago
  Python is intentionally a kitchen-sink type language that provides everything in its standard library, whereas Nim is intentionally the opposite. More and more things are moved out of its standard library to the package repository (Nimble). Thus, asking someone to write a stdlib-only solution in Nim is a bit of a trick question...

StreamBright 8y ago

+1 I would like to add 2 more things: - there are at least 3 incomplete logging and http server libraries (please provide documentation if you want anybody to use your library) - documentation is not always clear how to use the language

pathsjs 8y ago
As the author of at least one HTTP server library ( https://github.com/andreaferretti/rosencrantz https://github.com/andreaferretti/rosencrantz ) do you find anything missing in its documentation?
- StreamBright 8y ago
  It is actually really nice. Thanks for the link!
nudpiedo 8y ago
I agree also on the point about documentation, this practice was also extended to the community modules (but everything was new and hacky so I thought it was OK, but it ended up being the rule a the ecosystem).
- StreamBright 8y ago
  If you develop a new piece of software, especially a new language, documentation should be there so that the users can get in as fast as possible. I think Elixir is a great example in this regard that Jose paid attention to this feedback early and there is decent documentation for most of the things nowadays (minor exceptions). I have limited time and there are so many new languages, I will go with the one which has the lowest entering barrier.
sp33der89 8y ago
- As far as I know Jester is the go-to for your webservers and you could use the httpclient in the standard library. - This is true and there are plans to improve it, if you have any feedback on what could be clearer, you can share your thoughts here: https://forum.nim-lang.org/t/4523 https://forum.nim-lang.org/t/4523

detaro 8y ago

> python 3 (without any library or optimization) was faster than compiled nim to count words on a moderately large text. Do you still have examples around? I haven't used Nim yet, but it could be interesting to take a look at something like this to understand what happened.

nudpiedo 8y ago
I can check it later when I am back at home but since I regularly clean my projects & prototypes folder I do not think I kept it. The implementation was quite straight forward in both languages: count words and then some statistic counting. It made me think that Nim will end up making me think all the time in the CPU and the compiler in the same way I did when I programmed C (and still high level languages beat the things by achieving much faster cleaner designs/prototypes/high level patterns, etc). To be fair in my initial criticism, I guess a highly skilled Nim developer could beat python on a restricted environment, and in high level async processes both might differ in less than 1% in performance matters; but my code was really trivial and a straight forward iteration.

SolitudeSF 8y ago

> Hate speech against functional concepts in the community are you trolling? > Some arrogant community members were tolerated just because they wrote popular blog posts on Nim implementing a fashionable pet project. for example?

nudpiedo 8y ago
No, I am not trolling, read my other comment on the "hate speech". It was an opinion, do not take it too serious, if you like the language go for it.

dom96 8y ago

Nice list, thank you for compiling it. I'm one of the Nim core devs so I naturally disagree. A lot on the list is painted as a negative, whereas I see it as a positive, in particular: > * A return variable within procedures that works in the same fashion as an assembly routine with a registry Not sure I see the parallels between assembly and I don't understand why you think this feature is negative, can you elaborate? > * Mutable strings I love these! No need for messing around with `StringBuilder` and the like. > * Mutable everything That's simply false. You can choose between mutability and immutability, in fact you can even have an immutable `string` if you really want one: `let x = "asd"`. Now let me discuss some of your other points: > * Hate speech against functional concepts in the community (with all the related biases that this brings) Communities are large. A lot of us love functional programming and are bringing more and more of it into Nim. > * Some arrogant community members were tolerated just because they wrote popular blog posts on Nim implementing a fashionable pet project. Can you elaborate on who this was and how/where they were tolerated? > * no clear consistent design direction > * too many pragmas > * too many pascal syntax mixed with other language syntaxes These are mostly subjective so there isn't much I can say. Perhaps Nim just isn't for you due to its syntax, but many out there love it. > * no module namespacing > * modules worked not much better than C libraries... (I am generalizing) This is false too. Every imported module is in its own namespace. > * python 3 (without any library or optimization) was faster than compiled nim to count words on a moderately large text. Did you compile with -d:release? :)

nudpiedo 8y ago
Hi Dom96, thanks for answering point by point. Unfortunately I cannot answer all of these things since I got this impression about two years ago, and things might have changed or perhaps I got them wrong (as you say some of them are subjective). For example, I cannot tell what compilation option I used but I remember I went for the max speed I could and that I used default Nim language constructs and default python constructs (no libs), the compilation was one of the most sold features so I believe I used the release mode and that there was a marginal difference in favouring of python (subsecond). Think However that python has also many optimizations for string manipulation and that under the cover all runtime objects are references whereas in compiled languages developers are naked in front of the CPU. Knowing that you are core-dev I must say that building a language is very hard, and that by not bringing much to the state of the art and overselling too early it is easy to get compared and valued by subjective aspects or mere impressions. Heads up, keep it with the great work and do not take it personally, make the language shine in some unique aspect. Also do not forget that my comment was just an unfavourable opinion based on some observations I made years ago; I could change my opinion on the language anytime and give it again a chance if it brings me any benefit for my development, or it is fun, or it has some solutions for the problems I need to solve. Thanks for answering.

alehander42 8y ago

Honestly, I feel like you just want different things from your language, and you'd prefer something like Scala or Haskell. I've never heard "hate speech" against functional concepts: I've worked on functional-ish/pattern matching libs and i know other people from the community that love functional lang ideas. However those ideas are not as prevalent as in functional languages tho(obviously). I'd say a lot of those points are very subjective(syntax/pragmas/modules etc). It's true that the ecosystem is still small and documentations is not good enough sometimes: this is something that probably can't change without a stable 1.0 first(and serious doc efforts started last month).

nudpiedo 8y ago
I never used Scala, Haskell or a functional language other than a small pet project on clojure I usually write small functional snippets within OOP for python (so my job colleagues can still understand most of my code/structure). "Hate speech against functional concepts" was a metaphor for repetitive comments without foundation against some concepts and highly respectable design choices, where I often saw people pretending these to be dumb without really discuss the points properly, or exploring choices or constructs without acknowledging any single good thing from it. You can consider that a subjective, generalized opinion if you want. Think that "that functional approach" has a lot to borrow from, even when still working within a mostly imperative language. Perhaps it is not a true red flag but in my eyes it was an involution. Totally subjective if the focus of the language is becoming a better and more advanced C (rival of Golang for example)
- vips7L 8y ago
  That's not hate speech.
  - nudpiedo 8y ago
    No, it is not. It was a metaphor.
    - klibertp 8y ago

narimiran 8y ago

> python was easily beating Nim in speed I'm just guessing here, but did you compile Nim in debug mode? (nim c filename.nim) From my experience, compiling files in release mode (nim c -d:release filename.nim) makes similar tasks run 10-100x faster than Python (usually around 30x for my use cases), and it doesn't require "highly skilled Nim developer" as you mention in your reply.

nudpiedo 8y ago
sorry, I cannot tell it anymore since that was long time ago, the python version probably had a generator; also remember that python's IO and string optimizations are written all in C.

mratsim 8y ago

There are plenty of functional libs in the Nim ecosystem, the prominent ones being: * NimFP[1] * Zero-Functional[2] Disclaimer: my very first language was Haskell and I'm now a Nim core contributor. Mutability: just like Ocaml, Nim has `let` and `const` and mutable function parameters and mutable variable need `var`. Caveat: for reference types, immutability is shallow (you cannot change the reference but you can mutate the reference content). Also many people in Nim community are pushing for more control on mutability, you can see for example the proposition on writetracking[3]. * [1] https://github.com/vegansk/nimfp * [2] https://github.com/zero-functional/zero-functional * [3] https://nim-lang.org/araq/writetracking.html

nudpiedo 8y ago
In my humble opinion on language design, if the main language favours a paradigm or style, the libs will do it even worse although some programming languages gave weird reimplementations of their whole stdlib in a different paradigm it is not the rule. C will be C no matter how much MISRA certifications are sold. For example, kotlin is very promising language on the paper, but in the reality it is being developed by people who kept a Java mindset and way to structure problems and code (and they repeat same concepts and ideas as they do in java, for example calling DSL to every single piece of nested code).
electrograv 8y ago
> Caveat: for reference types, immutability is shallow (you cannot change the reference but you can mutate the reference content). “Shallow immutability” is not just a “caveat” — it’s a complete abuse of the word “immutability”. If you can in-place modify the interior of a so-called immutable value in any way (possibly excepting code within some kind of “unsafe” blocks), it is by definition not immutable. Immutability is a pure, all or nothing kind of thing. That you are trying to present immutability as synonymous with C++ style “const”ness perhaps reinforces the parents’ post that Nim is not friendly or even aware of the functional paradigm of programming. But unlike others, I think it’s okay that it doesn’t support immutable variables. It certainly doesn’t outright condemn the language. However, let’s not pretend it’s something that it’s not.

nepeckman 8y ago

Wow we have had some different experiences. Going down your list, the only thing that has been a problem for me is the ecosystem issues, and that comes with the territory with smaller languages. The most surprising was your issues with speed, which I feel like had to have been a compiler or standard library bug of some sort. I use Nim on a side project with moderate calculations, and it finishes in about the time it takes nodejs to do Hello World. I think most of your list comes down to preference though. Nim isn't a fully FP, immutable language. It supports FP more than Python though, and probably as much as JavaScript does.

beagle3 8y ago

your recollection of your experience with Nim performance is what it is, but it is at odds with just about every other account of Nim, including by people who really dislike it. Your “it was a long time ago, I don’t remember” doesn’t make it credible either. Other comments are more a matter of opinion or view, but with respect to speed or memory use - Nim competes favorably with C++, D, Zig and friends. Neither CPython nor PyPy is in the same league.

Symmetry 8y ago
It's really easy to make C++ code that's slower at reading or writing files than Python if you go about it in an innocent way. https://stackoverflow.com/questions/30197068/why-is-my-c-text-file-parsing-script-so-much-slower-than-my-python-script?rq=1 https://stackoverflow.com/questions/30197068/why-is-my-c-tex... https://stackoverflow.com/questions/9371238/why-is-reading-lines-from-stdin-much-slower-in-c-than-python https://stackoverflow.com/questions/9371238/why-is-reading-l... So I wouldn't be at all surprised if you could make the same mistakes in Nim. But of course it would be unfair to claim that that means Nim is slow in general.

cryptonector 8y ago

All red flags except for this: > * Some arrogant community members were tolerated just because they wrote popular blog posts on Nim implementing a fashionable pet project. Arrogance is a problem, but kicking out a participant should require a bit more than their being arrogant.

rafaelvasco 8y ago

Mutable strings: That depends on the type of application you're doing. In my area, gamedev, it is better that everything is mutable by default and you optin for immutable, since games normaly deal with structures the mutate every frame. In that scenario it is normal to have immutable things getting in your way more than the other way around.

shevegen 8y ago

What a terrible non-sensical list that you gave here. Even more so your claim how python3 is faster. What is wrong with you lying to the people here? Why does ycombinator not outright forbid statements like this? Because this is not an "opinion" - this is a flat out lie from you here.