miguel_martin

See also: Nim's std/selectors API - https://nim-lang.org/docs/selectors.html, it supports: "Supported features: files, sockets, pipes, timers, processes, signals and user events." - here's a HTTP server event loop using it: https://github.com/guzba/mummy/blob/master/src/mummy.nim#L11...

This is what an AGENTS.md - https://agents.md/ (or CLAUDE.md) file is for. Put common constraints to correct model mistakes/issues with respect to the codebase, e.g. in a “code style” section.

What about simply providing value?

You can compile to wasm, I have done so via the XNNPACK backend - you might have to tweak the compilation settings and upgrade the XNNPACK submodule/patch some code. But this only supports CPU, not a WebGPU or WebGL backend.

Why are Nim, Odin, Zig, Mojo not included (and probably many others)?

With the uptime guarantees AWS, GCS, DO, etc. provide - it will probably 1h per 365 days accumulative (@ 99.99% uptime). 2 nodes for a simple static site is just overkill.

But, honestly, for this: just use github pages. It's OSS and GitHub is already used. They can use a separate repository to host the docs if repo size from assets are a concern (e.g. videos).

When I used to use emacs to write code I did this, but it would be great if I could use tramp instead, unfortunately the latency is unbearable.

Also, when compared to neovim, the latency for auto-completion (with LSP as a source) is also unbearably slow. Even with libgccjit enabled.

Now I only stick with emacs for org mode. Maybe I'll try it again, but neovim is just faster.

Also checkout blaze: https://gasiulis.name/parallel-rasterization-on-cpu/

Not one mention of SSH or remote development. Life must be nice to do development on a single machine. Tramp on Emacs is not ideal.

Not rust, but check out nimwave: https://github.com/ansiwave/nimwave

If your really want to use the keyword def instead of proc: you can do that with sed.

In all serious-ness, don't do that. I've used Python a lot, but Nim is a different language. Writing the proc keyword helps condition your brain to realize you are writing Nim, not Python.

> language like his personal compiler development playground

re personal compiler development playground: I don't see this for Nim 2. Nimony/Nim3 is more of a "playground", but rightfully so: he is creating a new major version of the language and aiming to improve the architecture of the compiler.

> He is also very difficult to work with and isn't very welcoming to newcomers

I don't have full context on the drama behind the fork, but I don't see Araq not being very "welcoming". Araq replies on the forums very consistently, replying to new-comer questions, which one might consider as "simple questions". Araq will state his personal & honest opinions, which may come off as abrasive or "un-welcoming" in your opinion. I don't agree with everything he says but that's OK.

From what I can tell the fork seems to be due to differences in direction of the language and w.r.t working together: differences in communication styles. But again, I don't know.

Personally, I see no reason to use the fork (Nimskull) over Nim, nor would I ever see any individual or company picking up Nimskull unless they were very deeply familiar with Nim (this is a small population of people). From a skim of the Nimskull repo, there is no website (there is a copy of the Nim manual), no forums (just some chatrooms), no clear documentation on the future direction, no documentation on differences for someone not familiar with Nim, etc. - why would anyone pick up Nimskull unless they knew Nim well? Please take this as constructive criticism. e.g. if any feature of the language/compiler/tooling is "better" or planned to be better: highlight it, summarize the long GitHub issue/projects discussions in a blog, etc.

This is incredible.

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.

To be clear, you can compile to WASM with emscripten. However, if you want to call JavaScript code, e.g. to interact with the DOM from WASM in browser, then the bindings that are declared in the standard library will not work.

Instead, you will need to write your own bindings. Here's an example repository of mine using emscripten with Nim: https://github.com/miguelmartin75/nim-wasm-experiments and here are bindings to emscripten's C API for websockets: https://github.com/miguelmartin75/nim-wasm-experiments/blob/...

With emscripten, you can create bindings to JavaScript using EM_JS macros, which you can emit in Nim. Here is an example of how to do so: https://github.com/treeform/windy/blob/bc98d4642c700f0277551...

I actually prefer atlas (see: https://github.com/nim-lang/atlas) to nimble now, it clones dependencies to to a local `deps/` folder relative to the project. It also supports adding local folders to the nimble path for management (via `atlas link` - see docs here: https://github.com/nim-lang/atlas/blob/master/doc/atlas.md#l...), i.e. you can clone your dependencies yourself via git submodule or a manual git clone

To solve your woes, fork and patch the code you need to in order to support pragmas for MSVC. And in atlas, use your fork's git path and if you choose to: submit a PR to the project. You can edit the project locally until something works.

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), [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 or [seaqt](https://forum.nim-lang.org/t/12709)

- ImGUI: https://github.com/nimgl/imgui

- SFML: https://github.com/oprypin/nim-csfml

- SDL: https://github.com/nim-lang/sdl2

- sokol: 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.

And there is support for unicode operators: https://nim-lang.org/docs/manual.html#lexical-analysis-unico... :)

Yeah, perhaps I should have made that more clear, but I did mention these are "*some* of Nim 2's features". I didn't want my post to be a copy-pasta of the Nim manual. The post is already pretty long, so I chose to prioritize the features of the language I am biased toward.

Also, I did mention operator overloading in my first bullet point on language design, but perhaps I should have highlighted it further.

Nim 2 does not have a mandatory gc.

It is recommended to use ARC, which has similar semantics to C++, ie moves, copies, etc.

Unlike D, the GC is not mandatory for the standard library.

I don’t think this is the only reason.

You could do this with Nim, Nim 2’s ARC model is compatible with c++’s RAII. Nim supports moves, destructors, copies, etc. see https://nim-lang.org/docs/destructors.html

You can import C++ classes, member functions, free functions, etc. easily with importcpp

importcpp for the code you are incrementally porting over. You could write a libclang script to do this for you. Exportcpp for what you any code that have been ported but have dependencies in C++ land.

My best guess is they want C++ compatibility and a new language due to preferences, more control over the compiler, etc. which are all valid reasons

Nim would be the best choice for this at the moment, imho

importcpp what you need. exportcpp for the other way around

Nim 2 doesn’t require gc, with arc/atomicArc. The only thing you really need to be careful about is when you use ref types or custom owning types. Otherwise, manual memory management can be done in Nim pretty easily.

Hypothetically you could importcpp fns, classes, etc when compiling with nim cpp

>“… Note that I'm not an expert, in anything, so take everything I write about with a grain of salt I guess :).”

>”I’m by far an expert and I could be wrong in some specifications”

You’re missing a “not” on that 2nd sentence ;)

In all seriousness, you don’t need this disclaimer, you’re selling yourself short.

There’s nothing wrong with your post to make the disclaimer.

And if there is something wrong with the post, let the comments flood in and tell you that rather than yourself.

Found a comparison: https://github.com/jj-vcs/jj/blob/main/docs/sapling-comparis...

How does this compare to sapling? https://github.com/facebook/sapling

Python debugging is great when you're strictly debugging Python code. Placing a `breakpoint` or spinning up an IPython instance to investigate the issue via `import IPython; IPython.embed()` makes life breezy. For neovim, you can send code to the ipython REPL easily via vim-slime.

I've never found myself debugging the underlying C++ code unless developing a C++ extension. But is it really that hard? Just point lldb to the python process and run your script in lldb.

If the C++ is not yours & assuming it's a mature lib (e.g. PyTorch): it's probably an error caused by you in Python land.

Nim is a likely a pretty good option, see https://github.com/EmbeddedNim/picostdlib/tree/master

See pybind11 or nanobind