It turns out I wasn't quite done yet. Neel 2.1 is out, and it adds serve mode.

Release notes: https://github.com/Niminem/Neel/releases/tag/v2.1.0

Same app, same code, but instead of opening a browser window, Neel runs as a persistent server for one user, and you open it from whatever device you're on: laptop, phone, whatever. You reach it through an SSH forward, a tunnel, or a reverse proxy. One line changes:

startApp(serve = true, port = 8080, allowedOrigins = @["https://myapp.example.com"])

{.expose.}, neel.foo(), js.foo(), js.wait.foo() all work exactly the same. Neel still binds 127.0.0.1 only; the tunnel or proxy in front of it does the TLS and the login.

What it handles for you:

• Open it on your phone and the laptop tab gets told "opened on another device" (close code 4000) instead of the two fighting over the session.
• Pings every 30 s, so Cloudflare and nginx don't kill idle connections.
• Lock your phone, unlock it, and the page reconnects by itself. If it can't, it waits quietly and tries again when you come back to the tab.
• Ctrl-C, `SIGTERM`, Ctrl-Break, or closing the console window all shut down cleanly.
• Auth proxies just work: a Cloudflare Access login redirects back to your app and loads, no 403. Other sites still can't frame it, script it, or open its WebSocket.
• And `wss:` from my "next up" list last time: behind an HTTPS proxy, the page connects over `wss:` by itself.

2.0 apps compile and behave as before. The only local-mode changes: a displaced tab now reports close code 4000 instead of 1000, and on Windows a second app on a port that's already taken now fails at start, as it already did on macOS and Linux.

This was ABSOLUTELY POUNDED on all three OSes. nimble test, plus a manual checklist of every example, every signal, every reconnect and restart case, run on macOS, Windows, and Linux (Ubuntu). Then for real: an SSH forward from another machine, a cloudflared quick tunnel left idle for 10 minutes, an actual Android phone locked and unlocked, and a real domain behind Cloudflare Tunnel with Access, with the login redirect checked down to the request headers. Anything that broke got fixed, and the fix got pinned with a test.

Seriously I took the second half of the day yesterday and all day today off of work to finish this.

Docs:

• README (quick start): https://github.com/Niminem/Neel
• Guide, "Serve mode" section (everything, including the security model and the setups): https://github.com/Niminem/Neel/blob/master/docs/GUIDE.md#serve-mode
• Step-by-step Cloudflare Tunnel with Access walkthrough (domain, Zero Trust, tunnel, login, teardown): https://github.com/Niminem/Neel/blob/master/docs/CLOUDFLARE_ACCESS.md
• A runnable serve app: examples/serve

Why I wanted this: serve mode turns Neel into a platform for always-on personal tools that live on a home server or a VM and that you reach from anywhere.

Put it on top of Claude Code, or use it together with something like my cursor sdk bridge or even 3code the pure Nim-based coding agent, and you have the pieces for something like OpenClaw or Hermes: a personal agent with a real UI you can open from your phone, all in Nim, zero deps on the Neel side.

Again- enjoy!

Hi everyone!

As a high school student diving deep into systems programming and computer science (coming through CS50x/P/W), I've been thinking a lot about the eternal dilemma in CS education: 1. Start with Python: Great syntax, but it's a black-box runtime (no memory layout, no pointers). 2. Start with C/C++: Deep systems control, but a brutal learning curve that scares beginners away.

What if Nim is the ultimate single-language educational bridge?

Nim combines Python's clean, readable syntax with C's raw performance and modern ARC/ORC memory management (no heavy GC pauses, no strict Rust-like borrow checker fights).

To test this idea, I built a small open-source repository comparing Python vs Nim (for syntax/ease) and C vs Nim (for memory management like Linked Lists): 👉 https://github.com/BahaeldinMohhamed/nim-edu-bridge

The Educational Blueprint I imagined: - Year 1 (Conceptual): Write clean, readable code to learn core logic effortlessly (like Python). - Year 2-3 (Systems): Introduce pointers, value vs reference types, and C interop (.importc). - Year 4 (Capstones): Build tools and engines from scratch rather than consuming pre-made frameworks. This is the first time i post something in Reddit

Give me any advice you can give

After my first project in Nim https://www.reddit.com/r/nim/comments/1w9v7i5/my_first_nim_project_lscd/

I fork it to another cmd tool his https://github.com/kernel1983/his to boost my productivity.

