[ibobev]

But, actually Nim compiles to C or very simplistic C++ without requiring you to write C, nor C++. For this reason there are no complications with the new C++ standards and even there is no requirement to understand C or C++. But you can easily use every C or C++ library (even the template ones) and the amount of good quality C and C++ libraries is really very huge. Almost every modern language has capabilities for linking to C, but with C++ the things are not so simple, because of the non standard ABI, across different compilers. With templates the things are becoming even more complicated. For now the easiest and the most reliable way to use C++ libraries from another language is to compile it to C++. Also by compiling to C or C++ you almost automatically cover every platform whether C or C++ compiler is available with very little special support required in the Nim compiler.

[earenndil]

D can also use C and C++ libraries (including templates), and with gcc and llvm it covers pretty much all the same architectures/platforms as nim.

> with C++ the things are not so simple, because of the non standard ABI, across different compilers. With templates the things are becoming even more complicated. For now the easiest and the most reliable way to use C++ libraries from another language is to compile it to C++

This turns out not to be true. The only way to parse C++ is to use a C++ compiler; there is no negotiability there. However you can, as calypso[1] and dpp[2] (latter is not ready for primetime yet) do, use the c++ compiler to parse the c++ and then emit bindings in another language. As for ABI, there are really only two ABIs: msvc (which microsoft uses), and itanium (which everyone else uses). And D already implements both.

1: https://github.com/Syniurge/Calypso

2: https://github.com/atilaneves/dpp

[ibobev]

> D can also use C and C++ libraries (including templates), and with gcc and llvm it covers pretty much all the same architectures/platforms as nim.

Thank you for the suggestion. It turns out to be correct. Obviously there is a huge amount of progress since the last times I had been looking at D, before more than 7 years. (https://dlang.org/spec/cpp_interface.html) Still the D way looks to me more inconvenient by requiring you to include the class internals into the D binding. Example from the D manual:

  extern(C++):
  struct Foo(T)
  {
    private:
    T field;

    public:
    @disable this();
    T get();
    void set(T t);
  }

Nim requires you only to mention the name of the class (template) and the public part of the interface which you actually going to use. Example from the Nim manual (https://nim-lang.org/docs/manual.html#importjs-pragma-import...).

  type StdMap {.importcpp: "std::map", header: "<map>".} [K, V] = object
  proc `[]=`[K, V](this: var StdMap[K, V]; key: K; val: V) {.importcpp: "#[#] = #", header: "<map>".}

  var x: StdMap[cint, cdouble]
  x[6] = 91.4

> with gcc and llvm it covers pretty much all the same architectures/platforms as nim

I am not sure whether they cover some really old platforms. By compiling to C you can target pretty much every platform which have a C89 standard conforming compiler.

A day ago I asked in the Dlang forum (https://forum.dlang.org/post/[e-mail]...) whether it is possible to develop in D for video game consoles, not only current generation which Remedy Games do for example, but also a few generations back. It turns out to not be completely clear, because maybe no one has tried it, but it was suggested that even if possible, probably it would require a considerable amount of tinkering. I don't know whether someone tried this in Nim but it seems to me, that by compiling to C89 or C++98, it would not be much an issue for every platform with a conforming compiler for these languages.