Replies: 1 comment 1 reply
-
|
We need to be careful with moving commands. We already know we don't want to move performance-sensitive commands to the standard library. But we also need to keep in mind that everything we add to the standard library slows down nushell startup speed. Right now, on my mac it's about a 115ms slower. On Windows, I'm sure it's dramatically slower. I think we just need to be conscious of the impact that it's having until we can speed up the startup process/parser. It may also mean we learn to write tighter nushell script code that isn't as verbose but yields the same results? I'd also want to get done what we have queued up before moving to other things. I'd like to see it completed, and live with it for a while to see how we like it before moving on. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Go back to the roadmap.
i've been wanting to discuss this for while, so here we are 😋
one of the goal of the library is to relieve the main source base of
rustcommands by moving non-time-sensitive commands to thenu-stdcrate 👍in #8311, we already have some ideas
helpcommandsnow comes the question...
what could / should we move to the standard library? 😏
currently the following commands are in the process of being moved or have been:
👉 from the discord server:
enter,shells,nandpcommands" (see #standard-library)dirscommand to std lib #8368benchmarkto wraptimeitin a multi-run loop ( see #cool-scripts)benchmarkandtestcommands to the standard library #8696👉 from GitHub
helpsubcommands fromrusttonushelland keep the mainhelpin therustimplementation to still allowhelp -f ...everywhere.print_help.nufrom @jntrnrhelpcommands with$nu#8505helpand the implementations innu-std#8813Beta Was this translation helpful? Give feedback.
All reactions