Live data from Hacker News

GitHub – nushell/nushell: A new type of shell

github.com

331–340 of 411 posts

Re: GitHub – nushell/nushell: A new type of shell

#331
post #288

Earlier quoted context omitted.

I agree... and any well written script will have a shebang that specifies the shell that shluld run it, anyway. For me, personally, I love having homogeneus systems put in place. In this case it means not having to switch my mind between in and for modes. Helps me avoid mistakes, having to keep less context up here. But it's always interesting to read about other people's way of working.

If you want to make the systems homogeneous, then you need homogeneous teams, too. Maybe some team members prefer fish, others prefer zsh, still others prefer bash. Your suggestion means that everyone has to use the same shell for their command line. I find that it is better to allow each team member to have their own working environment: different (command line) shell, different editors/IDEs, different keyboard shor…

no no no, I meant that I prefer using Bash everywhere, including my own machine, because anyway I'll need to end up translating most stuff I write to a Bash or even POSIX compatible script so... as someone said in other comment, why not cut the intermediary step. It makes it easier for me, the less context switches the better production code I'll produce.

But of course, I believe others should be free to make their own choices! As long as their choices don't end up affecting the quality of the code that ends up shared with the rest of the team...

Which brings an interesting point: I don't have a problem at all with you using whatever shell you want. But I do have a problem if because you don't use Bash in your day to day, you are less used to its ins and outs, you don't put in the extra work that is being as proficient with Bash than you are with your personal shell, and your scripts end up with bugs in how Bash arrays are treated (just a quickly made up example)

Re: GitHub – nushell/nushell: A new type of shell

#332
post #4

Kudos for writing something in rust and not appending "written in rust!" everywhere.

It's the new "I use Arch btw". Genuinely kind of tired of it already.

Meh, not really. Something being written in Rust is a feature to me.

Re: GitHub – nushell/nushell: A new type of shell

#333

Earlier quoted context omitted.

In my case, I use it because it is dead simple to get a standalone, lean, fast, native executable (on top of the other functional programming features). Cargo is a huge part of what I love about rust.

I have a great example. We have 100s of Markdown files. I needed a link checker with some additional validations. Existing tools took 10-20 minutes to run. I cooked up a Rust validator that uses the awesome pulldown-cmark, reqwest and rayon crates. Rayon let me do the CPU bits concurrently, and reqwest with streams made it dead simple to do the 1000s of HTTP requests with a decent level of concurrency. Indicatif gave…

Are the checks somewhat time-stable? Couldn't some of the checking (and network requests) be avoided by caching? For example by assuming that anything OK'd withing the last hour is still OK.

Re: GitHub – nushell/nushell: A new type of shell

#334

Earlier quoted context omitted.

I have a great example. We have 100s of Markdown files. I needed a link checker with some additional validations. Existing tools took 10-20 minutes to run. I cooked up a Rust validator that uses the awesome pulldown-cmark, reqwest and rayon crates. Rayon let me do the CPU bits concurrently, and reqwest with streams made it dead simple to do the 1000s of HTTP requests with a decent level of concurrency. Indicatif gave…

Reading your comment made me realize another thing: Using rust often feels like the language is a successful attempt to take the best parts of a lot of other languages and put them together into a single, rational collection of features. Most of what's in there isn't new, but it all fits together well in one place so I don't feel like I have to make a devil's bargain for important features when I start out.

Most good languages seem to boil down to this.

Re: GitHub – nushell/nushell: A new type of shell

#335
post #107

Thinking this is so cool! I was wondering if seriously buying into an alternate shell like this would be worth it in the long run. Would really love to read from people who use(d) an alternative shell, both success and failure stories. I cannot shake from my head the idea that buying into a non-standard shell will only work for personal projects in one's own workstation, but it won't fly too far for company work beca…

I tried fish for a while. The differing syntax between fish and bash for fundamental things mean I was running all my scripts through bash anyway, and if I wanted to share them/use them elsewhere in the company it had to be bash, so I swapped back to bash.

