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

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

I would also mention io.js in Node's lifetime and Merb in Rails’

Also Elixir made Erlang better.

,npm/yarn

I’m starting a project that requires a lower level language. Ideally I have tighter control of memory and no GC. I want to move fast and be safe. Go gives me the speed of development I desire, but is a little higher level than this project calls for. Rust is in theory the right choice, but my development speed is like molasses. Given I hope for this project to turn into a company I seek VC backing for, I’m uncomfortable investing in a tool that slows me down so early on.

How has Zig been for you in this regard? Do you have any regrets building your company’s flagship software around it at this stage?

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.

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

I have been unable to locate examples using remote import/export. I would like to able to do a

  import { inflate } from "https://www.example.org/libs/zlib.ts"

with bun downloading all dependencies in the background. Like Deno does.[1]

[1] https://deno.land/manual@v1.28.3/basics/modules#remote-impor...

I’ve built a few utility apps at work. I absolutely love it.

I hijacked your jsx support so that I had built in server-side templating without having to pull in any external libraries (e.g. React). The process of building my own TSX bindings was pretty trivial, but did feel like a hack (I created a React package.json entry that was a file path to my local source folder).

Is that scenario doable with less hackery?

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?

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.

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

Who do you see as biggest competition (Eg Just-JS, Deno, etc)

Thanks for all you do to make the ecosystem better, btw.

can Bun help solve the hell that is running `npm install` in a project and seeing an error mentioning `node-pre-gyp` in the output with some platform-specific native dependency build issue

Great job, when can we expect native MS Windows support?

What are the things you are hoping to release in Bun v0.4?

Is there a plan to add:

- Compiling to a single binary

- WASM

I’m using it for some internal business apps. I quite like it.

It’s early days, so I definitely miss some things— like a REPL.

I gotta say, though, it’s a good feeling when you deploy a zero-dependency TypeScript application complete with tests.

The more options the better.

Performance matters a lot.

The “tls” module is on our list of node core modules to implement, somewhere near the top

There's AssemblyScript, which is designed to be Typescript-esque, and compiles to webassembly, but apart from that, there's not much. The thing is that there's not much value in a Typescript runtime. The semantics of Typescript are fundamentally the semantics of Javascript, but with labels attached to each variable giving a rough hint as to what the type might be. For static analysis, that's really useful - rough hints are mostly good enough for human things like editor hints and typechecking that are allowed to be incorrect - but when it comes to executing the code, the type hints don't actually have that much value. It's very easy for them to be incorrect ("A as B" is a valid Typescript construct that just asserts that a variable is a type without needing to check that it's actually the case), and so the runtime engine can only ever use them as a hint. But with the JIT engines that must runtimes use, the interpreter already has a pretty good idea what the type is going to be, because it's already executed the code and inspected the runtime variable. So you don't get a huge amount of practical value by using the type hints.

And if the type hints aren't useful for the runtime, then there's no real reason to enforce that they be present. A Typescript runtime that ignores types is just a Javascript runtime with a more pedantic syntax, and if you're going to that effort, you may as well support both.

Not now but there is work going on in the JS standardisation process that will mean valid typescript is interpreted as valid JavaScript. (Basically run it and ignore the type annotations)