Dear Members of The Ring Programming Language Group,
Dear Mansour Ayouni,
Dear Mahmoud Fayed,
I hope this message finds you all in great spirits.
After reading the exciting announcement about the initial release of Ring++ and exploring the documentation of RingServ, I feel compelled to express my deepest gratitude and admiration for your outstanding work.
What truly impressed me is how you translated real-world production needs—from a bank in Niger and a restaurant management platform in France, to the massive 300,000+ lines of the Softanza library—into concrete, practical, and highly effective tools. Achieving a 75-fold performance improvement in loops simply by changing how data is passed is a remarkable milestone that speaks volumes about the ingenuity behind this project.
I am particularly inspired by the project's core philosophy: "Don't fight the VM." Instead of hacking the interpreter, you measured its behavior and leveraged its existing low-level capabilities. Delivering true static type checking, multi-platform native builds, and zero-dependency tooling—all without requiring a C compiler—is a game-changer. It makes Ring significantly more attractive for mission-critical and high-performance applications.
Special thanks go to Mahmoud Fayed for designing Ring with such flexibility and foresight, which made this project possible in the first place. And a huge round of applause to Mansour Ayouni for the brilliant vision, meticulous execution, and tireless effort behind Ring++ and RingServ.
This work clearly demonstrates that Ring is not just an educational or hobbyist language; it is a robust ecosystem ready for serious production environments. I eagerly look forward to your future updates (mobile support and deploying agents sound incredibly exciting!).
Thank you once again for your generosity, passion, and dedication to this community.
Wishing you all continued success.
Yours sincerely,
[Khaled ABID]
--
---
You received this message because you are subscribed to the Google Groups "The Ring Programming Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ring-lang+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ring-lang/9dfdd45a-ed54-4a70-84bf-c783dffd6785n%40googlegroups.com.
Dear Dr. Mahmoud Fayed, creator of the Ring language,
Dear Mr. Mansour Ayouni, developer of Ring++ and RingServ,
Dear Mr. Youssef Saeed, core developer and package maintainer,
And the esteemed Ring team,
Peace be upon you,
After reading the wonderful announcement about Ring++ and exploring the richness of the Ring ecosystem, I am writing to express my deepest gratitude and admiration for your exceptional work.
I am truly impressed by how real-world needs from actual production projects have been transformed into concrete, practical, and highly effective tools. Achieving a performance leap of up to 75-fold is a remarkable milestone that speaks volumes about the ingenuity behind this project.
While I thank Mr. Mansour Ayouni for his clear vision in both Ring++ and RingServ, I would like to specifically acknowledge Mr. Youssef Saeed for his pivotal role in enriching the language. His contributions—which include over 22 production-ready packages covering critical areas such as security, data analysis, desktop and mobile application development, along with Rust bindings for Ring, Docker images, and GitHub Actions to streamline project builds—all of this reflects the spirit of innovation and collaboration that defines the Ring community.
Special thanks go to Dr. Mahmoud Fayed for designing Ring with such flexibility and foresight, which made all of these projects possible, and to everyone who contributes to this growing ecosystem.
Ring++, RingServ, and the new libraries added by Youssef Saeed clearly demonstrate that Ring is not merely an educational or hobbyist language, but a robust platform fully capable of competing in real production environments. Your work opens new horizons for developers and showcases what can be achieved when passion meets purpose.
We eagerly look forward to your future updates and wish you continued success and prosperity.
With sincere appreciation and respect,
Khaled ABID
--
---
You received this message because you are subscribed to the Google Groups "The Ring Programming Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ring-lang+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ring-lang/6399d619-0b00-4462-9ae6-9a1370d1ca53n%40googlegroups.com.
$ ls
hello.ring ring.ringo
$ ring hello.ring
<runs ring.ringo, not hello.ring>
$ ring hello.ring -go
<runs ring.ringo again. No .ringo is generated for hello.ring>
Hello Youssef,
Thank you very much!
I made Ring++ to address three aspects that constrained me in my real-world Ring projects:
Type safety for a large library like Softanza — the aspect that you and Mahmoud found particularly useful.
Performance — the top concern when working with large datasets and computationally intensive algorithms in Ring.
Full portability of Ring programs through a true native build system— from any platform to any platform, without complexity, including desktop OSs (Windows, Linux, and macOS), WebAssembly, mobile devices, and Linux-based microcontrollers (Raspberry Pi, ESP32, etc.).
That’s why the solution provides both a Ring library (ringpp.ring) and a Zig-based CLI that builds a Ring program for the target platform without relying on any C compiler — no MSVC, GCC, or anything else. And for WebAssembly, without relying on Qt like we do currently in Ring, not even Emscripten, the LLM-based compiler!
Today, I just added Android support to Ring++ native build system. The photo shows a Ring VM running, with a Ring program running ontop of it, fully and natively on Android, without requiring Qt or the Qt Creator toolchain. With a simple:
$ ringpp deploy --target android
Your Ring program is turned into an APK in seconds.