I tried fish for a short while too and quickly realized everything depends on bash/dash. I then switched to zsh which is mostly compatible. I installed Oh My Zsh and a fish-inspired theme with line autocompletion and coloring and never looked back. But I still use zsh for the interactive prompt only, still writiiing #!/bin/sh scripts for maximum compatibility between platforms.

Re: GitHub – nushell/nushell: A new type of shell

#336

Earlier quoted context omitted.

PowerShell was started by a single person, Microsoft's Jeffrey Snover. As the project progressed other designers came on board but Snover remained (and remains) as Chief Architect. The design-by-committee allegation isn't being fair to him. Part of why PowerShell may seem not quite Unix-like, is Snover didn't just look at Unix as an influence. Snover's professional background included experience with IBM OS/400's CL…

BTW Jeffrey Snover said every PowerShell feature was supported by a business case. A principled approach, I thought, if mercenary. But what's the "business case" for iteration, conditionals, addition - apart from "everyone needs these"? Though these probably weren't the features he was thinking of.

I don't think I understand the question.

You think iteration, conditionals, addition are not needed in shell scripts? It would be a very unusual position indeed.

Or could it be that you are not familiar with the expression "business case"? (Sorry if this is off base! but the word "mercenary"in your post also kind of points this way).

"Business case" has very little to do with business as commercial enterprise...

Re: GitHub – nushell/nushell: A new type of shell

#337
post #107

Thinking this is so cool! I was wondering if seriously buying into an alternate shell like this would be worth it in the long run. Would really love to read from people who use(d) an alternative shell, both success and failure stories. I cannot shake from my head the idea that buying into a non-standard shell will only work for personal projects in one's own workstation, but it won't fly too far for company work beca…

> Which is something we came to accept and assume for interpreted languages (Python, Ruby, Node, etc.) Tangential, but: - "Node" isn't a language, it's a JS runtime - There's no such thing as an "interpreted language", whether something is interpreted or not is a property of the execution environment, not of the language itself - The commonly-used runtimes for JS at least are JIT compilers, not "interpreters", and th…

I didn't downvote your comment. But I guess some people did, possibly because you did the thing about stating several facts where all were true but none were relevant. I'd swear I read that this phenomenon even has a proper name but cannot recall it right now.

(And for the record I know very well about the internals and technicalities about the words and names that I used: Node.js is the de-facto Javascript runtime for the backend, popular to the point that people commonly refer to it as "programming in Node"; Python and Ruby are just languages but their majority of users run their program with the default official interpreter, so through a metonymy we can refer to either even when actually talking of the other; and etc. For economy of the language and avoiding the pedantry, I grounded my comment on the most generally perceived notion about those technologies. You see, just to avoid unnecessarily long explanations like this one)

Re: GitHub – nushell/nushell: A new type of shell

#338

What if we added json output mode to all shell commands? Or at least make some wrappers that parse their unstructured text output into json. We would be able to use standard pipelines and jq to filter/query outputs, without any custom shells. Just imagine: ifconfig --json | jq '.[] | [.interface, .inet] | @tsv'

There is some movement in this direction: e.g. it's possible to do `ip -j addr` today.

Re: GitHub – nushell/nushell: A new type of shell

#339

Earlier quoted context omitted.

FWIW, nushell is much more of this than it appears. While many commands share names with Unix commands, that is the only similarity for quite a few, since they are rewritten to return structured data instead of text.

From what I recall about nushell, it only scores 2/5 of my criteria.

Right, it’s still very early and something needing to be contributed to. However I have spoken to the creator (regretfully I haven’t had as much time to contribute as I would’ve liked); he is very open to improvements and the direction of the project is pretty open.

Re: GitHub – nushell/nushell: A new type of shell

#340

The title is somewhat misleading and makes it seem like this is a GitHub company initiative rather than a project just hosted on GitHub. I've not seen this title format on HN before. Could it be changed?

Same, I thought it was a GitHub project. There are often links to GitHub pages on HN and I don't think they generally have the "GitHub" prefix. It's not relevant anyway where the code is hosted.
Post reply on HN