[HN Gopher] Bun 0.3
___________________________________________________________________
Bun 0.3
Author : mcovalt
Score : 143 points
Date : 2022-12-07 14:30 UTC (8 hours ago)
(HTM) web link (bun.sh)
(TXT) w3m dump (bun.sh)
| packetlost wrote:
| Does anyone know if there's a TypeScript runtime that
| compiles/runs TypeScript directly instead of going through the
| JS/ECMAScript intermediary?
| MrJohz wrote:
| 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.
| xchkr1337 wrote:
| I don't see any reason to use this over Deno.
| [deleted]
| epolanski wrote:
| Performance matters a lot.
| culi wrote:
| 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]
| _hypx wrote:
| The more options the better.
| philippz wrote:
| https://medium.com/deno-the-complete-reference/hello-world-p...
| tested23 wrote:
| Doesnt deno bring a bunch of security improvements to the
| table?
| CharlesW wrote:
| FWIW this similarly-trivial "Hello world" benchmark shows
| Bun's lead at ~25% faster than Deno at the moment, which
| doesn't seem insurmountable.
| https://github.com/denosaurs/bench
| panzerboiler wrote:
| Those benchmarks are measuring the speed of the tool used
| to run the benchmark, not the http servers. Take them with
| a pack of salt.
| CharlesW wrote:
| "Take all benchmarks with a grain of salt" is my middle
| name, but the benchmark I linked to is an open source
| project with 17 contributors. In contrast, I'm not seeing
| any source referenced by the Medium benchmark article I
| responded to.
| [deleted]
| leejoramo wrote:
| Will be watching how the new nodejs compatibility works out.
| Maybe in a few months I will have the time to test porting a few
| expresses applications.
| Jarred wrote:
| I work on Bun
|
| happy to answer any questions or feedback
| damsta wrote:
| What are the things you are hoping to release in Bun v0.4?
| n42 wrote:
| 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?
| johnnypangs wrote:
| 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?
| dstaley wrote:
| 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.
| Jarred wrote:
| 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...
| Jarred wrote:
| Bun is able to run in these environments now - before it had
| that glibc error
|
| Right now you'd need to download it via curl
| https://bun.sh/install | bash
|
| But we need to make that better
| wdb wrote:
| I was curious where the 'dgram' module is on your roadmap?
| Jarred wrote:
| 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
| jamesmunns wrote:
| 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
| henry_viii wrote:
| Tweet in question:
|
| https://archive.ph/PP6Im
| gavinray wrote:
| 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.
| christophilus wrote:
| 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?
| Jarred wrote:
| You can set "jsxImportSource" in tsconfig.json or
| jsconfig.json to point to a different jsx package
|
| There is also a setting in bunfig.toml but it appears we
| haven't documented it yet
| sieve wrote:
| 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...
| bcjordan wrote:
| 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
| adam_arthur wrote:
| 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.
| Jarred wrote:
| 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
| petre wrote:
| 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.
| nine_k wrote:
| I suppose a compatibility shim for features that should not
| go into the new core could work. It would have a performance
| cost, but as long as this cost is limited to some deprecated
| APIs it would be OK.
| adam_arthur wrote:
| Yeah, a compatibility branch or a build time cross
| compatibility compiler would suffice.
| adam_arthur wrote:
| I'm surprised JSC doesn't get more press. Lots of news/articles
| about V8, but seems JSC has eclipsed it on perf by some metrics.
|
| Overall though, Bun honestly looks like it has a shot to supplant
| Node if npm package compatibility reaches a sufficient level. Or
| at least encourage Node to work much harder on perf. Deno feels a
| bit too esoteric/theoretical in its approach, vs Bun which looks
| to be much more focused on ease of use
| [deleted]
| progx wrote:
| 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/...)
| ignoramous wrote:
| > _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.
| christophilus wrote:
| Also, a big reduction in dependencies could make hardening a
| Bun application something that's realistic. It's unimaginable
| with the typical node stack that I've seen.
| nesarkvechnep wrote:
| Also Elixir made Erlang better.
| adam_arthur wrote:
| Happened with node via io.js back in the day too
| culi wrote:
| 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...
| shard972 wrote:
| ithrow wrote:
| ,npm/yarn
| gcoguiec wrote:
| I would also mention io.js in Node's lifetime and Merb in
| Rails'
| dmix wrote:
| Haven't heard the name Merb in forever.
| ryanto wrote:
| Looks awesome. Gotta say, the built in testing, websockets, and
| file system router are exciting to see.
|
| Is anyone using bun in production? Would love to hear your
| experience.
| christophilus wrote:
| 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.
| philippz wrote:
| Would love to switch, but we're still missing the NodeJS TLS API
| Jarred wrote:
| The "tls" module is on our list of node core modules to
| implement, somewhere near the top
| christophilus wrote:
| Not that I want to cause scope creep, but it would be amazing
| to have something like the certmagic library (the Caddy
| team's automatic TLS Go library) without having to reach for
| a 3rd party.
| Jarred wrote:
| I would love for us to do this builtin to Bun.serve()
|
| No idea about timeline but something we are thinking about
| qwerty3344 wrote:
| what are the other core modules near the top?
___________________________________________________________________
(page generated 2022-12-07 23:02 UTC)