Hacker News Reader

Comment by transfire | Hacker News Reader

Is there any sane reason to choose C++ any more? Crystal is such a better AOT statically typed OOPL.

The ecosystem around C and C++, existing projects. C++ code is known to be able to build millions of lines of projects. IIRC, Crystal still struggles there, though I think the last year has had improvements there? To be fair, C++ does as well, but how it struggles is better documented.

I'd bet that C++ gives you more low level control than Crystal does, though I'm not deeply familiar with Crystal.

Zig and Rust both seem to eat at the space that C++ occupies more than what I've seen out of Crystal, but I have not followed it closely at all, so I could well be wrong there. Crystal feels closer to the Ruby flavor to Nim's Python flavor, and I know syntax doesn't imply low-levelness, but yeah.

You can certainly write very low-level Nim code though, seeing that things like Arraymancer (high-performance tensor library) and Chronos (an async runtime) are written in pure Nim. Everything you can do in C you can certainly do it in Nim (event better, with generics/templates/macros helping you out). And once the garbage collector is finally removed for the new ARC/ORC runtime (think of Objective-C-like reference counting, but much better), it’s definitely a language that can compete with C++/Zig/Rust.

> The ecosystem around C and C++, existing projects.

Except that with D you can use C++ ecosystem rather seamlessly and still have a GC which enables one to not worry about memory management too much. Everyone likes to bash at D's GC, yet it's one of the huge improvements over C++, it doesn't get in the way and you can also deactivate it. The other huge improvement is the saner language. Zig can also do C interop to a certain extent.

  https://dlang.org/spec/cpp_interface.html
  https://dlang.org/spec/interfaceToC.html
  https://ziglearn.org/chapter-4/

> Crystal feels closer to the Ruby flavor to Nim's Python flavor

Crystal is to Ruby like what Nim is o Python, except that it's done right with a real LLVM based compiler instead of compiles-to-C nonsense, although I'd wish they copied more APIs out of Ruby. Ruby also compiles to C if you enable MJIT. I don't understand the need for a brand new language to do that when one could have Python do it (like Nuitka does but through the official compiler). Instead they chose to write something like Vala, except Vala was designed that way with a purpose in mind (to build upon GObject).

The memory management can be quite suboptimal. I wrote the same program in both at one point (an experimental language transpiler) and the Crystal version would spiral up into the 10s of GB when converting a very simple file while the C++ version wouldn't even hit 1 GB.

No doubt there was something I could have done to coax it into behaving, but in C++ that was unnecessary. RAII and ordinary standard library containers were enough to make it work.

This was a while ago, so perhaps things have improved.

Crystal is managed memory, C++ isn't. C++ gives a level of control and performance that Crystal, Nim, Java, Common-Lisp don't, even if they're quite close performance-wise. Only Rust (and maybe Zig) truly compete with C++. The rest compete with Java.

Reply on news.ycombinator.com