Pharao- PHP-Like charm for Nim

There are some genuinely good things about PHP, the greatest of which, in my humble opinion, is the ability to just dump a script on a web server and run it on request. It's eminently practical and I missed it, but there is no way I will part from my fiercely appreciated Nim programming language any more.

But I really wanted to have this dump-a-script ability, so I wrote pharao- a small server program that will automatically compile your Nim scripts to a shared library under the hood, and run it. As a user it's just like using PHP, you can put 'echo "Hello World"' into hello.nim on your server and you get "Hello World" on request. And it's really not that hard to set up, try it!

So one issue is that I had to resort a bit of magic source code rewriting to get it to work, because every pharao program gets turned into a procedure. So while in PHP, scripts are global, in pharao, they are procedure bodies, but they still look global. I usually shy away from such magic but in pharao's case we're looking mostly at snippets throwaway code, so I looked the other way and went ahead with it.

The thing is, Nim has this little thing called source code filters. They are very underrated, the Nim dev team kind of sneers at them meanwhile because they're so simple. And yet they are so useful. To date the only way I know to get templating engine syntax compiled directly to machine code, loops and all. But the regular Nim source processing doesn't really work with them, so I in the previous versions I resorted to some very hacky macro magic to get it to work anyway. And it did!

Only after getting a bit more traffic I noticed some pharao crashes, and I was like- uh oh, here they are, growing pains. Help, what am I going to do!

So after a bit of fiddling I noticed that- whoops- no this isn't because of some thread safety problems in the Nim library, this is because every variable in a pharao program gets transformed into a global. So as you can imagine, this is not ideal for thread safety. If you don't get concurrent access on one variable, you're guaranteed to hit another.

Now what? Multiprocessing? Urgh. No way.

Turns out there was an easy fix because it's 2026. Nim's source code filters are really very simple, or at least comparitively simple, but buried in very Nim compiler like code. So when I asked an AI program to see if they can extract them, they just re-wrote the whole bunch, unit tests and all. Couple hundred lines and works like a charm! Back when I wrote pharao there was no coding AI and doing this would have been a major undertaking, but this went just like that.

So as a neat side effect, Nim source code filters are available to place with as well. Hell maybe we can use them in other languages!!! They have been freed! They are going to go all over the place! :-)

So the moral of the story is- why on earth didn't I notice that earlier? I suppose the answer is in the old adage, never assume- I assumed that I would eventually do something concurrent in my everyday use, and I did, it just took longer than expected. So now there's concurrency testing and I suppose just more old fashioned thorougheness.

So now we have pharao 0.2.0, that reinstates the original (better, more flexible) architecture, and supports source code filters using the new standalone library. These would normally have to be kept in sync with the compiler, but since they aren't being considered part of active development anyway, that should be quite doable. Unless they become the next big thing in languages- wouldn't that be fun :-)