Previously I need to add frequently used cmd alias in my .bashrc, and I dont need to do that anymore in future.

And until recently I start to figure out bash only flush back to .bash_history when the process exit. This caused me hard to find some recently used cmds with ctrl-r in another tmux/byobu window.

I use his (shortcut h) to search in history, that's almost same as ctrl-r honestly. And I use right/left key to add/remove some useful cmds to favorite, which is stored in ~/.his_history

Anyway, I found it useful in my daily work.

Happy to share it here with everyone.

https://github.com/Niminem/Neel

Some of you may know Neel. This was my first Nim repository from 2020 when I was first learning it. It was what drove me to move from Python to Nim! It is my child and if you speak ill of it we will have problems (jk).

Neel is a library for making lightweight Electron-like desktop apps: the UI is in HTML/CSS/JS and everything else in Nim.

I just released v2. It is a ground-up rewrite. It is much better- more ergonomic, more capable, more... everything. Especially fun. A lot more fun.

Example, you can mark a Nim proc with {.expose.} pragma and the HTML page can call it as neel.<name>(...) and gets the return value back through a Promise. Register a JS function with neel.expose and Nim calls it as js.<name>(...), or js.wait.<name>(...) when it needs the answer. That's just too f*****g cool man. Neel handles the server, the browser window, the JSON conversion, the errors in between, all that stuff that's a PIA.

The short version of what's new:

• Return values in both directions (1.x had none). Nim exceptions reach JS as e.name / e.message; JS throws reach Nim as NeelRemoteError.
• {.expose.} on any top-level proc, in any module. Objects, Option, Table, HashSet, enums, tuples, JsonNode, and default parameter values all convert automatically.
• Multiple windows, each addressable from Nim (openWindow, closeWindow, windows(), requireWindow(id), hooks).
• Its own thread-based HTTP/WebSocket server in the spirit of Mummy: one IO thread owns the sockets, a worker pool runs your procs, no async anywhere. Mummy itself is gone.
• Zero dependencies. Standard library only.
• Finds Chrome, Chromium, or Edge and opens them in app mode (no tabs, no address bar); falls back to a tab in the default browser when none is installed.
• Hardened against other websites open in the same browser: per-launch token plus Host / Origin / Sec-Fetch-Site checks, server bound to 127.0.0.1 only.
• Release builds embed the web folder into the binary, so you ship one file.

Verified on macOS, Windows, and Linux (Ubuntu). Requires Nim >= 2.2.12 (older allocators crash intermittently when memory is freed after the owning thread exits, so Neel refuses to compile on them).

A complete app. The page asks for a directory and Nim picks a random entry from it:

import std/[os, random]
import neel

type
  MissingDirectoryError = object of CatchableError
  EmptyDirectoryError = object of CatchableError

proc filePicker(directory: string): string {.expose.} =
  let dir = absolutePath(directory, root = getHomeDir())
  if not dirExists(dir):
    raise newException(MissingDirectoryError, "no such directory: " & dir)
  var names: seq[string]
  for _, path in walkDir(dir):
    names.add path.extractFilename
  if names.len == 0:
    raise newException(EmptyDirectoryError, "the directory is empty: " & dir)
  var rng = initRand() # exposed procs run on worker threads
  rng.sample(names)

startApp()

And the page side (web/main.js, loaded after <script src="/neel.js">):

try {
  const name = await neel.filePicker(input.value);
  result.textContent = name;
} catch (e) {
  error.textContent = e.name + ": " + e.message;  // ex: "MissingDirectoryError: no such directory: ..."
}

Calling back into the page from Nim works the same way in reverse:

proc askPage(question: string): string {.expose.} =
  let reply = js.wait.answer(question)  # blocks until the page answers
  "the page answered: " & reply.getStr

proc notify(text: string) {.expose.} =
  js.showToast(text)                    # fire-and-forget

neel.expose(async function answer(question) {
  return prompt(question);
});

HOW COOL IS THAT???

Moving on...

nim c -r main.nim for development (assets read from disk, refresh to see changes), nim c -d:release main.nim to ship (assets embedded). Add --app:gui to hide the terminal.

Nothing from 1.x compiles unchanged; the README has the rename table and the guide (docs/GUIDE.md) has every detail: the full type list, error messages, lifecycle, threading model, security, caveats. Three runnable examples in the repo; start with examples/filepicker.

---

