Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub – nushell/nushell: A new type of shell

github.com

Post reply on HN
Print view View original

171–180 of 411 posts

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

#171

Post by junon »

pdpi wrote: post #86
junon wrote: post #42

Earlier quoted context omitted.

None of that sounds appealing on its own. Ready for the downvote wave. :D

This is a thread about a shell. That’s very much the sort of project that is typically written in C, and also the sort of project that really benefits from being written in something safer. It’s fine if writing systems languages doesn’t appeal to you, but they fulfil an important niche in. V8, Hotspot, Cpython all have to be written in something .

You assumed a lot about me from one sentence. This is why people dislike the rust evangelism.

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

#172

Post by [deleted] »

j1elo wrote: 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…

[deleted]

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

#173

Post by detaro »

hnlmorg wrote: post #138
pdpi wrote: post #92

Earlier quoted context omitted.

Maybe we could be writing things in ADA. I don’t know, it’s a language that’s been on my radar for several years but I haven’t actually dug into it yet. That said, we need something to replace C — and Rust seems to be picking up momentum. Rust seems good enough a replacement to me, and that’s enough for me to cheer it on. I do agree that “written in rust” isn’t as big a guarantee of quality as people here assume thou…

We've already had languages that could replace C. Ironically Pascal was replaced by C on home systems. But Rust isn't a C replacement, it's a C++ replacement. HN talks about Rust like there was a void before it but there wasn't. I think it's great that the community have finally gotten behind a safer language and I think Rust is a worthy candidate for the community to get behind. But I'm sick of reading about Rust as…

> it's the only shell what has a page of comments commending the authors for their choice of language.

There isn't "a page of comments commending the authors" here, so I have no clue what you are talking about? The main Rust discussion is in a subthread which someone specifically started by asking "why Rust", at which point you can't really fault the Rust fans for explaining why Rust.

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

#174

Post by okamiueru »

toxik wrote: post #170
okamiueru wrote: post #155

Earlier quoted context omitted.

If you're running scripts, what difference does it make that you use fish? You're not really supposed to write scripts for fish, unless it is meant to be used be the fish shell itself. A shebang on the top of your script will invoke the script with the right executable, and whether you called it from bash, zsh or fish would make no difference.

So, instead of just typing shell commands, you type something else, but as soon as you need a shell script, you have to go back to shell commands.... Why not just cut out the middleman?

Answer to the first question: yes. Answer to the second question: because bash is a rather poor terminal shell.

In my experience, the middleman you mention doesn't exist. Or, if anything, it is a very tiny man that hardly gets in the way. It's either a one-liner with a syntax change you can pick up in 5 minutes, or it falls under any combination of these:

- might as well belong in a script

- the complicated stuff is in awk or the likes

- you can just enter bash for any copy-pasted bashisms

- you can execute it explicitly with bash -c

In any case, none enough of a hassle that it could demerit the immense productivity benefit I've gotten from fish. The only regret I have on that matter is not having ditched it sooner. Use bash to run scripts, or even better, sh. Use a different shell to make your life on the terminal better. Doesn't need to be fish, zsh is pretty good too.

If I can offer any advice: if you still want to stick with bash, at the very least take a look at fzf, https://github.com/junegunn/fzf , aside from fish/zsh it's the best and most lowest hanging fruit.

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

#175

Post by vbsteven »

chx wrote: post #65
vbsteven wrote: post #20

Earlier quoted context omitted.

I think Cargo doubling as both build tool and package manager is a big factor here. The combination of Cargo + crates.io makes it very easy to write some Rust code and make it available to anyone with Cargo on their system. Either by `cargo install nu` to build it from sources on crates.io or `cargo install` inside the git repo to build my own customized version. No more waiting for distro packagers to keep up. Putti…

This is insanity and hubris. "It's so easy!" yes if you have the language and tools de jour installed and up to date. I want none of that. It was node and npm. Then go. Now Rust and cargo. Oh, I forgot ruby. And all this needs to be up to date or things break. (And if you do update them then things you are actively using will break.) I don't need more tamagochis, in fact the less I have, the better. What happened to…

I'm the parent that you replied to. In my eyes there is nothing wrong with .deb and .rpm files. In fact, many of these tools are available for download in these formats and some others (docker, snap, etc). And it is good that they do but it comes with extra work to setup the pipelines/builds.

The concept of a language-specific package manager distributing not only libraries but also executables isn't new. Go get, ruby bundler, python pip, cargo and npm all have this feature.

I was originally answering a question about why we suddenly see all these "written in Rust" tools pop up. I think that is partly because Cargo provides this easier way to distribute native code to users on various platforms, without jumping through additional hoops like building a .deb, and setting up an apt repository.

