The Bun Shell • Hacker News Board

Re: The Bun Shell

#151

Post by cassepipe » Sun, Jan 21, 2024, 9:30 AM UTC

brabel wrote: post #124

laserbeam wrote: post #93

Earlier quoted context omitted.

Nope. Zig is still changing. In my understanding bun is generally quick to adapt to these changes, and one of the projects zig is keeping an eye on when breaking changes are introduced.

I've played around with Zig a few times and quickly ran into compiler bugs, things that should work but are not yet implemented, lots and lots of things completely absent in the stdlib (and good luck finding custom zig libraries for most things)... given all that, I just can't fathom how they managed to write Bun mostly in Zig (I see in their repo they do use many C libs too - so it's not just Zig, but still it's a l…

Probably because they are the kind of people that don't rely on libraries and are able to fix compiler bugs

Re: The Bun Shell

#152

Post by yard2010 » Sun, Jan 21, 2024, 9:37 AM UTC

Jarred wrote: post #16

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

Jarred thank you for making the ecosystem better in your own special way like nobody else does

Re: The Bun Shell

#153

Post by FiloSottile » Sun, Jan 21, 2024, 9:40 AM UTC

ycuser2 wrote: post #111

lambda wrote: post #109

Earlier quoted context omitted.

Being in the Google GitHub org doesn't mean "by Google", it means "by someone who works at Google."

But doesn't he get paid by Google to code this?

No, something being under github.com/google means the person who started it was paid by Google, not paid by Google to code this. Google contracts (like most tech contracts in the US) have ridiculously broad IP assignment clauses, so unless you go through a lengthy process to request Google disown something, they own anything you code, and they insist you open source your things under github.com/google.

You decide your own definitions, but that's very different from "Gmail by Google" or even "Go by Google" in my book. Note how the main author has "Ex-Google" in their bio, too.

Re: The Bun Shell

#154

Post by Aerbil313 » Sun, Jan 21, 2024, 9:40 AM UTC

abhinavk wrote: post #102

jchw wrote: post #13

> We've implemented many common commands and features like globbing, environment variables, redirection, piping, and more. Of course on paper that sounds fine. However, something that is missing from here is some assurances of how compatible it actually is with existing shells and coreutils implementations. Is it aiming to be POSIX-compliant/compatible with Bourne shell? I am going to assume that not all GNU extensio…

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.

Re: The Bun Shell

#155

Post by sureglymop » Sun, Jan 21, 2024, 10:02 AM UTC

jackhalford wrote: post #150

sureglymop wrote: post #104

Earlier quoted context omitted.

Wait but find isn't a builtin command right? What do you mean by the odds and ends of GNU find not being there? That doesn't depend on the shell, it's an external program being called.

It does depend on the shell here, bun is reimplementing basic commands to make them cross platform, like rm -rf is not running the rm binary because that doesn’t work on windows

Ahh I see now! I thought they were only doing what you're describing for shell builtins. That does seem like a big effort though, now that you mention it...

Re: The Bun Shell

#156

Post by baudaux » Sun, Jan 21, 2024, 10:02 AM UTC

Bash works well in https://exaequos.com. It is compiled in WebAssembly

Re: The Bun Shell

#157

Post by hnlmorg » Sun, Jan 21, 2024, 10:12 AM UTC

baudaux wrote: post #156

Bash works well in https://exaequos.com . It is compiled in WebAssembly

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

Re: The Bun Shell

#158

Post by [deleted] » Sun, Jan 21, 2024, 10:31 AM UTC

1vuio0pswjnm7 wrote: post #51

"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.

[deleted]

Re: The Bun Shell

#159

Post by baudaux » Sun, Jan 21, 2024, 10:39 AM UTC

hnlmorg wrote: post #157

baudaux wrote: post #156

Bash works well in https://exaequos.com . It is compiled in WebAssembly

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 ?

Re: The Bun Shell

#160

Post by simplyinfinity » Sun, Jan 21, 2024, 11:07 AM UTC

In the .net world, we have a namespace called System.IO, that houses cross platform implementations of functions to work with directories, files, searching for files, can't we just have a standard js library in the same spirit, than try to half ass emulate a shell just so someone can run rm - rf. All of this seems extremely unnecessary and a wasted time and energy to solving the wrong problem.