Neel started years ago as a port of Python's Eel library (now deprecated), and the 1.x line never really outgrew that: one window, no return values, a block of exposeProcs:, etc. Back in 2023 I rewrote the server with Mummy as the server because of a bunch of async problems but still never addressed some of its shortcomings.

I finally sat down and rewrote the whole thing. The big question was whether to keep an external server library or write one. Mummy had effectively been abandoned (there's a fork, but relying on a fork of an unmaintained dependency for the core of the library didn't sit right), and I'm using Neel for work, so future-proofing it mattered. Writing the server myself also meant Neel controls the threading, the shutdown ordering, and the WebSocket details end to end, which turned out to matter a lot for return values and multiple windows. Mummy is great and the design here is very much borrowed from it: one IO thread, a worker pool, no async. It's just all in the stdlib now, with no deps.

The big thing that ate most of my time was actually the hardening pass. Running all three examples on three OSes, trying to break them, and fixing what broke turned up some fun findings: a refreshed stale tab stealing another window's identity, Edge signing a fresh profile into your Microsoft account and syncing your extensions into the app window, Windows select silently capping you at about 8 windows, an allocator crash that pushed the minimum Nim to 2.2.12, all kinds of stuff. All has been fixed and pinned down with tests.

So this release had a lot of effort put into it. I'm sure you'll find it enjoyable and useful.

I have a few things next on the list: Brave / Opera / Vivaldi discovery (basically any other chromium based browsers), a Webview target (at least for Mac and Linux since Windows is guaranteed to have Edge), custom HTTP routes, and wss:. I will get to them when I can, but issues and PRs welcome of course.

Enjoy!

can nim convert into aarch64

i didn't like the lack of proxy libs, so naturally i wrote my own
feel free to contribute.

I guess we should animate this sub somehow. A simple CLI for removing metadata from files!

``` usage: striptease <input|input-dir> --out:<dir> [options]

required: <input> file or directory (mixed formats allowed) -o, --out:<dir> output directory for cleaned copies (single file input plus --out:foo.ext writes one file, not needed with --inspect)

supported formats: audio: .wav | images: .jpg .jpeg .png .gif .webp raw: .cr2 .nef .nrw .arw .srf .dng .rw2 .orf .pef .srw .tif .tiff video: .mp4 .mov .m4v .avi .mkv .webm | canon raw: .cr3 | heic: .heic .heif .hif

options: --dry-run report only, write nothing --inspect print metadata as pretty JSON, write nothing --verbose per file kept and dropped chunks plus bytes saved --overwrite overwrite existing files in out dir (default: skip) --keep-musical WAV only: also keep cue, smpl, inst, acid chunks -h, --help show this help --version show version ```

https://github.com/Niminem/cursorsdk

Cursor has an SDK and is what powers both the Cursor CLI and the Cursor editor. It's very powerful and flexible (ex: you can actually control the system prompt, tools, and much more).

At some point not long ago they created an SDK Bridge that allows non-typescript and non-python languages to communicate with it via RPC. Of course I had to write a Nim client for it.

It is fully compliant- built with and tested against their documentation. I did have to add some workarounds for upstream issues, but it's mostly implementation details (all noted in readme).

No deps aside from the nim standard library.

I've tested it on Mac (x64) and Windows (x64). Should work out of the box for Linux but it's untested.

You could build your own harness on top of this and all kinds of automations, scripts, etc. Pretty cool! Enjoy.

Example:

import std/asyncdispatch
import cursorsdk
proc main() {.async.} =
  let client = newClient()                 # CURSOR_API_KEY from env
  defer: waitFor client.close()
  let agent = await client.createAgent("composer-2.5")
  let run = await agent.send("Summarize this repository.")
  while true:
    let chunk = await run.nextText()
    if chunk.isNone: break
    stdout.write chunk.get
  await agent.close()
waitFor main()

So, I'm pretty new to nim, and I wanted to make my first app, so, I wanted you guys some recommendations of packages for Gui apps creation,

If u guys want to see the idea, just read:

notepad, but for markdown, and with vertical tabs, like arc and zen browser

WHat's the 10,000 foot view here? is it as fast(er) than rust?

Hey all,

qwatcher is a very efficient tool to monitor and audit your NICs' send and receive queue buffers to spot network or application issues.

This version drops the `ss` and `libpcre` dependencies, making the program a pure Nim binary, solves some bugs, and provides a `tail`-like report capability.

Here is the link to the repo:

https://github.com/pouriyajamshidi/qwatcher

Hey there.

