Comment by zombinedev | Hacker News Reader

Comment by zombinedev | Hacker News Reader

Parent Full thread

To escape the shit show that C and C++ are in their unique ways. In my experience, one of the worst things was working on a proprietary 1M+ LoC codebase. Everything was so painful (despite the feats of engineering being put in the internal infra to support the development processes and the great team members I worked with) that I'll never go back to anything like that if I have the choice.

I'm also dissatisfied with some of the design decisions accepted into C++11/14/17/20. (Some were fixable and just plainly shortsighted IMO, but others probably not, due to the language legacy).

Don't get me wrong, I love learning from the C++ community (conferences, tech talks, blogs and checking out how open-source projects that I'm interested in are implemented), but once that I had tasted the power and freedom of D going back to C++ feels like a huge step in the wrong direction.

And also being not only a user, but a contributor is immensely empowering. A PR to the standard library, runtime, compiler or package manager can take anywhere from days to mere hours (depending on the complexity of change), while attempting a change with a similar impact to C++ would likely take anywhere between months to years. And yes, I can see the value of the ISO C++ standardization process, but it's definitely not for me.

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.

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

> 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/nmwinrjavfumvxffptxy@forum.dlan...) 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.

Reply on news.ycombinator.com