Re: New "Learn Nim" page
@Prohyon it's actually the other way around. When you use a `for` loop with 1 iterator (e.g. `for i in 0 .. 9:`) you are iterating over **values**. If you want to also have the corresponding index of each loop you have to do ` for i, v in 0 .. 9:`, then `i` will be the index and `v` the value. Also keep in mind that `mod` is an expensive function, you should try to avoid it if possible.
Re: List of pending CT evaluation features
Of course other constructs can be used instead, but with this logic you could also use a different program just to calculate what is known before (main program's) runtime, and then somehow pipe the results into your program. The whole point of metaprogramming is **flexibility**. Using closure iterators and dynamic dispatching idioms and still getting CTE would be awesome, and it 's certainly doable! The VM **is** _a runtime_ so there is no restriction; it can emulate the runtime phase and resolve dynamic behavior.
Re: List of pending CT evaluation features
CTE for methods is missing. There must be more.
List of pending CT evaluation features
Recently I found out about CTFE and started reading all about it. I am very pleased to discover that Nim is currently the #1 language on this topic! Dlang is catching up; they are developing a new [bytecode VM](https://dlang.org/blog/2017/04/10/the-new-ctfe-engine/) for CTFE just like Nim has for years now (vmdef.nim). Recently [attempts](https://github.com/nim-lang/Nim/pull/10150) to provide the missing FFI support begun! What are all the features that Nim _could eventually_ that you can think of? I know this is not top priority stuff, but it would be nice to concentrate all the CT pending features in one place (maybe github RFC issue).
Re: Convincing my friend about Nim
I have this feeling that the particular quote of Araq will become really famous and be remembered. So happy I was the one asking! :D
Re: Saying hi
So... is this accurate? **Today:** Each thread has its own memory heap and GC. This eliminates pauses and race conditions but impairs efficiency because the communication between threads is less nimble (can only exchange messages but no other data). **Tomorrow:** ARC will allow a shared-memory model implementation. This will improves data locality significantly and eliminate the need for message passing, all while retaining safety.
Re: Saying hi
Message Passing is not enough?
Need guidelines for contributing bugfixes
Hi, I want to eventually start fixing bugs and I worry about misusing git (it's probably just my lack of experience). The [relevant article](https://nim-lang.github.io/Nim/contributing.html) doesn't go into details about branching. I considered a couple of strategies and I am not sure which one the maintainers prefer: * Common first step: Create a `branch` off devel * Common last step: Make the PR * * * * Strategy 1: Just push the `branch` to the fork * Strategy 2: Merge `branch` with `upstream/devel`, then push to the fork * Strategy 3: Rebase to `upstream/devel`, then push to the fork
Re: Saying hi
I barely dare to ask because it might be self-explanatory... but if you can put it briefly: how will destructors aid concurrency? (I've seen the relevant articles and videos on destructors but still can't make the connection)
Re: Functional Programming in Nim
Regarding that... what is currently the preferred way to do laziness in Nim? Hand-writing closure iterators works, but is there any established library? I know of [lazy](https://rawgit.com/petermora/nimLazy/master/doc/lazy.html) and [iterutils](https://hookrace.net/nim-iterutils/iterutils.html), but it's unclear if I should use one (which?) of them.
