Live data from Hacker News

Bun 0.3

bun.sh

41–50 of 64 posts

Re: Bun 0.3

#41
post #29

Earlier quoted context omitted.

Bun seems really cool! I had a question about this part: > Bun now works in more Linux environments, including Amazon Linux 2 and builds for Vercel and Cloudflare Pages. (Previously, you might have seen errors like: "version 'GLIBC_2.29' not found") How would building for Vercel and CF pages work? Like normal but installing the relevant build tools using bun?

Additionally, I'd love to see the PR where this change was implemented. I've been trying to convince Zola, a static site generator written in Rust, to support older versions of GLIBC.

Most of the code is here. It needs some linker config but basically you wrap symbols which depend on too new versions of glibc and dynamically load them or call some other implementation internally

https://github.com/oven-sh/bun/blob/main/src/bun.js/bindings...

Re: Bun 0.3

#42
post #4

I like this tech "fights" (evolutions). Even if bun will not overtake node, it will make node better. We see this many times with other projects (js/coffeescript/typescript/..., php/HHVM/HPHPc, webpack/vite/...)

Happened with node via io.js back in the day too

Hadn't heard of io.js before but from reading up on it it seems to be a unique case since they had the explicit goal of merging back into node eventually.

Can't really find what the main benefits of io.js are though...

Re: Bun 0.3

#43
post #20
post #12

I work on Bun happy to answer any questions or feedback

I was curious where the 'dgram' module is on your roadmap?

Lower than “tls” and “dns”, but not much lower. It’s necessary for databases and anything databases need is important for Bun to support well

Re: Bun 0.3

#44
post #4

I like this tech "fights" (evolutions). Even if bun will not overtake node, it will make node better. We see this many times with other projects (js/coffeescript/typescript/..., php/HHVM/HPHPc, webpack/vite/...)

> Even if bun will not overtake node...

Why wouldn't bun, if it keeps its performance promises on its way to 100% node compatibility? I am intently keeping tabs on bun's progress because a better-engineered, faster, and leaner node-compatible runtime means $$ saved in server costs.

Besides, from the effort going into bun, it looks like the node community has its work cut out.

Re: Bun 0.3

#45

I don't see any reason to use this over Deno.

Performance matters a lot.

Well then... don't write your back end in javascript? The next most popular alternative is probably Ruby which has even worse performance. I don't disagree that performance matters but I don't think the industry seems to agree

Re: Bun 0.3

#46
post #45

Earlier quoted context omitted.

Performance matters a lot.

Well then... don't write your back end in javascript? The next most popular alternative is probably Ruby which has even worse performance. I don't disagree that performance matters but I don't think the industry seems to agree

[deleted]

Re: Bun 0.3

#47
post #12

I work on Bun happy to answer any questions or feedback

Congrats on the release! Were there any organizational or policy changes after the "9 month grind" [0] tweet? Or is this still the policy of the bun/oven org? [0]: https://news.ycombinator.com/item?id=32584211

Tweet in question:

https://archive.ph/PP6Im

Re: Bun 0.3

#48
post #12

I work on Bun happy to answer any questions or feedback

Are there any exclusive features that Bun has, that are particularly well-suited for writing databases or other low-latency, high-throughput I/O applications?

Seems like being written in Zig might give it a good foot in the door here.

Re: Bun 0.3

#49
post #33

Earlier quoted context omitted.

What's the target level of compatibility with existing npm modules? 100%? Some lower percentile? Hate to carry forward baggage of past design choices, but likely essential to really get widespread adoption. I'd definitely start using Bun for my projects today (non-production), if it works seamlessly with existing packages.

We want Bun to feel more like an upgrade from Node than switching runtimes Basically everything that doesn’t rely on node’s internal “bindings” C++ stuff should eventually be supported

Will bun perpetuate the dependency hell that it prevalent with node? I like the deno approach better in this regard.

Are there any install methods other than piping curl into bash? Like packages.

Re: Bun 0.3

#50
Does anyone know if there's a TypeScript runtime that compiles/runs TypeScript directly instead of going through the JS/ECMAScript intermediary?
Post reply on HN