RFC: cargo wrapper

[dherman]

This RFC proposes we evolve neon to be a complete wrapper for cargo instead of its own custom abstraction. This also involves a change to the directory structure of Neon projects.

Rendered

[MilanLoveless]

This PR brings up an existential question that cuts to the heart of "what is Neon?" Should it be low level glue between the run time environments or should it be a high level abstraction that bridges them? It could even be two libraries: the latter built on top of the former.

[dherman]

@MilanLoveless Can you say a little more about how that question plays out for this RFC? In what ways would you see different answers impacting the design of the tooling and/or project layout?

[nixpulvis]

@MilanLoveless I'm honestly kinda confused the distinction you are making between the two. Maybe an example of each might help?

[MilanLoveless]

As far as wrapping Cargo goes, do we really want to abstract that for a developer who may or may not be new to writing Rust? I am a little concerned about this level of opaqueness, especially with basic functions like cargo install Apologies if my last comment was a little dramatic 😅

[dherman]

@MilanLoveless I wonder if your concern is related to my worry about the name neon for the executable. I took inspiration from the xargo project, which is similarly a project that wraps cargo because it doesn't have all the extensibility hooks it needs. But since the name sounds like cargo, it makes it easier to intuitively understand that it's just a slightly modified version of cargo, rather than a whole new tool.

On top of that, the name neon leaves some ambiguity about whether you're operating at the Rust or the JS level.

So as much as I hate to let go of the beautiful name neon, I'm wondering if a name like nargo ("Node Cargo" or "Neon Cargo") or jargo ("JS Cargo") might make this more intuitive.

[MilanLoveless]

Yeah, that's definitely part of it. Also there is some danger if the development environments (vanilla Rust and Neon) diverge too much.

[dherman]

@MilanLoveless Agreed about the divergence concern, which is why I intend this only to be a stopgap until we can actually get the customization hooks we need from cargo. We'd basically be signing up to keep in sync with the cargo behavior. I don't think it changes super frequently, and not only that, a mitigation is the fact that most flags just get passed through untouched. So simple changes as cargo evolves should not require any maintenance work for "nargo."

[dherman]

(Cargon?)

[nixpulvis]

• jargo, feels like Java’s JARs, maybe that’s fine.
• esargo, unpronounceable.
• vargo, kinda like this one. JS is all about var even when it’s let.

All I got for you right now.

[dherman]

vargo is genius! And then you missed an awesome variation on esargo... escargo!

[MilanLoveless]

I like escargo - it's like ECMA Script Cargo 😂

[nixpulvis]

Ohhh escargo could be good! I love snails ❤️

[nixpulvis]

So between vargo and escargo we have an interesting problem. Vargo sounds more like cargo, but Escargo is more literally correct. Additionally escargo would be easier to “brand” since it’s a type of food. I think I personally like vargo better, but it’s going to make less sense to more people than escargo, because not as many people are going to associate JS with var over time. 💭

[dherman]

I'm not sure "correctness" per se is exactly an issue with branding, although we do want to create the right mental image for the customer.

I was leaning towards escargo until I tried typing both options at the command-line, and vargo felt better to me. I think the reason is that es is too generic. Neon isn't a general-purpose ECMAScript bridge, it's only for Node. Meanwhile, being a one-letter-change pun on cargo is pretty nice, and continues the tradition of xargo. And while both names are cute, vargo is just kind of amazing. :)

$ vargo build

[nixpulvis]

I completely agree, vargo fits into the Rust ecosystem better. And I’m always a fan of less typing.

[dherman]

D'oh, I need to close this PR and re-create it from a non-master branch. I hope I don't lose the conversation here. :(

[dherman]

Phew! Nothing was lost. 😅 I'll link to this thread from the new PR.

[nixpulvis]

Haha, I can't count the number of times I've done this.