I open my front end code, it is JavaScript. I open my server code, it is JavaScript. My database? JavaScript. My shell commands? JavaScript. I leave my desk to get a snack. I open the fridge, it’s full of JavaScript. I try to scream, but only JavaScript comes out.
The cycle historically is 1.5-2 years for JS: we do the thing our own way and its the best thing ever, in 2 years: we did this thing our way and it was the worst thing ever and now I live in perpetual hell to support it in my project.
I predict that in 2-3 years, we will all go back to using React SPAs for everything and realize server-first apps and web-centric API design were a mistake
That’s really a JS/web thing. You look at Python, C++, Java, etc, and they all have some solid implementations and stick to them. Web is an ADHD kid with decision anxiety and delusions of grandeur
@@Kane0123 a little bit crazy, mostly due to windows. For windows, containers need WSL which doesn't have full access to do what a Linux or MacOS could do. That means either workarounds that can be difficult to do or simply having to do stuff directly with windows, which means no containers. Sometimes you simply have no choice but to use Windows. That's when you cry because all your shell skills become mostly irrelevant. Bun shell would shine in those scenarios. Also containers can consume a lot of resources and you might need those resources free for you to use.
javascript is _much_ more nicer to read and write than a shell script. Nothing is replaced here... it's combining the powers of two worlds, that's the point!
haha, and here I was thinking it was a super innovation from the bun engine, when Deno already had it, just didn't get the same spotlight. Bun is making everything seem like it's something new. Definitely, the Bun team does better in marketing
I have mixed feelings about this. I love shell scripts, but highly dislike code in strings, because you lose out on things like syntax highlighting and intellisense. How do you know which options this implementation of ls has? How do you know which commands are supported at all without trial and error? It feels like simplified APIs would have been more clear and integrated better with existing tooling, but I suppose I'll have to try for myself to see if it really matters.
Wouldn't it be possible to create tooling around this? Like how Tailwind CSS is a syntax confined to strings, but it has tooling for formatting, auto complete, and documentation on hover. There are also plugins to syntax highlight inline code such as SQL inside string literals. I don't see why a similar thing wouldn't be attainable with this
@@wlockuz4467 why? The problem of writing JS shell scripts is annoying enough to warrant a solution, and here we have a really elegant one at that that literally (pun intended) makes it so much easier for beginners to write code. Plus, intellisense really isn’t a big deal at all in string literals, I use it everyday with emotion css function. I’m getting tired of the “if it ain’t broke don’t fix it” anti-innovation crowd, it seems like you just like complaining because it’s easier than learning new things.
@yamyam263 It's called bloatware. You shouldn't be doing shell in a web server, that's just a throwback to CGI and FastCGI then that still wasn't fast enough so people agreed that shell doesn't scale to the web. Now here we are again but with Bun. Also, they tested Bash in their performance test which even its own manpage acknowledges has too many features. If they tested a lightweight shell like Dash I guarantee you it would perform better than any Bun shell written in JS. I saw the writer tested sh but they obviously don't know that many systems symlink sh to bash these days. The whole "what about Windows" argument is irrelevant on the server side ever since containers and WSL. Honestly, people with the complexity engineering mindset are scary. When I was in uni a couple years ago I saw people learning React before basic HTML/CSS. If I tried talking to them about anything fundamental then all of a sudden they knew nothing.
Zsh has a bash compatibility mode, enabled by default when its $0 is "bash" or "-bash". Also macOS moved to it long after it became a popular shell on linux and macs.
indeed, also no mention of csh, where are the BSD guys :D Serioualy, a lot of people don't seem to realise that dash is ubuntu system default and fish is quite popular. Maybe we need to stop creating new incompatible shells to solve the shell compatibility problem.
@@EwanMarshall xkcd/927. I say that devs should be aware of what they're writing for, and readers should look at the shebang. If you want to write something cross-platform, target POSIX sh, and if you want to use something cross platform, don't run it in fish.
Yep. All these different shells exist because of choice. And some provide compatibility but usually not mirroring of functionality, between each other. Implementing shell functions into something that is used as a language is just asking for trouble. Should PHP, which can be used to write command line programs, also implement bash or pwsh?
@@EwanMarshall bash, zsh and dash are at least all Bourne Shell (sh) compatible, dash being a descendant of ash. fish and csh are a whole another can of worms :D By the way, dash being made the default shell for I think Debian some years ago, as an effort to speed up the system so that system scripts don't have to spin up a whole bash instance, uncovered a lot of scripts that were declared as /bin/sh but actually had bash-specific syntax and broke on the switch. Currently, if you want to have cross-system compatibility (not including Windows which as always decides to be the outcast), you've gotta only use sh syntax, as poor as it is.
The mac bash was FreeBSD Bash and does not have all the same flag options as Linux Bash, it was also modified to do MacOS type things. This is hidden a bit by the move to zsh in mac. For example cp -aux works fine on Linux (copy, recursively, save links, only 1 filesystem) but is most similar to cp -pRX source dest on MacOS (it really doesn't have a direct equivalent). Go checkout the relevant man pages
Interesting. More native to the language makes it present a nicer API to the user(Bun user) but it is hard to maintain? It is more like an “illusion” that they allow scripting. More like a very special function that interprets strings very specifically, ideally imitating what shells do
Still using shell commands, I was hoping for better abstraction. E.g. instead of "grep" - you would import a JS function that does the same, then you just write JS instead of bash. Python has far better libraries for this. This is only useful - if you have an existing node project and want to keep some sysadmin stuff in the same project instead of .sh files.
Yeah, that's what I was just thinking too. Unless there is some hard reason you need a npm specific package or just require you work in JS, this doesn’t solve anything new that Python hasn’t been doing for years.
I think when redirecting output to a buffer they just create temp file when interpolating buffer variable into $ string. And when it's done awaiting they just read file - put it into buffer and delete file. This thing is really cool, it could replace python / bash for ci/cd stuff in gitlab/docker for example
Many language runtimes allow you to issue shell commands to the host and listen to the results. It's cool that Bun is adding a nice syntax for it, but it's not like it replaces the shell itself.
iPython has been trying to do this for years. I've seen a couple really odd folks run it somewhat successfully, but you do a pretty stellar job of isolating yourself from the ecosystem in ways that are really non-productive.
At 2:25, I don't get the point : you can install zsh or bash or fish or anything on Linux, and I guess you can do the same thing on MacOs... It's not a problem to run a bash script if your current interpreter is zsh since the shebang tells the kernel which interpreter to run ??
I think the problems comes with ppl using bash extensions while the shebang is sh, on linux the sh is probably a symlink to bash, so it works, but that's not the right way to do it, when the shebang is sh you would expect that it's a posix compliant shell, the same thing happens with makefiles, many ppl use GNU extensions, but the name Makefile or makefile implies that it's a posix compliant makefile, on linux this is not a common issue, since make is usually a symlink to GNU Make, but for other unix-like system this might be an issue
@@lauraprates8764 and how will this deno shell solve that problem? Are they gonna rewrite the existing bash script in deno? If yes, why not rewrite it in python or Ruby? That will eliminate cross platform issue. If cross platform shell is really a need then use Nushell. If speed is a requirement then use faster programming languages (even tho speed is never a requirement in shell).
as some one that uses fish the main issue with it is not being bash compatible, which im fine with as I can just swap to bash if i need to, but I still run all my scripts like deployment scripts in bash, then I dont have to worry about it being on the system as all unix systems come with bash, unless they put js and bun into the kernel I just see this as another fish which its self get a lot of stick for not being bash compatible
Others have said something similar, but this needs to be the default shell in a Web OS (not the dead one by the same name, but the concept). It would also be awesome to have native Linux, Android, MacOS, and Windows support in that OS (possibly with enabling dev mode or something, not the out of the box experience).. but with a cross-platform CLI that bridges the gap and ties right into the browser with support for JS, etc. So awesome! I look forward to see where this goes and what people do with it. And I think the native OS should simply support Progressive Web Apps with only lightweight OS features (like consistent login, settings, file management, graphics, a modern layered theme manager, touch support with context menus, etc).
Hi Phase/Theo. I don't know who's doing the youtube part of this, but it'd help a lot if when Theo mentions "check out that other video i made", we could get a card or at least a link in the description. I don't really have compliments to sandwich this with yet because i haven't watched the rest of the video, sorry. Nice hair, though!
Theo: the bash vs zsh issues you mention are mostly BSD vs Linux/gnu issues. zsh and bash are very compatible, but the different flags, for instance, are the differences between BSD and Linux implementations of commands. I get tripped up by these all the time.
aren't those commandes just binarys on your system and open source for the most part? never really went into it it but would it not be posible to make both behave exacly the same
Wait, I know windows cmd is weird; but I'm pretty sure if you write sh code without bashisms or use the correct shebang for the isms you're using; and avoid file system structure assumptions or assumptions about non-posix tools being available (which won't even work universally on all Linux flavours anyway) it will work well on both Mac and Linux as long as they have the shell matching the shebang installed.
Heck I've even had some success running bashism free shell scripts on windows as long as it's executed using the more linux like shell (which I don't remember what is called) and not the old cmd. Of course Windows is _really_ limited in what it has preinstalled of common tools outside of the basic posix ones.
My first thought after hearing this: so zoomers have invented child_process.execSync. My second thought (after watching the video): so zoomers don't know that shell (if, for, |) and coreutils (ls, rm, cat) are two separate parts of the operating system. And yes there is a win32 port of rm with -rf support, more than one actually.
Sure there's plenty of dev's with experience of bash commands, the typical options you need to remember, all from muscle memory. But we are also now well used to autocomplete and built in docs. It seems the Bun have reimplemented bash commands in JS, and then a layer to process CLI strings into those JS API's. So please, expose those JS API's so I can use them natively, then I can start to forget about the arcane bash commands and options, and have something that is readable, self documenting and that devs that follow don't have to go through the pain of the previous generation.
Meanwhile, Bun is still using WSL on Windows, so the real question is: how much cross-platform is it actually... but cool idea, I can definitely see at least few areas where this would be super useful, like build scripts, simple tools.
@@yojou3695 my point is: it's not Bun that is making it corss-platform - it's WSL. And also, it kind of defeats the purpose: the main promise of Bun is that it is faster than vanilla nodejs tools, but if performance is your main goal then why are you going through another layer of WSL? I know, the effort of virtually implementing every low level thing again specially for Windows is too much and I get that this is beyond reach for now, but let's stop pretending we are making something cross-platform if we are running it inside the tool that is literally designed to run any Linux executable on Windows...
I don't know if I'm happy new people have one less thing they need to learn to get started (bash) or if I'm worried new people won't learn bash and get to the market anyway.
@@whoknows3679 isn't zx basically just a fancy way of running shell commands from node? So if for example "rm blah" doesn't work on Windows, using zx won't help. With Bun it does work. And you can't say it isn't important when you see the download numbers of rimraf
Bun team's roadmap: - Bunker (for Docker users) - Buxt (faster than nuxt) - Bunizzle (faster than Drizzle) - BunDB (why aren't we creating databases with Bun and storing everything in .bundb files?) - BunDoc (if you wanna stick with JsDoc)
The Emacs equivalent of this, Eshell, is extensively documented. Bun shell needs the same. Other than that, I don't actually think this would ever hurt, even in the long rub.
Hi, Great content as always. But some feedback for you. The editing style is sometimes a little uncomfortable. You finish a sentence, and immediately the video cuts to your next sentence. Add a few 100ms please!
4:05 Testing for a file in a list of directories doesn't spawn a new process at all in bash. The [/test command is a builtin. Even if it did execute in a new process, that wouldn't be starting a new bash shell interpreter.
That's not what Theo was trying to say. Running a command like that *from JS* would need to spawn a shell. Both JavaScript and Bash are scripting languages (very different ones, but with some non-zero overlap), and until now Bash was waaay more comfortable for efficiently launching commands. Now with Bun Shell, you can do something very similar from JS with similar performance (but a more feature-rich programming language to back it up)
It's impressive how the knowledge about windows is outdated in this article. Nobody uses cmd anymore. Powershell was released 21 years ago, it's cross platform since 2016 (windows, linux and Mac), it can do everything other scripting languages can do, it not only understands it's own commands, but bash commands as well, you can create aliases for your commands AND it runs c# scrips natively, and you can also build modules to it in c#. So bun is VERY late to the party. But you guys are too busy hating Microsoft 😂
Using cmd on Windows is a "there's your problem" moment. You can get bash or zsh on Windows in at least two fully functioning ways - git even comes with git bash, and there's always WSL which your dev environment will thank you if you move to it.
@@EwanMarshall yeah, if you insist on using stock Windows functionality for whatever reason, PS is miles ahead of the DOS from Wish that is cmd.exe. And it has more of the familiar basic commands.
How is this different (and more importantly better) than using packages like rimraf and which? Presumably it's still platform-specific implementations under the hood, and any performance improvements are down to the implementation avoiding spawning shells rather than the programmer-facing syntax. So what we're really getting is strings as code, which as others have mentioned tends to trip up existing tooling. If shell startup times are really a critical performance issue for your application, then the solution is to do what bun shell is likely doing internally, just write an implementation which avoids shells altogether by using lower-level APIs. It seems a shame for Bun Shell to go through the trouble of solving an actual real problem with a number of common commands (as evidenced by the demand for those packages) only to wrap it up in a hacky centralized shell package that many people won't want to use.
so.... your jq example is that a bun implementation of jq or is that your system happens othave jq? Does bun handle dependencies of command line stuff if its not a bun built in thing? Thats why I kinda dislike this, its great that theyre making the interface for shell calls better with wrapping and stuff but I kinda hate that they're pushing towards making shell calls more defualt? Make a library for ls that takes in a regex if that's what you want, but going through a fake shell like that is a horrendous idea in practice even though it DOES sound really awesome in theory
Imma say it, it feels dirty... but I honestly defaulted to using PHP for cli scripts for a long time, because it was easy to bring team members onboard, get good script output and avoid brain drain from trying to remember the bash-ism to do a specific thing. It feels so dirty to admit it.
No matter how many featues you add to bun, people will still use nodeJS. Every language has their own use cases. And node serves very well in those cases where you use JavaScript.
I would still use Node simply because i despise needless abstractions. If it ultimately runs Node, i'd rather just run Node directly and bypass the middleman, even if the middleman simplifies commands and puts caching facades in the middle
You spent a long time talking about shell compatibility issues ... which/where's, os bin argument incompatibilities, etc .... all great portability issues .... then you introduced a shell implimentation ... $`ls *.js` ... was running the native /bin/ls or is it running a internal ls? (ala busybox) or an internal gzip or internal jq? ... how does this get jq on windows? it doesn't (via bun) ... seems odd to hype the portability of the initial gripes into a shell solution. a "bun + brew" reveal seems like a missing step for many of your initial issues.
do people actually run so many os based commands locally? I have used windows until for the i was like 17, then linux for like 4 more years, and now mac because i was given an mbp, but i still miss the time have had with linux, and I am saving for a windows desktop, & with wls, do I really need anything else?
Depends on the project/company I guess? Maybe devops people need to run the whole pipeline they're creating locally to test them? I'm not devops specialist but the few times I had to change devops stuff in my company I had to build stuff locally, but then again where I work we only use linux so the compatibility stuff was never a problem for us.
You'll find very quickly that with Windows subsystem for Linux, things that shouldn't break do break because it's not a real Linux, it's a containerized Linux and a lot of things are replaced or hobbled. For example if you ever tried to use the networking stack to use things like trace route or ICMP related things or security related things, the network stack will just get in your way. Also the stack will get in your way when you're trying to do specific file operations.
I absolutely love this. I hate shell scripts with a passion. From relatively benign things such as, writing scripts that only work on one specific OS even when building an OSS project that targets multiple OS. Why for the love of god would you do that? You just prevented people from those other OS from contributing to your OSS project because they can't build on their OS, unless they move over or emulate the OS. Which is detrimental to both build performance, developer experience and your project in the long run because you attract less contributors. Or when a company has got a in-house user-base that primarily uses Windows and they then hand out Linux-based scripts to "automate" things. To just plain evil things, like writing a shell-script in which a call to a function/command defines the function-/command-name using a variable which fucks up most if not all IDEs already minimal shell-script support. Which is an issue when people create an entire damned chain consisting of multiple dozens of scripts to handle a CI-pipeline, almost all of which have nice little quirks like that. Yes, I've really seen all of this in production systems and it fuels my hatred for shell-scripts to this day and will for many years to come.
I open my front end code, it is JavaScript. I open my server code, it is JavaScript. My database? JavaScript. My shell commands? JavaScript. I leave my desk to get a snack. I open the fridge, it’s full of JavaScript. I try to scream, but only JavaScript comes out.
ECMAScript
@@fulconandroadcone9488 LigmaScript
@@fulconandroadcone9488 JS ._.
And you write all on the VSCode an electron app, written in JavaScript.
Hrngggggggggggg
If this scope creep keeps up, Bun will end up being an entire OS. You read it here first.
It's like emacs of the js eco system
what could go wrong
bun os becoming more mainstream than any linux distro would be crazy
I am all-in for Bun-OS 2030!
@@b_delta9725 year of the bun desktop
The cycle historically is 1.5-2 years for JS: we do the thing our own way and its the best thing ever, in 2 years: we did this thing our way and it was the worst thing ever and now I live in perpetual hell to support it in my project.
That cut deep. (while pondering the move to HTMX)
i feel that bun is really permeating a lot of principal developer apps. if it goes kaput, it's going to be a mess
@@codywikman1881 I have a feeling that htmx might actually survive the vicious cycle but I wouldn't bet my life on it either...
I predict that in 2-3 years, we will all go back to using React SPAs for everything and realize server-first apps and web-centric API design were a mistake
That’s really a JS/web thing. You look at Python, C++, Java, etc, and they all have some solid implementations and stick to them.
Web is an ADHD kid with decision anxiety and delusions of grandeur
Don't ever set Bun as your system command shell....
i getthejoke but you actually should
Am I crazy to think that the differences between OS shells are less important as a we shift more and more toward containers even locally?
it would be funny if they developed some sort of way to actually make that work, like how zsh has `emulate sh && . /etc/profile` and it just works
Make me!
@@Kane0123 a little bit crazy, mostly due to windows. For windows, containers need WSL which doesn't have full access to do what a Linux or MacOS could do. That means either workarounds that can be difficult to do or simply having to do stuff directly with windows, which means no containers. Sometimes you simply have no choice but to use Windows. That's when you cry because all your shell skills become mostly irrelevant. Bun shell would shine in those scenarios. Also containers can consume a lot of resources and you might need those resources free for you to use.
now you have no idea what are the dependencies of this package because it's written in a string.
solvable problem, also not different from before
These 'lets just see how much crap I can do with this' videos lately are really enjoyable to watch
It certainly feels like an unusual direction to move in, but I have stopped trying to make sense of what goes on in the JS land.
There's no way this kills bash.
javascript: watch me.
Dude likes hyperbole
for webdev it's already meeting the quota. i used to manage my templates with a bash script, but now bun init ./template is easier and better
@@ElmerGLue what's a better tool for templates?
@@b_delta9725 Sounds like you're already a JS dev though.
PHP is staring at bun right now: "really!...."
"7ms to start a shell, very annoying" I believe if you're not an alien, you will not notice that slowness level
"Your brain on JS" lol
🤣🤣
yup! replace a 10mb binary with 3700 node packages so you can write “shell” commands in js - the madness continues!
and basically just created yet a new incompatible shell in doing it.
😂 🤣
It's bun, not node
Not to mention the former is battle tested.
javascript is _much_ more nicer to read and write than a shell script. Nothing is replaced here... it's combining the powers of two worlds, that's the point!
well, no one can deny that the Bun team is working hard on features! I love it. BTW I can't wait for the windows stable version.
This feature seems just like the dax module available in Deno.
haha, and here I was thinking it was a super innovation from the bun engine, when Deno already had it, just didn't get the same spotlight. Bun is making everything seem like it's something new. Definitely, the Bun team does better in marketing
Damn it’s literally the same thing. Thanks for pointing it out!
I have mixed feelings about this. I love shell scripts, but highly dislike code in strings, because you lose out on things like syntax highlighting and intellisense. How do you know which options this implementation of ls has? How do you know which commands are supported at all without trial and error? It feels like simplified APIs would have been more clear and integrated better with existing tooling, but I suppose I'll have to try for myself to see if it really matters.
Wouldn't it be possible to create tooling around this? Like how Tailwind CSS is a syntax confined to strings, but it has tooling for formatting, auto complete, and documentation on hover. There are also plugins to syntax highlight inline code such as SQL inside string literals. I don't see why a similar thing wouldn't be attainable with this
Anything more than a couple one liners and I'd rather have it in an actual bash script so I can use the VSCode shell check extension.
@@barjo_At that point it seems like inventing a problem then creating a solution for it
@@wlockuz4467 why? The problem of writing JS shell scripts is annoying enough to warrant a solution, and here we have a really elegant one at that that literally (pun intended) makes it so much easier for beginners to write code. Plus, intellisense really isn’t a big deal at all in string literals, I use it everyday with emotion css function. I’m getting tired of the “if it ain’t broke don’t fix it” anti-innovation crowd, it seems like you just like complaining because it’s easier than learning new things.
@yamyam263 It's called bloatware. You shouldn't be doing shell in a web server, that's just a throwback to CGI and FastCGI then that still wasn't fast enough so people agreed that shell doesn't scale to the web. Now here we are again but with Bun. Also, they tested Bash in their performance test which even its own manpage acknowledges has too many features. If they tested a lightweight shell like Dash I guarantee you it would perform better than any Bun shell written in JS. I saw the writer tested sh but they obviously don't know that many systems symlink sh to bash these days. The whole "what about Windows" argument is irrelevant on the server side ever since containers and WSL.
Honestly, people with the complexity engineering mindset are scary. When I was in uni a couple years ago I saw people learning React before basic HTML/CSS. If I tried talking to them about anything fundamental then all of a sudden they knew nothing.
This is just absolutely insane. Incredibly hype and happy to be alive in this day and age, where we can implement things like this.
Crazy 🔥💯
Imagine if they did this with Nushell's approach to CLI instead of Bash and you got structured data back from your commands instead.
"Write programs to handle text streams, because that is a universal interface"
~ Unix philosophy
getting text back via stdin and spitting text out on stdout, and operating on this in a pipeline is a feature, not a bug tbh.
@@laalbujhakkar it's intentional sure, but it sucks ass. writing scripts in nushell is so so much easier and they are way more stable too.
Zsh has a bash compatibility mode, enabled by default when its $0 is "bash" or "-bash". Also macOS moved to it long after it became a popular shell on linux and macs.
indeed, also no mention of csh, where are the BSD guys :D Serioualy, a lot of people don't seem to realise that dash is ubuntu system default and fish is quite popular. Maybe we need to stop creating new incompatible shells to solve the shell compatibility problem.
@@EwanMarshall xkcd/927. I say that devs should be aware of what they're writing for, and readers should look at the shebang. If you want to write something cross-platform, target POSIX sh, and if you want to use something cross platform, don't run it in fish.
Yep. All these different shells exist because of choice. And some provide compatibility but usually not mirroring of functionality, between each other. Implementing shell functions into something that is used as a language is just asking for trouble. Should PHP, which can be used to write command line programs, also implement bash or pwsh?
@@EwanMarshall bash, zsh and dash are at least all Bourne Shell (sh) compatible, dash being a descendant of ash. fish and csh are a whole another can of worms :D
By the way, dash being made the default shell for I think Debian some years ago, as an effort to speed up the system so that system scripts don't have to spin up a whole bash instance, uncovered a lot of scripts that were declared as /bin/sh but actually had bash-specific syntax and broke on the switch.
Currently, if you want to have cross-system compatibility (not including Windows which as always decides to be the outcast), you've gotta only use sh syntax, as poor as it is.
The mac bash was FreeBSD Bash and does not have all the same flag options as Linux Bash, it was also modified to do MacOS type things. This is hidden a bit by the move to zsh in mac.
For example cp -aux works fine on Linux (copy, recursively, save links, only 1 filesystem) but is most similar to cp -pRX source dest on MacOS (it really doesn't have a direct equivalent). Go checkout the relevant man pages
Interesting. More native to the language makes it present a nicer API to the user(Bun user) but it is hard to maintain? It is more like an “illusion” that they allow scripting. More like a very special function that interprets strings very specifically, ideally imitating what shells do
Still using shell commands, I was hoping for better abstraction. E.g. instead of "grep" - you would import a JS function that does the same, then you just write JS instead of bash.
Python has far better libraries for this. This is only useful - if you have an existing node project and want to keep some sysadmin stuff in the same project instead of .sh files.
Better yet, we go full javascript and npm install bun-grep with 2000 dependencies
Yeah, that's what I was just thinking too. Unless there is some hard reason you need a npm specific package or just require you work in JS, this doesn’t solve anything new that Python hasn’t been doing for years.
Bun brought Google ZX to their runtime
So, we can run php-cli inside js code. Perfect! :)
you can already do it with spawn_child
Backtick operator in PHP does a very similar thing. Been using PHP to create shell scripts since forever and it's great!
PHP is outdated now, wake up dude!
Nice! Would also love to see a video on Nushell. A shell made with Rust focused on data
Thanks! this is brilliant, well done bun team.
bun shell is like what execa did over a year ago, just slightly more extended?
which I guess copied google's ZX
The end of this video made need laugh so hard. Amazing job!
Impressive and funny at the same time how you present these sane technologies combined!
I think when redirecting output to a buffer they just create temp file when interpolating buffer variable into $ string. And when it's done awaiting they just read file - put it into buffer and delete file. This thing is really cool, it could replace python / bash for ci/cd stuff in gitlab/docker for example
Many language runtimes allow you to issue shell commands to the host and listen to the results.
It's cool that Bun is adding a nice syntax for it, but it's not like it replaces the shell itself.
iPython has been trying to do this for years. I've seen a couple really odd folks run it somewhat successfully, but you do a pretty stellar job of isolating yourself from the ecosystem in ways that are really non-productive.
At 2:25, I don't get the point : you can install zsh or bash or fish or anything on Linux, and I guess you can do the same thing on MacOs... It's not a problem to run a bash script if your current interpreter is zsh since the shebang tells the kernel which interpreter to run ??
I think the problems comes with ppl using bash extensions while the shebang is sh, on linux the sh is probably a symlink to bash, so it works, but that's not the right way to do it, when the shebang is sh you would expect that it's a posix compliant shell, the same thing happens with makefiles, many ppl use GNU extensions, but the name Makefile or makefile implies that it's a posix compliant makefile, on linux this is not a common issue, since make is usually a symlink to GNU Make, but for other unix-like system this might be an issue
@@lauraprates8764 Okay, see what you mean
But then it's just a matter of using *#!/bin/bash* instead of *#!/bin/sh* ^^'
@@lauraprates8764 and how will this deno shell solve that problem? Are they gonna rewrite the existing bash script in deno? If yes, why not rewrite it in python or Ruby? That will eliminate cross platform issue. If cross platform shell is really a need then use Nushell. If speed is a requirement then use faster programming languages (even tho speed is never a requirement in shell).
as some one that uses fish the main issue with it is not being bash compatible, which im fine with as I can just swap to bash if i need to, but I still run all my scripts like deployment scripts in bash, then I dont have to worry about it being on the system as all unix systems come with bash, unless they put js and bun into the kernel I just see this as another fish which its self get a lot of stick for not being bash compatible
Yep, solve shell compatibility by yet a new shell. It hasn't worked the last dozen times. It is that old joke about new standards.
Great! Would love to learn more about this. Sounds like progress and a bit of the hope.
Others have said something similar, but this needs to be the default shell in a Web OS (not the dead one by the same name, but the concept). It would also be awesome to have native Linux, Android, MacOS, and Windows support in that OS (possibly with enabling dev mode or something, not the out of the box experience).. but with a cross-platform CLI that bridges the gap and ties right into the browser with support for JS, etc. So awesome! I look forward to see where this goes and what people do with it. And I think the native OS should simply support Progressive Web Apps with only lightweight OS features (like consistent login, settings, file management, graphics, a modern layered theme manager, touch support with context menus, etc).
That’s crazy they wrote their own. Zx did a nice job of making the $ syntax for shells in js work but cool if things like rm just work.
“This is just your brain on JavaScript, my guy” 😂
Giving JavaScript access to your shell. That's the most reasonable thing I've ever heard
we need an extensible lsp for template tags, it would open a lot of possibilities for all this kind of stuff, the closest thing to macros in js.
this will help me so much
Interesting, I'm still not using bun
Don’t lie
I installed it because of this shell feature. They got me..
I use it for scripts, because its so easy to setup. No typescript setup bs
This feature had existed for years in both node and deno
Look for zx by google for node (originals )
Dax for deno
@BboyKeny
Brilliant content and amazing usage example!🎉
Now let's add PHP to Bun 😍🥰
💀
PHP is a scripting language so you could just do $`php -r "echo 'hello world'"`
Honestly incredible
Seriously, this guy looks like Nikola Tesla.
Funny how I was writing an npm run script with stdin/stdout just this morning and it didn't feel quite right. But this is making a lot of sense.
just learn bash guys, it will a lasting investment
Hi Phase/Theo. I don't know who's doing the youtube part of this, but it'd help a lot if when Theo mentions "check out that other video i made", we could get a card or at least a link in the description. I don't really have compliments to sandwich this with yet because i haven't watched the rest of the video, sorry. Nice hair, though!
Theo: the bash vs zsh issues you mention are mostly BSD vs Linux/gnu issues. zsh and bash are very compatible, but the different flags, for instance, are the differences between BSD and Linux implementations of commands. I get tripped up by these all the time.
aren't those commandes just binarys on your system and open source for the most part? never really went into it it but would it not be posible to make both behave exacly the same
Bruh wtf this is so cool I'm conflicted
They just stole what google did with zx
Wait, I know windows cmd is weird; but I'm pretty sure if you write sh code without bashisms or use the correct shebang for the isms you're using; and avoid file system structure assumptions or assumptions about non-posix tools being available (which won't even work universally on all Linux flavours anyway) it will work well on both Mac and Linux as long as they have the shell matching the shebang installed.
Heck I've even had some success running bashism free shell scripts on windows as long as it's executed using the more linux like shell (which I don't remember what is called) and not the old cmd. Of course Windows is _really_ limited in what it has preinstalled of common tools outside of the basic posix ones.
My first thought after hearing this: so zoomers have invented child_process.execSync. My second thought (after watching the video): so zoomers don't know that shell (if, for, |) and coreutils (ls, rm, cat) are two separate parts of the operating system. And yes there is a win32 port of rm with -rf support, more than one actually.
Sure there's plenty of dev's with experience of bash commands, the typical options you need to remember, all from muscle memory. But we are also now well used to autocomplete and built in docs. It seems the Bun have reimplemented bash commands in JS, and then a layer to process CLI strings into those JS API's. So please, expose those JS API's so I can use them natively, then I can start to forget about the arcane bash commands and options, and have something that is readable, self documenting and that devs that follow don't have to go through the pain of the previous generation.
I love how, in the *one* other language that natively handles JSON elegantly, you chose to instead export that work out to `jq`.
Meanwhile, Bun is still using WSL on Windows, so the real question is: how much cross-platform is it actually... but cool idea, I can definitely see at least few areas where this would be super useful, like build scripts, simple tools.
i mean, wsl is the only sane option, why would they ever do something different
@@yojou3695 my point is: it's not Bun that is making it corss-platform - it's WSL. And also, it kind of defeats the purpose: the main promise of Bun is that it is faster than vanilla nodejs tools, but if performance is your main goal then why are you going through another layer of WSL? I know, the effort of virtually implementing every low level thing again specially for Windows is too much and I get that this is beyond reach for now, but let's stop pretending we are making something cross-platform if we are running it inside the tool that is literally designed to run any Linux executable on Windows...
This exist on both node and deno and with deno you can compile to binary on windows
Zx for node
Dx for deno
Self promo, there is a package nodejsscript for cross-platform scripting (uses shelljs library internally).
PowerShell Core is pretty popular and also cross-platform.
I don't know if I'm happy new people have one less thing they need to learn to get started (bash) or if I'm worried new people won't learn bash and get to the market anyway.
what can be written in javascript will be implemented in bun
Bun + Bash = Bush shell
Bun has done a better job at Deno than Deno! omg, roasted 😬
Deno has had this for years, but is not like they created
Google created this, look for zx for node
except it's not true
@@robertsimplerinoYeah, it is not fair.
So like google's zx?
Exactly, not sire why people think this is new it literally been out for years for both node and deno
@@whoknows3679 isn't zx basically just a fancy way of running shell commands from node? So if for example "rm blah" doesn't work on Windows, using zx won't help. With Bun it does work. And you can't say it isn't important when you see the download numbers of rimraf
@@dasten123 what you mean lol bun doesn’t even work properly on windows
@@whoknows3679 not yet but they are working on it right now
agreed, this is dope
Bun team's roadmap:
- Bunker (for Docker users)
- Buxt (faster than nuxt)
- Bunizzle (faster than Drizzle)
- BunDB (why aren't we creating databases with Bun and storing everything in .bundb files?)
- BunDoc (if you wanna stick with JsDoc)
The Emacs equivalent of this, Eshell, is extensively documented. Bun shell needs the same. Other than that, I don't actually think this would ever hurt, even in the long rub.
Perl was the tool to replace shells….
Hi,
Great content as always. But some feedback for you. The editing style is sometimes a little uncomfortable. You finish a sentence, and immediately the video cuts to your next sentence. Add a few 100ms please!
4:05 Testing for a file in a list of directories doesn't spawn a new process at all in bash. The [/test command is a builtin. Even if it did execute in a new process, that wouldn't be starting a new bash shell interpreter.
That's not what Theo was trying to say. Running a command like that *from JS* would need to spawn a shell. Both JavaScript and Bash are scripting languages (very different ones, but with some non-zero overlap), and until now Bash was waaay more comfortable for efficiently launching commands. Now with Bun Shell, you can do something very similar from JS with similar performance (but a more feature-rich programming language to back it up)
we need a LMAO lang video Theo!
It's impressive how the knowledge about windows is outdated in this article.
Nobody uses cmd anymore. Powershell was released 21 years ago, it's cross platform since 2016 (windows, linux and Mac), it can do everything other scripting languages can do, it not only understands it's own commands, but bash commands as well, you can create aliases for your commands AND it runs c# scrips natively, and you can also build modules to it in c#.
So bun is VERY late to the party. But you guys are too busy hating Microsoft 😂
There's a similar thing for python called xonsh, except it's a superset of posix sh.
PowerShell already solved that problem 😅
Using cmd on Windows is a "there's your problem" moment. You can get bash or zsh on Windows in at least two fully functioning ways - git even comes with git bash, and there's always WSL which your dev environment will thank you if you move to it.
Not to mention, powershell is theas much the default shell on windows now.
@@EwanMarshall yeah, if you insist on using stock Windows functionality for whatever reason, PS is miles ahead of the DOS from Wish that is cmd.exe. And it has more of the familiar basic commands.
If you just wrote to the POSIX spec you’d all be fine.
How is this different (and more importantly better) than using packages like rimraf and which? Presumably it's still platform-specific implementations under the hood, and any performance improvements are down to the implementation avoiding spawning shells rather than the programmer-facing syntax. So what we're really getting is strings as code, which as others have mentioned tends to trip up existing tooling.
If shell startup times are really a critical performance issue for your application, then the solution is to do what bun shell is likely doing internally, just write an implementation which avoids shells altogether by using lower-level APIs. It seems a shame for Bun Shell to go through the trouble of solving an actual real problem with a number of common commands (as evidenced by the demand for those packages) only to wrap it up in a hacky centralized shell package that many people won't want to use.
If you make a POSIX compliant script it should work on bash and zsh without needing to download something new
shh don't scare them, they're skiddish.
With this, Bun can now efectivelly replace Makefile and Justfile
"Writing cross platform scripting is actually really difficult!" PowerShell
The only downside is you will have to touch power shell 💀
this actually pissed me off
so.... your jq example is that a bun implementation of jq or is that your system happens othave jq? Does bun handle dependencies of command line stuff if its not a bun built in thing?
Thats why I kinda dislike this, its great that theyre making the interface for shell calls better with wrapping and stuff but I kinda hate that they're pushing towards making shell calls more defualt? Make a library for ls that takes in a regex if that's what you want, but going through a fake shell like that is a horrendous idea in practice even though it DOES sound really awesome in theory
Imma say it, it feels dirty... but I honestly defaulted to using PHP for cli scripts for a long time, because it was easy to bring team members onboard, get good script output and avoid brain drain from trying to remember the bash-ism to do a specific thing.
It feels so dirty to admit it.
Shoutouts to korn shell and rc!
But in all seriousness every os should have at least busybox (or toybox) installed in base.
No matter how many featues you add to bun, people will still use nodeJS.
Every language has their own use cases. And node serves very well in those cases where you use JavaScript.
I would still use Node simply because i despise needless abstractions. If it ultimately runs Node, i'd rather just run Node directly and bypass the middleman, even if the middleman simplifies commands and puts caching facades in the middle
anything that can be written in javascript, will be eventually written in javascript
You spent a long time talking about shell compatibility issues ... which/where's, os bin argument incompatibilities, etc .... all great portability issues .... then you introduced a shell implimentation ... $`ls *.js` ... was running the native /bin/ls or is it running a internal ls? (ala busybox) or an internal gzip or internal jq? ... how does this get jq on windows? it doesn't (via bun) ... seems odd to hype the portability of the initial gripes into a shell solution. a "bun + brew" reveal seems like a missing step for many of your initial issues.
do people actually run so many os based commands locally?
I have used windows until for the i was like 17, then linux for like 4 more years, and now mac because i was given an mbp, but i still miss the time have had with linux, and I am saving for a windows desktop, & with wls, do I really need anything else?
Depends on the project/company I guess? Maybe devops people need to run the whole pipeline they're creating locally to test them? I'm not devops specialist but the few times I had to change devops stuff in my company I had to build stuff locally, but then again where I work we only use linux so the compatibility stuff was never a problem for us.
You'll find very quickly that with Windows subsystem for Linux, things that shouldn't break do break because it's not a real Linux, it's a containerized Linux and a lot of things are replaced or hobbled. For example if you ever tried to use the networking stack to use things like trace route or ICMP related things or security related things, the network stack will just get in your way. Also the stack will get in your way when you're trying to do specific file operations.
If this compiles to a standalone treeshaken binary, I'm in
It's nothing more than syntactic sugar
I tried bun 2 months ago,
Where I found bugs while running on my Ubuntu,it was running fine on windows but having some issues with Linux
Approved!
now what, this aint stopping me from using bash, bash 4.3ms on my arch linux like i don't have much things in .bashrc.
Does adding a shebang at the top work?
Technically possible, except Windows
bun is pre alpha hypeware at this point
recursive "cp" with direcrtories has a different semantic in macOS and Linux. Creepy stuff.
Bun is going wild !
Holy shit. Don’t do this. 😂
3:42 is Bun dissing Arch Linux??? Holy Shit these guys are coming with all the guns...
I absolutely love this. I hate shell scripts with a passion.
From relatively benign things such as, writing scripts that only work on one specific OS even when building an OSS project that targets multiple OS.
Why for the love of god would you do that? You just prevented people from those other OS from contributing to your OSS project because they can't build on their OS, unless they move over or emulate the OS. Which is detrimental to both build performance, developer experience and your project in the long run because you attract less contributors.
Or when a company has got a in-house user-base that primarily uses Windows and they then hand out Linux-based scripts to "automate" things.
To just plain evil things, like writing a shell-script in which a call to a function/command defines the function-/command-name using a variable which fucks up most if not all IDEs already minimal shell-script support. Which is an issue when people create an entire damned chain consisting of multiple dozens of scripts to handle a CI-pipeline, almost all of which have nice little quirks like that.
Yes, I've really seen all of this in production systems and it fuels my hatred for shell-scripts to this day and will for many years to come.
Node already has no by Google for cli tools
"bun did the work"