61–70 of 122 posts
Earlier quoted context omitted.
Ok, but I'm not really looking to my package manager for entertainment. To me this jargon is just needlessly obtuse.
hm quite a sour take. I find that the names actually are reflective of an actual storage process so they fulfill both the playfulness and the natural naming.
Will Bun JavaScript Take Node's Crown - https://news.ycombinator.com/item?id=32457587 - Aug 2022 (321 comments)
Bun: A Complete Overhaul of the JavaScript Ecosystem - https://news.ycombinator.com/item?id=32243534 - July 2022 (25 comments)
Bun gets “bun:FFI” – call native libraries from JavaScript - https://news.ycombinator.com/item?id=32120090 - July 2022 (16 comments)
Bun (can become) the ideal JavaScript runtime - https://news.ycombinator.com/item?id=32067268 - July 2022 (14 comments)
Bun: Fast JavaScript runtime, transpiler, and NPM client written in Zig - https://news.ycombinator.com/item?id=31993429 - July 2022 (314 comments)
Bun – fast JavaScript and CSS bundler - https://news.ycombinator.com/item?id=29179848 - Nov 2021 (36 comments)
Kind of related:
Hop: Faster than unzip and tar at reading individual files - https://news.ycombinator.com/item?id=29178710 - Nov 2021 (128 comments)
Earlier quoted context omitted.
I 100% agree. Cutesy names should end once the package name has been chosen. Package authors and contributors that overdo the thematic names should stick to writing fiction, not code.
"keg" and "bottle" are cutesy? well, to see the exact opposite of "cutesy", please fork homebrew and give all of those things GUIDs for names, including all the packages a user could install; you'll soon see why the names chosen are quite acceptable, indeed.
It's an incredible achievement, though I worry about the use of an unproven language (Zig) that lacks memory safety by design. JavaScript runtimes, especially those with JITs, have been plagued by vulnerabilities from memory safety, type confusion, and data races. Node.js, despite being based on V8, is still susceptible independently of V8 and introduces its own vulnerabilities. It's not sufficient for the runtime to…
Yes.
> 2. What measures is Oven taking to proactively detect and mitigate vulnerabilities? (e.g.: fuzzing, audits, bug bounties)
Fuzzing will begin soon. Regular security audits will happen around the 1.0 release. Bug bounty seems like a good idea, but it's too early today to know when this will start.
> 3. Will Oven support Zig development to avoid an existential risk in upstream vulnerabilities?
Yes. Oven will donate to Zig Software Foundation.
More broadly - I think about all of this a lot, but until now Bun has been mostly the work of just me. Bun is still very early - there's a lot that's just not implemented yet.
Earlier quoted context omitted.
Ok, but I'm not really looking to my package manager for entertainment. To me this jargon is just needlessly obtuse.
Yep, I found homebrew confusing exactly because of this 'bespoke' terminology.
Earlier quoted context omitted.
I'm curious about where all that performance comes from I know it uses the WebKit JS runtime instead of V8, which is super interesting. Does that cause a performance lift? Or is there some other secret sauce that pervades throughout Bun? Or is it just a matter of Jarred giving lots of attention to spot-optimizing the most important bottlenecks outside of the core runtime?
I suspect it’s the latter. I would guess V8 with a thin wrapper and a ton of effort from someone who cares about perf to port all the native goodies of node would get similar wins.
Earlier quoted context omitted.
Isn't that what they're doing? Providing a monetizable system around open source software. It's the Vercel/Next.js model
I wonder if AWS is a sleeping crocodile ready to eat all these dev-focused paas companies up (by competing or takeovers) in a while. Maybe they are waiting to see who wins first.
Earlier quoted context omitted.
"keg" and "bottle" are cutesy? well, to see the exact opposite of "cutesy", please fork homebrew and give all of those things GUIDs for names, including all the packages a user could install; you'll soon see why the names chosen are quite acceptable, indeed.
This is the worst straw-man I've seen this year. Realistically, non-cute homebrew names would look like bin, libexec, repo, that is to say descriptive names that are already in common use, not GUIDs.
Earlier quoted context omitted.
I am fairly confident that Zig does not lack memory safety by design; from what I understand, the language as a whole isn't even finished, and the memory safety design isn't like a GC'd language or like Rust, so people assume there isn't memory safety when in reality it is at least partially implemented.
I'm afraid "partially implemented" memory safety is also widely known in the offensive security industry as "not memory safe". Many people have fooled themselves into thinking there is a gradient with safer C++ abstractions, libraries in C, custom allocators, static analyzers, valgrind, etc.
Rust isn't even memory safe if you want to be THIS pedantic about it. the unsafe keyword exists in Rust, and it is often used.
Are Bun and Deno in direct competition or do these projects address different markets?
They are roughly in competition, though Deno made the decision early on to largely split itself from the ecosystem and existing conventions of Node (and an enormous body of existing JavaScript packages on npm), whereas Bun did not. Bun, AFAIK, aims to be compatible with Node and existing the npm ecosystem.
I very much admire that he seems to be trying to get things right in light of lessons learned, but history would imply that backwards compatibility tends to trump better technology on average.