D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[Guillaume Piolat]

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.