All three aspects are strategically important to the project, and they work together to simplify and modernize the entire Ring development experience.
I hope Ring programmers will see that value, try the three facets of Ring++ in their own projects, and experience the same fun and power that I feel when using it in mine.
Best regards,
Mansour
To view this discussion visit https://groups.google.com/d/msgid/ring-lang/a9780945-0d74-4db1-a006-1345c2ec2836n%40googlegroups.com.



To view this discussion visit https://groups.google.com/d/msgid/ring-lang/0086eed0-c504-4799-8053-2ccf3a8c3d88n%40googlegroups.com.
Type safety .
Performance — computationally intensive algorithms in Ring.
Full portability of Ring programs through a true native build system.
To view this discussion visit https://groups.google.com/d/msgid/ring-lang/269a6212-ddbe-48a8-899e-0708d82ba828n%40googlegroups.com.
Sir,Ringpp install H:\Ring\tools\ringpm\packages\ringpp-0.9.how to use Ringpp.RegardskamleshOn Thu, Aug 27, 2026 at 2:24 PM Mansour Ayouni <kalid...@gmail.com> wrote:Hello Kamlesh,You should just add from mayouni like this:H:\Ring>ringpm install ringpp from mayouniI will correct the info on the website and the github page.Thank you.Best,MansourOn Thu, 27 Aug 2026 at 09:19, kamlesh patel <patel.h...@gmail.com> wrote:Sir,Thank you for the reply.I get an error when I install ring++.H:\Ring>ringpm install ringpp
Installing ringpp (master)
Error(10): Package doesn't existRegardsKamlesh
To view this discussion visit https://groups.google.com/d/msgid/ring-lang/CAFdCj1Dr2h2C1c8t%3DK8AZToM%3DbnzvqN4BbQW9Jgww9rsy_EHtA%40mail.gmail.com.
Hello Mahmoud,
Thank you very much for your thoughtful interaction.
Please be assured that I don't see this as an attack, but rather as a valuable opportunity to learn from your reflections and to have a serious discussion, as we always do, with mutual respect.
I am particularly concerned with clarifying two main points you raised:
Point 1:
Ring++ evokes the performance of C, the static analysis of C++, and the ability to natively build Ring programs with these capabilities.
These three criteria are the three goals of the project, directly addressing the three constraints I encountered during two years of using Ring in customer-facing projects.
The name is short and catchy, but more importantly, the "++" is meant in the same spirit as when we write i++ for a counter: does the counter change its type? No. It is still an i, simply with a greater value.
Point 2:
I'm sorry if the documentation gave a different impression. The website and documentation state the opposite, from the very first sentence through every page, document, and code example:
The GitHub README.md also clearly states that Ring++ creates nothing new, but instead builds on what Ring already provides:
That being said, I will take another careful look at the wording and see how I can make the intent even clearer.
All the best,
Mansour
To view this discussion visit https://groups.google.com/d/msgid/ring-lang/4732206b-834d-403c-bb42-3a6ed006d7ccn%40googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/ring-lang/c32fefea-e312-496b-aa65-208c33c7f23bn%40googlegroups.com.
Hello Mahmoud,
Your answer is amazing and completely off the target of what my message raised as a concern.
It's just an opinion and personal projection you made on each point you raised, but I will not comment on them one by one to keep us all focused on what is more important.
Your mistake is that you assumed it was a personal attack on Bert, although I prevented it in the intro. So, my question, frankly, to you: did you believe me or not? If you don't, and build all that narration on a false proposition, this is your fault, not mine.
I do really mean what I said about my respect for Bert, and don't feel like I'm being attacked at all about his remark concerning the documentation, nor about your unilateral decision to trim the Ring++ project scope to just one dimension out of three (the description of the package in the RingPM registry). They are all fine, and keep discussion open and healthy.
This being said, I know the direction I took to rethink some of the foundations of the Ring project itself (removing any dependency on any library other than the ones that are vendored inside the tools, or that rely on Softanza Engine one-stop-binary alone) could raise a strategic question about the alliance between what I do with Ring and the Ring project.
This is a fair question which I'm totally aware of, and that's why I carefully managed to adapt Ring itself, without fighting agains its VM or making any changes to it, to solve some of the concerns my customers raised about adopting it: performance, safety, and portability without complexity.
I did this and started using it successfully.
I thought this would be received with enthusiasm and strategic support from you, since this solves real-world limitations of Ring. You may recognize only one of them, as you did with static analysis Ring++, but this does not change the reality of the customers I have in front of me, whose decision to adopt Ring depends on all three of them.
Ignoring this reality is a strategic error I don't hope you will make, and I'm confident that you have all the intelligence and strength of technical personality needed to help you review your position, for the good of Ring, which we all love and support.
This being said, I'm happy we reached this point that makes my decision about the future direction I should take, ethically, easier for me. And I will let you know through a final and last message I will write in this group soon.
Thank you very much, Mahmoud. I love Ring and will continue to support it as I've done from the first day. Certainly in other contexts and using other forms, that keep our strong human ties and intellectual friendship.
And I owe the same feeling to Bert (to whom I express my sincere apologies if he ever felt attacked by my message) and to the other team members, one by one, and I hope we will stay in touch.
Sincerely, and please read it again... Sincerely,
Manssour
To view this discussion visit https://groups.google.com/d/msgid/ring-lang/e7c7be29-2f47-496a-a19c-ab28646abd9en%40googlegroups.com.
Ring, faster, safer and more portable — without ever leaving Ring
Short answer: no, ringpp won't speed this particular program up, and you don't need to add or change anything for it to run under plain Ring.
Here's why, based on what's actually on the ringpp site:
What ringpp's "performant code" pillar actually does
Its speed claim (the 75× number) is specifically about avoiding Ring's string-copy behavior — Ring copies a whole string onto the stack every time you pass it into a function, while it passes lists/objects by reference for free. RppBuffer/RppView give you a way to hold a big block of bytes as an object instead of a string so it stops getting copied on every call. That's the entire mechanism.
Your Queens-N-Timing.ring program never passes a string anywhere in its hot path — x, n, k, i, j are all numbers, and x is a Ring list, which Ring already passes by reference. So there is no copying cost for ringpp to remove here. This is actually one of the cases the site itself flags: three of its own eight examples conclude "plain Ring is the right answer" for that shape of code, and yours is that shape.
The other two ringpp pillars don't apply either:
===============================
If you actually want it faster, the win is algorithmic, not tooling. Place(k,i) re-scans all previously placed queens (O(k)) on every single placement attempt, using fabs() (float abs) on integers, which is the classic N-Queens bottleneck. The standard fix is to track "column used" / "diagonal used" with boolean arrays so each check is O(1):
That's a genuine order-of-magnitude speedup at n=12+, independent of any library. One other thing worth noting for correctness, not speed: countQueen/countPlace are declared once outside the for n loop and never reset, so the printed counts accumulate across all board sizes rather than resetting per n — worth fixing if you want per-size stats.
====================