3 ms·

> In fact, you could use Nim as a production-ready alternative to the upcoming Carbon language. Nim has fantastic interoperability with C++, supporting template

> In fact, you could use Nim as a production-ready alternative to the upcoming Carbon language. Nim has fantastic interoperability with C++, supporting templates, constructors, destructors, overloaded operators, etc. However, it does not compile to readable C or C++ code, which is unlike Carbon's goals. Well, that really depends on what the reason for one's interest in Carbon is, which is slightly hinted at by the last sentence. From what I understand big goal is to be able to do automated migration of large C++ codebases at Google to a saner language. Mond had a nice blogpost musing about it[0]. Nim is not that. Of course, neither is Carbon yet, and we'll have to wait and see if it reaches that point or if it ends up on killedbygoogle.com. I'm rooting for Carbon though, it's a cool idea. Anyway, that is a different ambition than looking for a successor language that lets you use existing C++ code without requiring that the latter is changed, which is what Nim is suggested to be good at here. [0] https://herecomesthemoon.net/2025/02/carbon-is-not-a-language/ https://herecomesthemoon.net/2025/02/carbon-is-not-a-languag...

zozbot234 1y ago
I'm a bit skeptical about the "fantastic interop" with C++ also. If it was that easy, the Rust folks would have done that already; whereas it seems that they're still looking into it. And Rust is being developed for LLVM, a compiler that's also shared with C++.
- cb321 1y ago
  With `nim cpp` the Nim compiler actually just generates C++ from the Nim source for the backend to compile. So, calling C++ code is just emitting the calls at a C++ source level and so is straightforward. The situation with Rust "sharing" LLVM is very different, as that is not a source-to-source compiler. C++ code calling Nim code is also not usually as straightforward. So, "fantastic" here may apply only in one call direction.
  - miguel_martin 1y ago
    The way to enable C++ code calling Nim is via exportc or exportcpp and by writing a head file with the declarations you are exporting This will require manual work, but you can use macros or a code generation script to help if your api is large.
- jibal 1y ago
  Rust doesn't have an option to generate C++ code; Nim does. > Rust is being developed for LLVM, a compiler that's also shared with C++. Not at all relevant (and LLVM is a backend target, not a compiler).
  - zozbot234 1y ago
    Rust cbindgen has an option to generate C code, which is generally also valid C++.
    - jibal 1y ago
      Also not relevant since it lacks Nim's mechanisms for integrating the generated code with user-provided C++. You said that you questioned Nim's "fantastic interop" but you have no valid logical reason to ... certainly Rust not having it isn't any sort of argument.
  - ModernMech 1y ago
    > (and LLVM is a backend target, not a compiler). LLVM is a backend compiler which compiles to backend targets like x86, which have their own compilers. It's hard to say exactly what a compiler is and isn't, because it's compilers all the way down; compilers are made of compilers. My working definition is a compiler is a program that turns code from one form into another, whether that's machine code, byte code, IR, or some other high level source. It's a broad definition but it covers all the things we call "compilers".
    - jibal 1y ago
      So you have an idiosyncratic definition of compiler that no one else uses. https://en.wikipedia.org/wiki/Compiler https://en.wikipedia.org/wiki/Compiler "In computing, a compiler is software that translates computer code written in one programming language (the source language) into another language (the target language)." https://en.wikipedia.org/wiki/LLVM https://en.wikipedia.org/wiki/LLVM "LLVM, also called LLVM Core, is a target-independent optimizer and code generator.[5] It can be used to develop a frontend for any programming language and a backend for any instruction set architecture. LLVM is designed around a language-independent intermediate representation (IR) that serves as a portable, high-level assembly language that can be optimized with a variety of transformations over multiple passes.[6]"" As I correctly said, LLVM is not a compiler, it is a backend target of Rust, C++, etc. compilers. They read source language and generate backend output ... anything from assembly language to C++. Even when Nim uses the C++ backend, C++ is the backend target, even though the generated C++ is fed to a C++ compiler. End of story and of my participation.
