Cool. Let's start with rRustConduit, because I think there's a bad joke in there about rusted pipes (12 seconds of google did not find a special name for it).

Make sure to include an explicit license, and maybe a disclaimer/hint that it's not part of the "Phorge" organization.

Thanks @avivey !

Hah this has been something spinning in the back of my mind for a while. One thing that will be difficult to support in something like Rust (not sure about Go) is that the PHP arcanist allows for very easily extending by dropping in your own PHP files to the extensions folder.

The only things I've looked at that might be a way forward with Rust is using something like Rhai however it would require quite a bit of rework (and all existing extensions that people have would not work). PHP is nice in that you get a more familiar OOP means of extending -- just extend some PHP class and customize it how you want, and being able to review the code of what you're extending since you have all the code right there.

@speck the whole point of an alternative phab client implementation is remove friction that comes with arcanist. Namely:

• PHP - according to my personal observation the mere fact of having to install PHP is already a show stopper for many (and this is true in both enterprise and opensource cases). I am in the same boat. If I can avoid having php on my workstation - I will. Scripting/extensibility in PHP is not sexy by any stretch of imagination.

• Scripted language in general. Whether this is nodejs, php or python - there is an entire bucket of problems associated with dependency management, interpreter versions, etc which makes user's experience non-uniform and very miserable in these cases. This is why Go/Rust is chosen - it has to be a self-sufficient binary, that works everywhere if compiled.

• Minimal solution. I mean what is this? (snippet from arc help).

      anoid
      Pilot a probe from the vessel "Arcanoid".
...
      look
      look [options] -- thing
      You stand in the middle of a small clearing.

> arc look
 <!> Arcventure

You stand in the middle of a small clearing in the woods.

It is late in the evening. The air is cool and still, and filled with the
sound of crickets.

Several small trails and footpaths cross here, twisting away from you among
the trees.

Just ahead to the north, you can see remotes.
[14:29:23] ngor@zen /home/ngor/src/git.freebsd.org/src
> arc look remotes
 <!> Arcventure

You follow a wide, straight path to the north and arrive in a grove of fruit
trees after a few minutes of walking. The grass underfoot is thick and small
insects flit through the air.

At the far edge of the grove, you see remotes:

[2023-05-07 21:29:35] EXCEPTION: (RuntimeException) strlen(): Passing null to parameter #1 ($string) of type string is deprecated at [<arcanist>/src/error/PhutilErrorHandler.php:261]
arcanist(head=master, ref.master=d47289622650)
  #0 PhutilErrorHandler::handleError(integer, string, string, integer) called at [<arcanist>/src/utils/PhutilUTF8StringTruncator.php:90]
...

😕 Why do I needs this in my code review tool??

Extensibility can be achieved in other ways, if needed. Git model works fine - just drop a script in your PATH and prepend git- to it. Or look at taskwarrior. Forcing users into a specific language is always a bad thing (today this language is sexy, tomorrow it is not)

• it has to be less opinionated. If users want a custom commit template it should be as easy as dropping a file into the repo similar to .github/ISSUE_TEMPLATE/FORM-NAME.yml

I’m fully aware of the friction that comes up trying to get developers using arcanist, the difficulties with PHP, the complexity in not understanding what’s going on, etc. and also familiar with the benefits of a compiled binary solution.

What I’m saying is that the extensibility story arcanist has today is really quite valuable - for adding custom workflows, linters, test runners, etc. If we’re looking to maintain a replacement it must allow for some extensibility, likely in the way of an embedded scripting language which allows exposing the internals of arcanist which would be necessary for the things I mentioned, which couldn’t be implemented as a separate git-binary.

I see what you are saying. I quite like Lua and how neovim uses it to achieve this extensibility...

I was similarly looking at lua for the same reason as it's used by neovim 😆 . There are a few libraries for lua in rust but the one that seems recently active is mlua, which doesn't implement lua execution in rust but binds to lua binary/library. If we go the route of binding to another library/binary then our build/package would have to include the lua library file too (though it may be possible to embed it?). Something like Rhai (or there's also Rune and a few others), are implemented fully in Rust so there's less to worry about during the build/package process. I wasn't sold one way or the other but wanted to check out Lua along with some of the others to see how well they turn out.

One other thing we’ll need to address is the current code sharing between arcanist and phorge. I’m not sure the full scope of what Phorge relies on from arcanist but I think there’sa fair amount. We can probably get an idea by looking at the libphutil repo which was the shared library between the two which was eventually merged into arcanist