Live data from Hacker News

GitHub – nushell/nushell: A new type of shell

github.com

131–140 of 411 posts

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

#131
post #120
post #101

Earlier quoted context omitted.

Hold on, do you not see the insane contradiction of not wanting to rely on having cargo installed but requiring something is deployable and tested in a docker container? What?!

No, you misunderstood. I meant that if you're going to document a block of command-line instructions, you should first make sure those commands work as-is in a clean system. A very easy way to do this (for me anyways) is using a Docker container. I use this method to test all of my documented commands. But there are other ways, of course, like using a clean VM. Regardless, just test the commands without assuming the…

You're telling me that people who want to replace a command-line utility are the same people who can't install a toolchain (or just download a binary and put it in their path)?

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

#132

What is better about this tool than PowerShell? The README doesn't mention it at all, just that the tool is inspired by PowerShell.

Nothing. Lets be realistic.

Even if it goes mainstream it will be decade behind PowerShell in conceivable future.

While I appreciate the enthusiasm for developing shell, nothing usable here in years to come IMO when I can just use pwsh.

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

#133
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.

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

#134
post #65

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 agree that it's not ideal, but unfortunately bad decisions by Linux distributions and package maintainers have trained me as a user to avoid the package managers if I want up to date software with predictable and documented defaults.

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

#135
post #65

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…

> What happened to .deb and .rpm files?

The problem with those is they require global consistency. If one package needs libfoo-1.1 (or at least claims to), but something else needs libfoo-1.2+, we can't install both packages. It doesn't take long (e.g. 6 months to a year) before distro updates break one-off packages.

I think some people try hacking around this by installing multiple operating systems in a pile containers, but that sounds awful.

My preferred solution these days is Nix, which I think of as a glorified alternative/wrapper for Make: it doesn't care about language, "packages" can usually be defined using normal bash commands, and it doesn't require global consistency (different versions of things can exist side by side, seen only by packages which depend on them).

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

#138
post #92
post #68

Earlier quoted context omitted.

Rust isn't the only language that offers that. In fact most languages offer that. Even Pascal is safer than C. Or if we're really concerned about security then we should be advocating that out shells are written in Ada. But clearly there's more to it than that.... It's also worth remembering that the biggest causes of RCE in shells haven't been buffer overflows. It's been fundamental design problems from the outset (…

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 if it's a silver bullet. HN badly needs to get past this mindset that Rust is the only safe language (it is not), and that programs are automatically safer for being programmed in Rust (in some cases that might be true but in most cases it is not).

I remember learning to program back in the days when people would mock developers for using structured control flow blocks because "GOTOs are good enough". While the Rust movement is, thankfully, the inverse of that in that people are questioning whether older, arcane, paradigms need to be disrupted, there is still a weird following surrounding Rust that has the same emotive worship without actually looking at the problems being discussed. People seriously suggesting everything should be written in Rust or harping on about the language as if its a one of a kind. There's plenty of domains that better suit other, safe, languages and there are plenty of developers who personally prefer using other, also safe, languages. Rust isn't the right tool for everything.

And the fact that I've seen people advocate Rust ports of programs written in Haskell, OCaml and Go because "it's safer now it's rewritten in Rust" is a great demonstration for how absurd the cargo culting has become.

My point isn't that Rust is a bad language or that people shouldn't be using it. Just that people need to calm down a little when discussing Rust. Take this case for instance: most shells out there these days are written in safe languages. The last dozen or so shells I've seen posted on HN been programmed in Python, LISP, Go, C# and Scala. It's really only the old boys like Bash and Zsh that are C++ applications. So Nushell isn't all that unique in that regard. But because its the only one out of a dozen that was written in Rust, it's the only shell what has a page of comments commending the authors for their choice of language. That's a little absurd don't you think?

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

#139
post #93
post #65

Earlier quoted context omitted.

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…

100% agree. I find it very funny, but in a sarcastic and totally wrong way, when a project's README has an Install section that reads: Run "cargo install myProject" I know Rust, so Cargo is not alien to me. But come on, you know that your install instructions are a bit shitty. Please, choose a target distro, then test your instructions in a clean Docker container. THEN you can sit down knowing you wrote proper guidan…

[deleted]

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

#140

Earlier quoted context omitted.

Ah, I see. Thank you for explaining. The part that bothered me was not that they described something that shared some concepts with PowerShell as "a new kind", but that I did not see any illustration of entirely novel features in the examples that followed. As a sibling comment remarked, they feel I'm quite mistaken, and there are very positive distinctions illustrated in the examples, but I took a look at them again…

It's not a question of precision, but rather one of convention. In this case, the convention is that a marketing line glosses over huge swaths of reality in order to give a simple and compelling narrative (people like things to appear simple, even if they're not - and even if they KNOW they're not). So calling out imprecisions and inaccuracies in this context reflects poorly upon you because everyone is already aware…

I appreciate you attempting to explain.
Post reply on HN