dualogy 1y ago
> Nim has fantastic interoperability with C++ Last year I asked around in the Nim community if "the C++ interop" will allow me to easily link-to-and-import in Nim a C++ lib (in this case, a 3D engine called WickedEngine) and thus make a game using its surface API from Nim instead of writing it all in C++. There seemed to be no straightforward way to do so whatsoever. Sure you can import old-school C APIs. Sure maybe you can have Nim transpile to C++ code. But "fantastic interoperability" didn't have my fantasy here in mind: something like `@importcpp "../libwickedengine/compilecommands.json"` and boom, done, including LSP auto-complete =) It would be the same for other major C++ libs then: think LLVM, Dear Imgui, Qt, OpenCV, libtorrent, FLTK, wxWidgets, bgfx, assimp, SFML...... Sure, I get it, "unlike C, C++ doesn't have an ABI. These C++ libs should maintain and expose a basic C API". I agree! But still..
- elcritch 1y ago
  There's a wrapper for unreal engine using the C++ interopt. It's doable but not automatic. https://github.com/jmgomez/NimForUE https://github.com/jmgomez/NimForUE Mentally I view Nim as a better, safer, easier C++ now. Anything I wanted to do in C/C++ I can do in Nim, but far easier. Not exactly a Carbon competitor but still an alt C++ 2.0 with C++ interopt.
