Live data from Hacker News

GitHub – nushell/nushell: A new type of shell

github.com

151–160 of 411 posts

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

#151
post #89
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…

Ruby requires an interpreter at runtime. JavaScript too. Rust produces standalone binaries. So no, "things don't break" and you only compile things once. // I can't care less about deb or rpm files so don't try to force that down my throat.

There's no win/win scenario when comparing libraries to static binaries. On the one hand, static binaries are more user friendly. But they remove the responsibility for keeping your OS secure away from the OS/distro maintainers.

For example, if a vulnerability is found in a create, you then have to hope that every maintainer who manages a Rust project that imports said create diligently pushes out newer binaries quickly. You then have multiple applications that need to be updated rather than one library.

This may well be a future problem we'll end up reading more about as Rust, Go and others become more embedded in our base Linux / macOS / etc install.

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

#152
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…

use it as an interactive shell first, not for shell scripts.

also, why would any dependency of your projects at work be implicit? all dependencies should be captured somehow, the very least in some documentation.

at our company, we use shell.nix files to declare all of our dependencies, so everyone has the exact same software available on their development workstations.

it's not a completely trivial thing to do, but worth investing into it, to lower the chance of surprises, which will happen when you can afford them the least...

here is an example to get started:

``` with import (builtins.fetchTarball { name = "nixos-unstable-on-2021-05-16"; url = "https://releases.nixos.org/nixos/unstable/nixos-21.05pre2893... sha256 = "1kilrk0ipvldf4rrn6aq6v2bj2jfhbz33cjb9w9ngqmbmr2f94wd"; }) { };

let project-jdk = jdk11; clojure = callPackage ./deps/clojure { jdk11 = project-jdk; };

in mkShell rec { buildInputs = [ coreutils cacert direnv nixfmt curl jwt-cli fd python3 nodejs (yarn.override { nodejs = nodejs; }) project-jdk clojure yaml2json

    modd
    devd
    overmind
  ];

  shellHook = ''
    export LC_CTYPE="UTF-8" # so tar and rlwrap won't complain
  '';
} ```

it shows how u would use your custom package (for clojure in our case) and how would u pin there state of the whole package repository to a specific point in time.

in the past I've used es, the extensible shell (https://wryun.github.io/es-shell/), this way, without bothering my colleagues with teaching them about it. they just git pull, press enter in a shell within the hour repo and direnv will pull down any new dependencies.

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

#153
post #4

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

Why is everything written in rust nowadays? Apart from the safety it provides.

Might just be the Baader-Meinhof effect:

https://en.wikipedia.org/wiki/Frequency_illusion

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

#154

Very promising project that I hope it will take off and succeed. I recently switched to zsh with the addition of oh-my-zsh and I am happy how it has features like auto completion and command validation of some sort, but this could take it to the next level. I am just afraid to change to it and be disappointed about some incompatibility issues or bugs / crashes. I will observe and wait until it's quite popular to hop…

I use Oh-my-zsh too but I hate that it constantly asks me to update itself and it isn't exactly the quickest update either. Either update automatically in the background or don't tell me about updates at all. Don't constantly nag me when I start new shells!

I used to use oh-my-zsh and never really understood it. Turns out what I mostly wanted was `zsh-autosuggestions` and `zsh-syntax-highlighting` plugins, plus some sane history settings [0]. I've been oh-my-zsh-free for three months, my computers are now less cluttered and more straightforward.

[0]: https://github.com/tasuki/dotrc/commit/e3769134e758d02a947ef...

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

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

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.

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

#156
post #149

Earlier quoted context omitted.

> Apart from the safety it provides. Sum types (and pattern matching), first-class results, ownership, good performances and a rich ecosystem turn out to be quite nice for a general purpose langage once you’ve passed the hurdle of the borrow checker, even ignoring all the zero-cost abstraction stuff. Also the really solid and safe multithreading. You might struggle a bit getting all your ducks in a row, but past that…

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.

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

#157

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?

I got excited thinking it was an official Github project.

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

#158
post #149

Earlier quoted context omitted.

> Apart from the safety it provides. Sum types (and pattern matching), first-class results, ownership, good performances and a rich ecosystem turn out to be quite nice for a general purpose langage once you’ve passed the hurdle of the borrow checker, even ignoring all the zero-cost abstraction stuff. Also the really solid and safe multithreading. You might struggle a bit getting all your ducks in a row, but past that…

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.

That thing is runtime performance.

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

#159
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 don't know if fish counts as an alternative shell since it is still pretty close to bash and zsh, just with better defaults requiring less configuration (similar to i3wm with respect to "better defaults").

I just use it as interactive shell and for scripts I use `/bin/sh`. So I don't really run into a lot of problems, only sometimes with scripts that do not have a proper `#!/path/to/shell` declaration at the top.

("better defaults" is of course entirely subjective but for fish, i3 and Doom Emacs they mostly align with my preferences)

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

#160

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?

I think the "nushell/nushell" part makes it clear which repo it is talking about.

no.. I didn't find it clear..
Post reply on HN