41–50 of 94 posts
It's feels like a shame to me that the one Python maxim that Nim has chosen to reject is "there should be one and preferably only one way to do it" - from this flows so much of the other goodness of the Python ecosystem. I worry that some of the metaprogramming magic that Nim allows will result in the loss of that feeling that I can view source on almost any 3rd party Python code and immediately feel like I can follo…
It's feels like a shame to me that the one Python maxim that Nim has chosen to reject is "there should be one and preferably only one way to do it" - from this flows so much of the other goodness of the Python ecosystem. I worry that some of the metaprogramming magic that Nim allows will result in the loss of that feeling that I can view source on almost any 3rd party Python code and immediately feel like I can follo…
Nim needs to move it's discussions to a mailing list if the authors want to gain more serious developers onboard. Polling a poorly implemented web forum speaks leaps and bounds about the kind of attitude you need to have to discuss, develop or debug issues around the Nim toolchain. This is something that Nim developers can instantly do to boost the attractiveness of the language. Please, do this.
Well, it's the kind of attitude that let me contribute to the language, and fix bugs despite being rather new to it all, so I'll be honest and say that I think it's quite good. Aside from that, the IRC channel is always super busy and amazingly helpful. I think a mailing-list is a good thing, sure, but it's not the be-all-end-all, in my humble opinion.
Earlier quoted context omitted.
This is more of an option than you might think. Nim plugs in to C libraries much easier than you would expect from an FFI. That means even if the stdlib depends on the GC heavily, you can eschew it for the C stdlib. For example: proc printf(formatstr: cstring) {.header: " ", importc: "printf", varargs.} I'd be interested in seeing a comparison of higher level language features rather than performance (which is genera…
Wow, that's a pretty cool insight. Basically that means you could use "Nim without GC" as "a better C". I can see very few downsides. You could probably start using it in existing C projects much like you could start adding .scala files to an existing Java project.
One thing they both lack that hinders wider adoption : good IDE support. For me YouCompleteMe support is the only thing preventing me from switching for my side projects.
How can you base the choice of a language solely on that?
It's feels like a shame to me that the one Python maxim that Nim has chosen to reject is "there should be one and preferably only one way to do it" - from this flows so much of the other goodness of the Python ecosystem. I worry that some of the metaprogramming magic that Nim allows will result in the loss of that feeling that I can view source on almost any 3rd party Python code and immediately feel like I can follo…
On the other hand, it's quite convenient if you can't remember the exact name and it saves you a look-up e.g. quick_sort vs quicksort vs quickSort - either work
> It’s mysterious that Rust’s release version with -i ran slightly faster, though. That's actually not surprising: a large fraction of time is spent in the map lookup, which in Rust is implemented as a B-tree, thus lookup time is (mildly) dependent on the map size. If keys are lowercased before inserting them, the map ends up having fewer elements. The Nim version uses instead hash tables, whose lookup time is near-c…
This was not the case in my benchmarks: the Rust spent 60% of its time doing regex matches, 25% allocating strings and less than 6% manipulating the map.
It's feels like a shame to me that the one Python maxim that Nim has chosen to reject is "there should be one and preferably only one way to do it" - from this flows so much of the other goodness of the Python ecosystem. I worry that some of the metaprogramming magic that Nim allows will result in the loss of that feeling that I can view source on almost any 3rd party Python code and immediately feel like I can follo…
On the other hand, it's quite convenient if you can't remember the exact name and it saves you a look-up e.g. quick_sort vs quicksort vs quickSort - either work
It's feels like a shame to me that the one Python maxim that Nim has chosen to reject is "there should be one and preferably only one way to do it" - from this flows so much of the other goodness of the Python ecosystem. I worry that some of the metaprogramming magic that Nim allows will result in the loss of that feeling that I can view source on almost any 3rd party Python code and immediately feel like I can follo…
It's definitely unusual, but I think it works quite well.
Nim needs to move it's discussions to a mailing list if the authors want to gain more serious developers onboard. Polling a poorly implemented web forum speaks leaps and bounds about the kind of attitude you need to have to discuss, develop or debug issues around the Nim toolchain. This is something that Nim developers can instantly do to boost the attractiveness of the language. Please, do this.