- miguel_martin 1y ago
  This is a bit controversial, but in my opinion, just manually write bindings for the API surface you care about. There are tools to help automate the process ([c2nim](https://github.com/nim-lang/c2nim https://github.com/nim-lang/c2nim), [futhark](https://github.com/PMunch/futhark https://github.com/PMunch/futhark)), but these tools are mostly for C. Theoretically if you want to import a large C++ API (e.g. if you were importing Google's C++ codebase*), you could do so with libclang. I was working on an alternative to c2nim that supported Objective-c and C++, which used libclang, but it's currently in my project graveyard. If you're expecting a @cImport from Zig, then the closest you have to that is tools mentioned above to help with the process. * to be clear, I understand why Google does not want to use Nim instead of creating a new language (Carbon). i.e. readable code output, full control of the compiler and language design, etc. The amount of manual work to write bindings is minimal, i.e. you can do so simply by declaring a prototype for a procedure and then appending `{.importcpp, header: "<path>".}`, the same for types. And then compile with `nim cpp`. Compare the way you wrap libraries in Python, Nim requires so much less work - and yet the Python community wraps every C/C++ library you can think of. Again, in my opinion, if you really want a library: wrap it yourself (ideally the subset you need) or rewrite it in Nim. Also, most of the libraries you have listed have bindings already: - Qt: https://github.com/jerous86/nimqt https://github.com/jerous86/nimqt or [seaqt](https://forum.nim-lang.org/t/12709 https://forum.nim-lang.org/t/12709) - ImGUI: https://github.com/nimgl/imgui https://github.com/nimgl/imgui - SFML: https://github.com/oprypin/nim-csfml https://github.com/oprypin/nim-csfml - SDL: https://github.com/nim-lang/sdl2 https://github.com/nim-lang/sdl2 - sokol: https://github.com/floooh/sokol-nim https://github.com/floooh/sokol-nim If there's a popular enough C or C++ library, it's probably already wrapped, especially within the gamedev community.

zozbot234 1y ago

I'm a bit skeptical about the "fantastic interop" with C++ also. If it was that easy, the Rust folks would have done that already; whereas it seems that they're still looking into it. And Rust is being developed for LLVM, a compiler that's also shared with C++.

cb321 1y ago
With `nim cpp` the Nim compiler actually just generates C++ from the Nim source for the backend to compile. So, calling C++ code is just emitting the calls at a C++ source level and so is straightforward. The situation with Rust "sharing" LLVM is very different, as that is not a source-to-source compiler. C++ code calling Nim code is also not usually as straightforward. So, "fantastic" here may apply only in one call direction.
- miguel_martin 1y ago
  The way to enable C++ code calling Nim is via exportc or exportcpp and by writing a head file with the declarations you are exporting This will require manual work, but you can use macros or a code generation script to help if your api is large.
jibal 1y ago
Rust doesn't have an option to generate C++ code; Nim does. > Rust is being developed for LLVM, a compiler that's also shared with C++. Not at all relevant (and LLVM is a backend target, not a compiler).
- zozbot234 1y ago
  Rust cbindgen has an option to generate C code, which is generally also valid C++.
  - jibal 1y ago
    Also not relevant since it lacks Nim's mechanisms for integrating the generated code with user-provided C++. You said that you questioned Nim's "fantastic interop" but you have no valid logical reason to ... certainly Rust not having it isn't any sort of argument.
- ModernMech 1y ago
  > (and LLVM is a backend target, not a compiler). LLVM is a backend compiler which compiles to backend targets like x86, which have their own compilers. It's hard to say exactly what a compiler is and isn't, because it's compilers all the way down; compilers are made of compilers. My working definition is a compiler is a program that turns code from one form into another, whether that's machine code, byte code, IR, or some other high level source. It's a broad definition but it covers all the things we call "compilers".
  - jibal 1y ago
    So you have an idiosyncratic definition of compiler that no one else uses. https://en.wikipedia.org/wiki/Compiler https://en.wikipedia.org/wiki/Compiler "In computing, a compiler is software that translates computer code written in one programming language (the source language) into another language (the target language)." https://en.wikipedia.org/wiki/LLVM https://en.wikipedia.org/wiki/LLVM "LLVM, also called LLVM Core, is a target-independent optimizer and code generator.[5] It can be used to develop a frontend for any programming language and a backend for any instruction set architecture. LLVM is designed around a language-independent intermediate representation (IR) that serves as a portable, high-level assembly language that can be optimized with a variety of transformations over multiple passes.[6]"" As I correctly said, LLVM is not a compiler, it is a backend target of Rust, C++, etc. compilers. They read source language and generate backend output ... anything from assembly language to C++. Even when Nim uses the C++ backend, C++ is the backend target, even though the generated C++ is fed to a C++ compiler. End of story and of my participation.

dualogy 1y ago

> Nim has fantastic interoperability with C++ Last year I asked around in the Nim community if "the C++ interop" will allow me to easily link-to-and-import in Nim a C++ lib (in this case, a 3D engine called WickedEngine) and thus make a game using its surface API from Nim instead of writing it all in C++. There seemed to be no straightforward way to do so whatsoever. Sure you can import old-school C APIs. Sure maybe you can have Nim transpile to C++ code. But "fantastic interoperability" didn't have my fantasy here in mind: something like `@importcpp "../libwickedengine/compilecommands.json"` and boom, done, including LSP auto-complete =) It would be the same for other major C++ libs then: think LLVM, Dear Imgui, Qt, OpenCV, libtorrent, FLTK, wxWidgets, bgfx, assimp, SFML...... Sure, I get it, "unlike C, C++ doesn't have an ABI. These C++ libs should maintain and expose a basic C API". I agree! But still..

elcritch 1y ago
There's a wrapper for unreal engine using the C++ interopt. It's doable but not automatic. https://github.com/jmgomez/NimForUE https://github.com/jmgomez/NimForUE Mentally I view Nim as a better, safer, easier C++ now. Anything I wanted to do in C/C++ I can do in Nim, but far easier. Not exactly a Carbon competitor but still an alt C++ 2.0 with C++ interopt.
miguel_martin 1y ago
This is a bit controversial, but in my opinion, just manually write bindings for the API surface you care about. There are tools to help automate the process ([c2nim](https://github.com/nim-lang/c2nim https://github.com/nim-lang/c2nim), [futhark](https://github.com/PMunch/futhark https://github.com/PMunch/futhark)), but these tools are mostly for C. Theoretically if you want to import a large C++ API (e.g. if you were importing Google's C++ codebase*), you could do so with libclang. I was working on an alternative to c2nim that supported Objective-c and C++, which used libclang, but it's currently in my project graveyard. If you're expecting a @cImport from Zig, then the closest you have to that is tools mentioned above to help with the process. * to be clear, I understand why Google does not want to use Nim instead of creating a new language (Carbon). i.e. readable code output, full control of the compiler and language design, etc. The amount of manual work to write bindings is minimal, i.e. you can do so simply by declaring a prototype for a procedure and then appending `{.importcpp, header: "<path>".}`, the same for types. And then compile with `nim cpp`. Compare the way you wrap libraries in Python, Nim requires so much less work - and yet the Python community wraps every C/C++ library you can think of. Again, in my opinion, if you really want a library: wrap it yourself (ideally the subset you need) or rewrite it in Nim. Also, most of the libraries you have listed have bindings already: - Qt: https://github.com/jerous86/nimqt https://github.com/jerous86/nimqt or [seaqt](https://forum.nim-lang.org/t/12709 https://forum.nim-lang.org/t/12709) - ImGUI: https://github.com/nimgl/imgui https://github.com/nimgl/imgui - SFML: https://github.com/oprypin/nim-csfml https://github.com/oprypin/nim-csfml - SDL: https://github.com/nim-lang/sdl2 https://github.com/nim-lang/sdl2 - sokol: https://github.com/floooh/sokol-nim https://github.com/floooh/sokol-nim If there's a popular enough C or C++ library, it's probably already wrapped, especially within the gamedev community.