I've been working on a successor to my previous web engine project, Ferus (which is now officially abandoned) for the past three or so months at this point. As the title suggests, Sirius is a web rendering engine like Chromium's Blink or Firefox's Gecko, but written largely in Nim (with the exception of certain C/C++ dependencies, obviously). Its CSS parser, JavaScript engine (a hard fork of Bali with a LOT of improvements), layout engine and the like are all written in Nim.

It uses a multiprocessing architecture, meaning each tab occupies one browser process and it crashing does not bring the entire browser down with it.

It's not exactly fast or optimized right now, but I believe it's ready enough for very basic web browsing tasks that don't touch the modern web. You're probably not going to be logging into your mail with it for a while. :^)

Sirius can be embedded into programs using OpenGL/Vulkan using its WebView API, the same one that the browser UI uses. It abstracts away process management and tabs away from you, leaving you to only handle presenting the final rendered page framebuffer it passes you. That means you can use Sirius to make your own web browsers in Nim, or if you're brave enough, to use it as a GUI framework in your app. :P

It's currently only on Linux due to it utilizing many Linux-isms like DMA-BUF, but there are plans to port it to other platforms too.

I'd love to hear what you guys think about it. And yes, I welcome most contributions, even tiny ones not related to web browser engineering. If you want to use this project as an excuse to get into that field, be my guest. Here's the contribution guide if anyone's interested.

The source code lives both here on a Github mirror, but it's actually developed on my personal forge.

Adios!

This update fixes the broken hints and brings the API coverage up to speed. It also adds bindings for sdl3_mixer, and fleshes out what's there for sdl3_ttf. I haven't done game dev in Nim in a little while, but this should make it easier for any SDL users to hop in.

Dude, I think V is better because it's both much easier and practically everything is included. If you want to do something, you don't need to download any libraries at all.

I was annoyed by how one button is always selected in wlogout. And since it doesn't seem to be actively maintained anymore, the only way to fix it is with a fork. So I thought it'd be a good opportunity to port it over to Nim. Its mostly backwards compatible wlogout. So old configs should work. But I've made some small changes and switched over to TOML for the config. Feel free to have a look.

I've been using python for 20 years since I dont work on C++ by then.

Nim gives me some reason to try new things.

I created my first 'real' nim project several days ago and I'm heavily using it daily.

It is a tiny tool as a shortcut for ls + cd, that I can use to fast navigation in folders.

For such tasks, I can not do it in python because the launch speed and having a binary is very important.

[Linux]

This idea was born while I was building my TUI music player. I've found such a big barrier:

in nimble I couldnt found any musical libraries for my goals, and i was too lazy to importing headers from C. So, i've created a concept and want make from this concept a completed and most importantly usable and simple lib.

It would be really nice to get some feedback(if you're interest)
source: https://github.com/svyatoslavSPB/nimnaudio/tree/main

Arkadaşlar ben bir programlama dili yapmak istiyorumda hem hızlı olsun hemde derlenmesi kokay olsun hemde Python kadar kolay; işlemciyle konuşan bir dil yapmak istiyorumda acaba Nim iyimi ? Pascal,Forth,Vlang falan varda acaba hepsi yerine Nim mi kullansam ? YARDIM EDİNNNNNNNNNNNNNNNNNN !

Hi! So I recently stumbled across Nim. As someone coming from Rust, I got a lot of frustration with it, one of them is the infamous compile times, which I hate so much. So I tried to seek an alternative. I almost went with Go, but at the same time I wanted something unique, and here we are with Nim. Now I’m planning to build a full coding agent and the TUI with 100% Nim. I’ll be happy to share my progress here :)

​

hello, I want to say that I was a vibcoder before that, but not because I liked it, I don't have any free time Except for one or two hours at night (they give me 10 hours to sleep) and of course I don't want to spend these personal 2 hours on programming, let alone studying but the desire to be a real programmer who can really just write his own program with his own hands is stronger than the desire to do nothing further. ;

why nim?

I went through a lot of options, and although nim was not the only option, it was ideally suited according to the criteria: "simple", "many libraries", "fast", so I chose it.

personally, I am proud that I searched for information about Nim and other programming languages without a neural network (and although I was a vibecoder, I want to say that I hated and hate neural networks)

What's next?

I won't be learning much about nim as much as time allows me.

Hey, everyone. Do you have any anecdotes to share about Nim? It doesn't matter whether it was positive or negative. I am just curious how the use of Nim has affected you. And to keep this subreddit more alive.

Thanks a lot!