Sometimes you just want to get some code out there into the world, and if the language ecosystem you are in provides easy publishing tools, why not use them for the first releases? And if later your tool evolves and becomes popular, the additional packaging for wider distribution can be added.

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

#176

Post by brushfoot »

wokwokwok wrote: post #90
kaba0 wrote: post #54

Earlier quoted context omitted.

I’m sorry to say this but this is a very uninformed comment with way too many biases without any backing. > I.e. it wasn't created from the need, like someone at Microsoft wanted to automate his work and created PS to solve his problem Interestingly enough, it is used for automating Windows configuration. Re last paragraph: UNIX commands are random letters that are like that due to historical reasons — if you don’t k…

> So while I am not particularly fond of Microsoft, powershell is better than bash (though frankly, what isn’t?) in every conceivable way. There are fair criticisms to be made of bash...but this isn’t a fair comment either; I use power shell a lot; I’ve written hundreds or thousands of lines of powershell glue for scripts and devops pipelines and all kinds of things. It’s not very good. It is one of those things that…

> It’s firmly a middle ground “no one wants to use it if they can avoid it” product.

No way, I love PowerShell. It was my first choice for the bulk of a B2B Windows integration product. Part of it's a C# desktop app; the rest is PowerShell scripts that customers can edit to taste.

I reach for it all the time in projects. The pipeline is so clean to work with. Once you get used to how it handles collections, the cmdlets are very intuitive, and PowerShell Gallery has a large selection available for download.

Objects instead of strings is big by itself, of course. Then you get the .NET standard library right in the shell to interact with them. Great for parsing dates, numbers; a powerful regex engine; stream manipulation; pathing functions; the ability to write and execute C# in the shell; etc.

The cmdlets for data manipulation have gotten very good, too. The CSV cmdlets used to be unintuitive because they exported type data, but that's now off by default. `Import-Csv` and `Export-Csv` work with objects that you can easily manipulate with the set operations cmdlets. It feels very much like LINQ.

Same with `Invoke-RestMethod` (`irm`) when interacting with APIs. It deserializes JSON into objects automatically. You can then easily filter or transform the result.

There's a learning curve for sure, but once you get past that, it's a very good shell. I feel like it's one of the best things to come out of Microsoft.

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

#177

Post by indemnity »

aethertap wrote: post #156
daptaq wrote: post #149

Earlier quoted context omitted.

There must be something else, because most of what Rust brings to the table is what functional languages have been providing for ages, just with rebranded names.

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 me awesome console progress bars.

And the best part, the CPU bound part runs in 90ms instead of minutes, and the HTTP requests finish in around 40 seconds, primarily limited by how fast the remote servers are over a VPN halfway around the world.

No attempt made to optimise, .clone() and .to_owned() all over the place. Not a single crash or threading bug. And it will likely work one year from now too.

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

#178

Post by rjzzleep »

pjc50 wrote: post #114
rjzzleep wrote: post #74

Earlier quoted context omitted.

Can you elaborate?

Not OP, but: MMC = Microsoft Management Console, the collection of "snap in" GUI config tools for all the advanced features beyond Control Panel. MMC can control remote computers, but I believe only one at a time? Unless it's something through Group Policy. Now, the APIs exist to do all this remotely (DCOM), but good luck discovering what they are! And the minimum level of program you'd need to call them would be a C…

Everything you say is accurate, but it doesn't really relate to his claim for the reasoning behind the decisions behind Powershell. That's what I was referring to when I asked for a more detailed elaboration.

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

#179

Post by vbsteven »

spullara wrote: post #56
vbsteven wrote: post #20

Earlier quoted context omitted.

I think Cargo doubling as both build tool and package manager is a big factor here. The combination of Cargo + crates.io makes it very easy to write some Rust code and make it available to anyone with Cargo on their system. Either by `cargo install nu` to build it from sources on crates.io or `cargo install` inside the git repo to build my own customized version. No more waiting for distro packagers to keep up. Putti…

How are you measuring popularity?

Popularity in this context is my personal experience seeing these tools pop up over and over again in the media that I consume.

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

#180

Post by indemnity »

vkoskiv wrote: post #87
stevenhuang wrote: post #76

Earlier quoted context omitted.

Why don't you download the native binaries then? Rust isn't an interpreted language, you only need the rust toolchain if you want to build from source.

Binary releases seem uncommon from my perspective. Every time I go to install a piece of software written in Rust from homebrew, it invariably starts installing some massive Rust toolchain as a dependency, at which point I give up and move on. Maybe it's a case of the packagers taking a lazy route or something, or maybe there is a reason for depending on cargo. I have no idea.

Do you have some specific examples?

E.g. ripgrep is packaged on most operating systems I have used, along with exa, and a few other Rust utils I use.

I certainly do not use Cargo to install them.

Post reply on HN