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

201–210 of 411 posts

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

#201

Post by Macha »

daptaq wrote: post #149
masklinn wrote: post #130

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.

Existing functional languages had their own issues:

1. Haskell: had to deal with cabal hell

2. Scala: Java toolchain, VM startup time, dependencies requiring differing Scala versions.

3. F#: .NET was considered too Microsofty to be taken seriously for cross platform apps.

4. OCaml: "That's that weird thing used by science people, right?" - Even though Rust took a decent amount of ideas from it, it got validated by its early users like Mozilla and Cloudflare, so people felt safer trying it.

5. Lisp: I don't think I need to retell the arguments around Lisp. Also a lot of the things Rust touts as FP-inspired benefits around type systems really aren't built into lisp, since it's dynamically typed, these come more from the Haskell/Scala school.

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

#202

Post by Macha »

wraptile wrote: post #23
firefly284 wrote: post #11

Earlier quoted context omitted.

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

Seems like low level programmers finally getting an enjoyable, modern, free language and are getting a bit loose with it!

Also high level programmers getting something more performant and that doesn't require a runtime but still has a lot of ergonomics they're used to.

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

#203

Post by wccrawford »

rincebrain wrote: post #140
kstenerud wrote: post #126

Earlier quoted context omitted.

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.

FWIW, I don't think "it's marketing" is a valid excuse for them saying things that aren't true. It's not a "new kind of shell" because it's mimicking things that already exist. The author even knows about those things and cites them.

I do not accept the idea that it's okay to make false claims to create a narrative, marketing or otherwise.

And I'm not on the spectrum.

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

#204

Post by Macha »

rincebrain wrote: post #14

This feels extremely like PowerShell, from all the examples, and even cites "draws inspiration from projects like PowerShell", so "a new type of shell" feels very disingenuous unless it has additional novel properties that aren't evident just from these. There's also no support for variables yet if the page is to be believed, which means there's 0 chance of me using this for more than 5 minutes right now. (I'm not tr…

I think to most people who've only used as Powershell as "That windows shell with the blue background and built in unixy aliases", getting into Powershell itself still qualifies as a "new type of shell", so I'm willing to extend that credit to other shells trying the same paradigm.

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

#205

Post by hibbelig »

maccard wrote: post #190
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.

> You're not really supposed to write scripts for fish Given that 95% of my time in a shell is running a script, a shell that doesn't do that well isn't a great fit for me. > A shebang on the top of your script will invoke the script with the right executable, Assuming the person who wrote it had the foresight to do so. That person isn't always me, and if I have to manually check if each script I run has a shebang, I…

I haven’t seen a shell script in ages that was missing the shebang. Is this common in some places?

I’ve started to write dash scripts because that seems to be reasonably posix and bash on macOS is ancient.

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

#206

Post by Macha »

ar_lan wrote: post #71
Offpics wrote: post #45

Earlier quoted context omitted.

Try fish shell. It has auto completion by default and is easy to configure with web interface "fish_config", no need to rely on some community repo like oh-my-zsh. There can be bugs if you set it as default shell but i just append "fish" at the end of my .bashrc :)

It's so interesting - it seems that fish is getting more and more popular lately. I tried it ~7 years ago and thought it was severely lacking, so I just stuck with zsh and have never really had a reason to look back. Maybe I'll check out fish again at some point - what features does it have that drew you to it?

I moved from zsh + oh-my-zsh to fish a couple of years ago.

The main reasons were:

1. It had a lot of qol features I liked from zsh _by default_ without requiring a significant config

2. Prebuilt zsh configs like oh-my-zsh have been pretty commonly quite slow in my experience, which fish fixes.

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

#207

Post by larodi »

skissane wrote: post #70
anticodon wrote: post #38

Earlier quoted context omitted.

PowerShell from Microsoft is looking too alien on Unix. Just looking at the syntax I already feel uncomfortable. It's hard for me to criticize it because I haven't used it, but it looks like it was designed by a committee and overdesigned. 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. It looks like some boss decided: "They have shells,…

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…

Once you start using PWSH, the design decisions are so obvious and make so much sense, that it is obvious Jeffrey Snover did have vast experience with variety of shells and languages.

The idea to tie it with .NET and COM+ on windows is the best a shell has ever done, though someone noted in another thread that it is an old idea from XEROX mainframes (not sure what the name was).

if you want to imagine this in terms of unix/linux - it would be something like having all libraries' APIs at disposal directly from a shell that passes structured objects. or python's REPL being more shell-usable or JVM having a shell that provides access to all classes in a click of ENTER.

major downside of pwsh is that you can feel it being slower than expected due to the way objects are passed around, but I really expect this will be solved at some point with future releases as PWSH as language is still being developed so some concepts and internal architecture decisions perhaps change a lot.

noshell is taking this idea to a fair level, but really, there is a reason to do some dev/devops work in PWSH because it will heavily impact all future shell development even if eventually superseded by something better.

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

#208

Post by Macha »

brundolf wrote: post #8
purplecats wrote: post #2

This looks pretty awesome. Wonder if it could be used with a command rather than as a new shell. Tangent: How is this at the top of the front page with a dozen upvotes and no comments? Maybe these upvotes all occurred at once?

It's not uncommon for people to upvote without commenting if they don't have anything to actually add or the post is self-explanatory

Software releases commonly get this treatment, I remember the comment about why there was no discussion on the actual contents of the change on a decently upvoted post about a minor release of wine, for example.

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

#209

Post by masklinn »

daptaq wrote: post #149
masklinn wrote: post #130

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.

> most of what Rust brings to the table is what functional languages have been providing for ages

In relatively familiar package & paradigm, with great package management (Haskell is the best of the functional langages there and it’s a mess), and with predictable and excellent performances.

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

#210

Post by masklinn »

Macha wrote: post #201
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.

Existing functional languages had their own issues: 1. Haskell: had to deal with cabal hell 2. Scala: Java toolchain, VM startup time, dependencies requiring differing Scala versions. 3. F#: .NET was considered too Microsofty to be taken seriously for cross platform apps. 4. OCaml: "That's that weird thing used by science people, right?" - Even though Rust took a decent amount of ideas from it, it got validated by it…

> OCaml

Also as much multithreading as Python (aka only for io).

Post reply on HN