D and nim are both very promising.
I created this git repo to compare them:

https://github.com/timotheecour/D_vs_nim/

Goal: up to date and objective comparison of features between D and nim (to help deciding what language to use), and 1:1 map of features and libraries to help D users learn nim and vice versa.

PRs are welcome and merged fast

On Tuesday, 27 March 2018 at 01:25:42 UTC, timotheecour wrote:
> D and nim are both very promising.
> I created this git repo to compare them:
>
> https://github.com/timotheecour/D_vs_nim/
>
> Goal: up to date and objective comparison of features between D and nim (to help deciding what language to use), and 1:1 map of features and libraries to help D users learn nim and vice versa.
>
> PRs are welcome and merged fast

Sometimes I want to use a debugger like gdc. If it works, it can be really useful. I skipped trying out Nim, because debugging was not really supported. I wonder, if this is fixed now

On Tuesday, 27 March 2018 at 01:25:42 UTC, timotheecour wrote:
> D and nim are both very promising.
> I created this git repo to compare them:
>
> https://github.com/timotheecour/D_vs_nim/
>
> Goal: up to date and objective comparison of features between D and nim (to help deciding what language to use), and 1:1 map of features and libraries to help D users learn nim and vice versa.
>
> PRs are welcome and merged fast

It seems you made up your mind, but some of your points are definately up to debate:

- ability to write file during CTFE is not necessarily positive. THough I can't tell why from the top of my mind.

- Nim doesn't lose points for not being able to use heap objects in CTFE.

- the ability to generate C breaks type system guarantees like memory safety. It's like how inline assembly breaks optimizers and type system, and is annoying to implement. It makes the language more "powerful" hence less easy to reason about.

- Some of use prefer DDoc to Markdown, which is a language where everything always parses.

- AST macros are not necessarily easier or more tractable, which have been argued repeatedly by Walter in these forums. The avoidance of AST macros is a plus, not a minus.

- Likewise, distinction between traced and untraced pointers is exactly what D designers didn't want.

Last time I tried Nim, the Javascript generation didn't preserve semantics. You would write "a.member = 2" and it would generate "a.member = 2", without consideration of memory model. It seems Nim's memory model depend on whatever language it generates.

On Tuesday, 27 March 2018 at 12:11:58 UTC, Guillaume Piolat wrote:
> - ability to write file during CTFE is not necessarily positive. THough I can't tell why from the top of my mind.

Only thing I can think of is that 3rd party modules can end up writing to your file-system during compilation and could potentially access data etc. they're not allowed to.

That is because you may invoke your compiler with the highest permissions possible, but not necessarily the compiled binary file.

Which means that the compile-time may not have any restrictions at all and thus potentially security holes are open.

Whereas the run-time will be limited and restricted.

However by allowing writes etc. at compile-time then the restriction at run-time suddenly doesn't matter, because libraries can just do what they want during compile-time and you don't really want to limit the compiler's permissions etc. because some things may be needed at compile-time that aren't necessarily things you want your run-time to access.

I don't know if that makes sense though, but I tried to explain my reasoning as much as I could.

In my eyes, it's definitely a no-go to allow writes at compile-time, especially without restrictions. (I don't know if Nim has any restrictions, but doesn't sound like it.)

> - AST macros are not necessarily easier or more tractable, which have been argued repeatedly by Walter in these forums. The avoidance of AST macros is a plus, not a minus.
>

Sometimes it's much simpler to use mixins, mixin templates etc. than constructing AST nodes.

I think this really comes down to taste.

However AST nodes seem to be more flexible to manage, but they also open up a lot of complexity.

I guess there is no real answer to that, as it'll always be a biased answer.

On Tuesday, 27 March 2018 at 01:25:42 UTC, timotheecour wrote:
> D and nim are both very promising.
> I created this git repo to compare them:
>
> https://github.com/timotheecour/D_vs_nim/
>
> Goal: up to date and objective comparison of features between D and nim (to help deciding what language to use), and 1:1 map of features and libraries to help D users learn nim and vice versa.
>
> PRs are welcome and merged fast

Named parameter arguments is an advantage? I would not consider using a language with named parameter arguments. At best, claiming it's an advantage is arbitrary.

You might have better luck comparing the languages if you got rid of the +1/-1 thing.

On Tuesday, 27 March 2018 at 14:51:30 UTC, bachmeier wrote:
> On Tuesday, 27 March 2018 at 01:25:42 UTC, timotheecour wrote:
>> D and nim are both very promising.
>> I created this git repo to compare them:
>>
>> https://github.com/timotheecour/D_vs_nim/
>>
>> Goal: up to date and objective comparison of features between D and nim (to help deciding what language to use), and 1:1 map of features and libraries to help D users learn nim and vice versa.
>>
>> PRs are welcome and merged fast
>
> Named parameter arguments is an advantage? I would not consider using a language with named parameter arguments. At best, claiming it's an advantage is arbitrary.
>
> You might have better luck comparing the languages if you got rid of the +1/-1 thing.

I agree with you. A lot of the parameters selected seem arbitrary. A lot of the advantages and disadvantages aren't absolute, but rather things that depend on the exact situation at hand

On 3/27/2018 5:11 AM, Guillaume Piolat wrote:
> - ability to write file during CTFE is not necessarily positive. THough I can't tell why from the top of my mind.

The act of compiling a buggy program not influence the global state of the computer. It should not be necessary to vet code downloaded from the internet before even compiling it to ensure it doesn't mess up the system.

CTFE should run in a sandbox. It must be safe to compile code.

On Tuesday, 27 March 2018 at 04:46:21 UTC, meppl wrote:
> On Tuesday, 27 March 2018 at 01:25:42 UTC, timotheecour wrote:
>> ...
>
> Sometimes I want to use a debugger like gdc. If it works, it can be really useful. I skipped trying out Nim, because debugging was not really supported. I wonder, if this is fixed now

I wanted to write "gdb" of course.
There is an article about debugging nim:
https://nim-lang.org/blog/2017/10/02/documenting-profiling-and-debugging-nim-code.html#using-gdb-lldb

Did they figure out how to pass data between threads?

On 2018-03-27 23:49, Walter Bright wrote:

> The act of compiling a buggy program not influence the global state of the computer. It should not be necessary to vet code downloaded from the internet before even compiling it to ensure it doesn't mess up the system.

There's usually nothing that prevents the build tool to write files at build time. Dub can do this.

-- 
/Jacob Carlborg