Live data from Hacker News

The Bun Shell

bun.sh

171–180 of 239 posts

Re: The Bun Shell

#171

"JavaScript is the world's most popular scripting language." Perhaps, based on usage. But shell must be the world's most ubiquitous scripting language. Not every computer has a Javascript engine but most have a shell. Many, many computers have no browser, let alone a GUI. Some small form factor computers might have embedded Javascript engine but that's a minority. No browser on the router.

> But shell must be the world's most ubiquitous scripting language.

“Shell” isn’t a language. It’s a collection of languages. And not even a consistent one:

- Most BSDs don’t ship Bash as part of base. They default to ksh

- macOS does ship bash but an ancient version and defaults to Zsh

- Some Linux distorts don’t ship sh, instead symlinking to dash or bash.

- Windows doesn’t have any of the above as part of its base install.

Re: The Bun Shell

#172
post #143

One of the selling points of this post is that bash is slow to start. But how fast is bun shell? Have anyone compared bash and bun shell start times?

An absolutely ludicrous point, shells have some of the fastest startup times of all processes

If you are mindful and optimize your shell config, yea.

But common stuff like zsh with oh-my-zsh is known to be rather slow, as in several hundred millisec to start.

Depending on you, of course, that might be considered fast. I consider it insanely slow.

My shell of preference, "nushell":

> Startup Time: 24ms 448µs 147ns

Ideally it would launch in < 16ms (1 frame at 60hz), but I can live with this ;-)

Re: The Bun Shell

#173

Using Windows for development feels like using Linux for anything but server-side work or Macos for gaming, it'll probably work if you have light requirements and don't use the shell that often, but when I think about the last time I tried it, it almost makes me feel fine paying $500 for a ram upgrade on my next mac

I been developing with windows using golang and rust for a couple years now.

I just use vscode and native toolchains.

I don't even use WSL2 but I have basically identical experience as I do on my Linux desktop or my macOS desktop.

Windows + Mac is the slower of the trinity but not by a huge margin.

With Windows you really must disable the Windows Defender stuff for your dev folder or performance will tank as it scans build artifacts for viruses all of the time.

I successfully developed a large number of cross-os apps and currently are working on a game.

I think the OS at this point is not relevant.

I mostly game in Linux these days, so the Windows install is used less and less.

Re: The Bun Shell

#174

I’m increasingly fed up with all shell scripts. Sure shell scripts are great when they’re small. Except then they become not small. But they don’t get rewritten. Piping strings of instructed text between programs is an error prone nightmare. I want full debugger support, strong typing, cross platform support, and libraries not programs. Python isn’t my favorite language. But I’ll take a debugable Python script over b…

I been using golang lately to replace shells.

Pros:

  * LSP
  * faster compile times than the node startup time
  * cross-platform
  * strong types
  * great std + many libs available
  * not bash script
  * fits easily in CI
Cons:

  * not bash script :-)

Re: The Bun Shell

#175

Earlier quoted context omitted.

Cool project but it’s completely impossible to navigate back. Something on that page is spamming my browsers back button history

Strange, history is not used. Which browser are you using ?

Safari on iOS.

Re: The Bun Shell

#176

Earlier quoted context omitted.

I have recently switched to using Nushell as my default shell. They were also writing their own but recently decided instead to begin incorporating github.com/uutils/coreutils (Rust rewrite of GNU coreutils). They target uutils to be a drop-in replacement for the GNU utils. Differences with GNU are treated as bugs.

Yeah, this is nice but also sad. GNU coreutils is ancient at this point. I know this is probably critical to get user share for nushell and not enough dev resources etc. but I’d wish they were innovating on this front too with simpler and less bloated coreutils, as they are already completely changing the shell paradigm.

I agree. I also increasingly find myself using bat, ripgrep, eza etc even with zsh.

Re: The Bun Shell

#177
post #16

I work on Bun - happy to answer any questions/feedback

This is so cool! Is it too late to change the import name? I immediately thought of jquery when seeing "$".

    import { $ as sh } from "bun";
(if you're coming from old school client side javascript I can see the momentary confusion (and in fact I had to blink myself), but in a shell script $ making you think of a shell prompt nonetheless seems like a pretty reasonable default to me)

Re: The Bun Shell

#178
post #167

Earlier quoted context omitted.

Yeah, this is nice but also sad. GNU coreutils is ancient at this point. I know this is probably critical to get user share for nushell and not enough dev resources etc. but I’d wish they were innovating on this front too with simpler and less bloated coreutils, as they are already completely changing the shell paradigm.

It doesn't have to be an either-or proposition Yes? People are free to experiment with alternative cli utils which are not burdened by backward compatibility while nushell also remains easily adoptable by users who are accustomed to coreutils.

Well yeah, but there’s always something to forcing people to move on to the next thing. I know I’m asking for too much.

Re: The Bun Shell

#179
post #167

Earlier quoted context omitted.

Yeah, this is nice but also sad. GNU coreutils is ancient at this point. I know this is probably critical to get user share for nushell and not enough dev resources etc. but I’d wish they were innovating on this front too with simpler and less bloated coreutils, as they are already completely changing the shell paradigm.

It doesn't have to be an either-or proposition Yes? People are free to experiment with alternative cli utils which are not burdened by backward compatibility while nushell also remains easily adoptable by users who are accustomed to coreutils.

I agree. I’ve written about this before but this is what murex (1) does. It reimplements some of coreutils where there are benefits in doing so (eg sed, grep etc -like parsing of lists that are in formats other than flat lines of text. Such as JSON arrays)

Mutex does this by having these utilities named slightly different to their POSIX counterparts. So you can use all of the existing CLI tools completely but additionally have a bunch of new stuff too.

Far too many alt shells these days try to replace coreutils and that just creates friction in my opinion.

1. https://murex.rocks

Re: The Bun Shell

#180

Great, it's approaching the ergonomics of what Perl has offered for decades. And Perl still does it better.

Um, what? Perl in 2024 is just (far) worse Php. Or why just not use Python at that point?

Raku (Perl 6) is a unique and great language for single developer productivity.
Post reply on HN