[HN Gopher] Anthropic acquires Bun
___________________________________________________________________
Anthropic acquires Bun
Author : ryanvogel
Score : 2106 points
Date : 2025-12-02 18:05 UTC (1 days ago)
(HTM) web link (bun.com)
(TXT) w3m dump (bun.com)
| ChrisArchitect wrote:
| Associated Anthropic post:
| https://www.anthropic.com/news/anthropic-acquires-bun-as-cla...
| colesantiago wrote:
| Is Claude Code the first CLI tool to have a $1BN ARR?
| CSSer wrote:
| I don't know for sure, but it's definitely the first tool of
| that value to have a persistent strobing (scroll position) bug
| so bad that passersby ask me if I'm okay when they see it.
| epiccoleman wrote:
| Man, I had never even put words to that problem but you are
| right that it is _beyond_ annoying. It seems to me like it
| worsens the longer the Claude instance has run - I don 't
| seem to see it early in the session.
| CSSer wrote:
| Yeah, issues have been open on GitHub for months. I've
| tried shortening my scrollback history and using other
| emulators but it doesn't seem to make a difference. It's
| pretty frustrating for a paid tool.
| thomasfromcdnjs wrote:
| ha I thought it was just a me thing and had have accepted
| my fate.
| jedixit wrote:
| This graph from the SemiAnalysis blog suggests that GitHub
| Copilot reached it earlier this year:
| https://substackcdn.com/image/fetch/$s_!BGEe!,f_auto,q_auto:...
| simonw wrote:
| "GitHub Copilot" encompasses so many different products now
| that it's hard to see it as a CLI tool.
| altmanaltman wrote:
| It doesn't make a lot of sense that they'll compare
| Microsoft 365 Copilot with Claude Code, though? Like it is
| a legit CLI tool but we should ignore it because it shares
| the name with something else?
| simonw wrote:
| The GitHub Copilot CLI tool is brand new, they only
| launched that in September:
| https://github.blog/changelog/2025-09-25-github-copilot-
| cli-...
|
| Prior to that GitHub Copilot was either the VS Code IDE
| integration or the various AI features that popped up
| around the GitHub.com site itself.
| altmanaltman wrote:
| Yeah but my point was it's pretty clear which Copilot the
| article was talking about and pretending like it could be
| anything beacuse "everything's copilot" is a L take
| sorry.
| fragmede wrote:
| Terraform gets to $600mm if you squint really hard make up
| stuff. Kubectl though. Whatever you want to say about
| kubernetes complexity, it does get a bunch of money run through
| it. We could also look at aws-cli, gcloud and az, and if we
| assign cloud budgets that get run through there, I'm sure it's
| in the hundreds of millions. Then there's git. Across the whole
| ecosystem, there's probably a cool couple billion floating
| through there. gh is probably much smaller. Other tools like
| docker and ansible come to mind, though those are not quite as
| popular. Cc only hits $1B ARR if you squint really hard in the
| first place, so I think in this handwavy realm, I'd say aws-cli
| comes first, then kubectl, then git, with maybe docket and
| terraform in the mix as well. Nonetheless, Claude is a really
| awesome cli tool that I use most days, I find.
| theflyinghorse wrote:
| Congratulations to the bun team!
| victorbuilds wrote:
| I use Claude Code CLI daily - it's genuinely changed how I work.
| The $1B number sounds crazy but honestly tracks with how good the
| tool is. Curious how Bun integration will show up in practice
| beyond the native installer.
| Aeolun wrote:
| Doesn't sound crazy at all? My Max subscription costs me more
| than all the other netflix/spotify etc combined, but I pay it
| happily, and spotify would go before Claude does.
| slig wrote:
| Love bun! Congratulations!
| re-thc wrote:
| Congrats...
|
| > Long-term stability. a home and resources so people can safely
| bet their stack on Bun.
|
| Isn't it the opposite? Now we've tied Bun to "AI" and if the AI
| bubble or hype or whatever bursts or dies down it'd impact Bun.
|
| > We had over 4 years of runway to figure out monetization. We
| didn't have to join Anthropic.
|
| There's honestly a higher chance of Bun sticking out that runway
| than the current AI hype still being around.
|
| Nothing against Anthropic but with the circular financing, all
| the debt, OpenAI's spending and over-valuations "AI" is the
| riskier bet than Bun and hosting.
| ricopags wrote:
| I say don't muddy the water with the public panic over "will it
| won't it" bubble burst predictions.
|
| The effective demand for Opus 4.5 is bottomless; the models
| will only get better.
|
| People will always want a code model as good as we have now,
| let alone better.
|
| Bun securing default status in the best coding model is a win-
| win-win
| re-thc wrote:
| > I say don't muddy the water with the public panic over
| "will it won't it" bubble burst predictions.
|
| It does matter. The public ultimately determines how much
| they get in funding if at all.
|
| > The effective demand for Opus 4.5 is bottomless; the models
| will only get better.
|
| The demand for the Internet is bottomless. Doesn't mean
| Dotcom didn't crash.
|
| There are lots of scenarios this can play out, e.g. Anthropic
| fails to raise a certain round because money dried up. OpenAI
| buys Anthropic but decides they don't need Bun and closes out
| the project.
| pzo wrote:
| Opus 4.5 is not living in vacuum. It's the most expensive of
| models for coders and there is Gemini 3 pro - with many
| discounts and deepseek 3.2 that is 50x cheaper and not much
| behind.
| phantasmish wrote:
| Yeah, no reader of tech news will take an acquisition of a
| company with four years of runway as anything but _decreasing_
| the odds their product will still be around (and useful to the
| same audience...) in four years. Even without being tied to a
| company with lots of exposure to a probable bubble.
| supern0va wrote:
| How so? Presumably Jarred got a nice enough payout that if
| Anthropic failed, he would not need to work. At that point,
| he's more than welcome to take the fully MIT licensed Bun and
| fork it to start another company or just continue to work on
| it himself if he so chooses.
| phantasmish wrote:
| History?
|
| I didn't say it was definitely the end or definitely would
| end up worse, just that someone who's followed tech news
| for a while is unlikely to take this as _increasing_ the
| odds Bun survives mid-term. If the company was in trouble
| anyway, sure, maybe, but not if they still had fourish
| years in the bank.
|
| "Acquired product thriving four years later" isn't unheard
| of, but it's not what you expect. The norm is the product's
| dead or stagnant and dying by then.
| littlestymaar wrote:
| > At that point, he's more than welcome to take the fully
| MIT licensed Bun and fork it to start another company or
| just continue to work on it himself if he so chooses.
|
| Is there any historical precedent of someone doing that?
| Lermatroid wrote:
| Yeah that's the main part that puzzled me, super happy for the
| team that they got a successful exit, but I wouldn't really
| consider Anthropic's situation to be stable...
| jedahan wrote:
| :(
| qsort wrote:
| Anthropic? The AI people?
| jsheard wrote:
| Look, if a terminal emulator can raise $67 million by riding
| the AI hypewave then a Javscript runtime can do the same.
| Nobody ever said that AI investments and acquisitions have to
| make any sense.
| jackblemming wrote:
| The Bun team works hard, glad to see it pay off.
| tkel wrote:
| Oh no ... unfortunately this likely means a Bun.AI API in my JS
| runtime.
| afavour wrote:
| What matters: it's staying open source and MIT licensed. I
| sincerely hope it stays that way. Congrats to the Bun team on
| making a great tool and getting the recognition they deserve.
|
| > Being part of Anthropic gives Bun: Long-term stability.
|
| Let's see. I don't want to always be the downer but the AI
| industry is in a state of rapid flux with some very strong
| economic headwinds. I wouldn't confidently say that hitching your
| wagon to AI gives you long term stability. But as long as the
| rest of us keep the ability to fork an open source project I
| won't complain too much.
|
| (for those who are disappointed: this is why you stick with Node.
| Deno and Bun are both VC funded projects, there's only one way
| that goes. The only question is timeline)
| cortesoft wrote:
| Nothing gives you long term stability in tech. You have to
| constantly work at staying stable, and it isn't always up to
| anything the company is in control of, no matter what ownership
| they have.
| afavour wrote:
| > Nothing gives you long term stability in tech.
|
| Sure. But everything is relative. For instance, Node has much
| more likelihood of long term stability than Bun, given its
| ownership.
| skybrian wrote:
| Sure, that makes it a good backup strategy. But there's
| little reason to use a worse tool until the time you need
| the backup comes.
| pier25 wrote:
| > _Node has much more likelihood of long term stability
| than Bun_
|
| Given how many more dependencies you need to build/maintain
| a Node app, your Bun application has a better chance of
| long term stability.
|
| With Node almost everything is third party (db driver, S3,
| router, etc) and the vast majority of NPM deps have dozens
| if not hundreds of deps.
| afavour wrote:
| I'm talking about long term stability of the tool and
| ecosystem, not of any specific app.
| pelagicAustral wrote:
| Godspeed. Seems like a good pairing. Bun is sort of the only part
| of the JS ecosystem I like, and Code has become such an important
| tool for my work, that I think good things will come out of this
| match. Go Bundler as well.
| wiseowise wrote:
| Hope nobody buys Astral or Python is f*cked.
| zelphirkalt wrote:
| Then it would probably be back to Poetry. Or some other
| newcomer, or maybe a fork of uv.
| andrewl-hn wrote:
| Honestly, given the constant rollercoaster of version
| management and building tools for Python the move to
| something else would be expected rather than surprising.
|
| I've seems like a great tool, but I remember thinking the
| same about piping, too.
| baq wrote:
| uv is a revolution in every possible positive sense of the
| word in the Python world and I've been here since 1.5. it
| is imperative that bitter oldtimers like us try it, I did
| and the only regret I've got is that I didn't do it sooner.
| zelphirkalt wrote:
| I also tried it and am now using it for new projects. But
| I was just fine with Poetry too. Yes, uv is faster and
| probably better code. But my use-cases didn't necessitate
| to re-create the venvs frequently, so the slowness of
| Poetry didn't matter that much to me, and I am not using
| the "one-off script" kind of approaches that uv enables
| (writing the dependencies in a comment in the script
| itself).
|
| So, yeah, uv is nice, but for me didn't fundamentally
| change that much.
| andrewl-hn wrote:
| Autocorrect messed up my last line, should say:
|
| uv seems like a great tool, but I remember thinking the
| same about pipenv, too.
| baq wrote:
| If you froze uv today it'll take years for anything to get to
| a state where the switch would be worth it.
| simonw wrote:
| uv is _very_ forkable - dual-licensed under Apache and MIT,
| high quality codebase, it 's Rust rather than Python but the
| Python community has an increasing amount of Rust experience
| these days.
|
| That's why I'm not personally too nervous about the strategic
| risk to the Python community of having such a significant
| piece of the ecosystem from a relatively young VC-backed
| company.
| whalesalad wrote:
| Our entire business runs on Python without a drop of Astral in
| the mix. No one would even notice.
| snapcaster wrote:
| you should try uv, really impressive tool
| pseudosavant wrote:
| Honestly, that is an understatement. `uv run` has
| transformed how I use Python since 99% of the time I don't
| need to setup or manage an environment and dependencies. A
| have tons of one-off Python scripts (with their
| dependencies in PEP 723 metadata at the top of the file)
| that just work with `uv run`.
|
| I get how it might not be as useful in a production
| deployment where the system/container will be setup just
| for that Python service, but for less structured use-cases,
| `uv` is a silver bullet.
| Philpax wrote:
| Finally, an event capable of killing the Python demon!
| thevillagechief wrote:
| I don't want to even think about it. uv has been a revelation!
| trollbridge wrote:
| #1, uv is open-source and it could easily be forked and kept up
| to date.
|
| #2, if you don't like uv, you can switch to something else.
|
| uv probably has the least moat around it of anything. Truly a
| meritocracy: people use it because it's good, not because
| they're stuck with it.
| pjmlp wrote:
| Never used any of their tools.
|
| Python is doing great, other than still doing baby steps into
| having a JIT in CPython.
| mrcwinn wrote:
| Congrats. This is the first time I remember reading a genuine,
| authentic story about a sale. Much preferred over "this is about
| continuing the mission until my earn-out is complete."
| jjordan wrote:
| I don't really see how Bun fits as an acquisition for an AI
| company. This seems more like "we have tons of capital and we
| want to buy something great" than "Bun is essential to our core
| business model".
| nurumaik wrote:
| Looks like they are acquiring the team rather than the product
| simonw wrote:
| No, they're clearly acquiring the technology. They're betting
| Claude Code on Bun, they have an invested interest in the
| health of Bun.
| LunaSea wrote:
| Why would they want to bet on nascent technology whereas
| Node.js bas existed for a god 15 years?
| stonogo wrote:
| Because Microsoft already owns that.
| Octoth0rpe wrote:
| Are you referring to node? MS doesn't own that. It's
| maintained by Joyent, who in turn is owned by Samsung.
| simonw wrote:
| Joyent handed Node.js over to a foundation in 2015, and
| that foundation merged into the JS Foundation to become
| the OpenJS Foundation in 2019.
|
| I'm not sure if Joyent have any significant role in
| Node.js maintenance any more.
| Octoth0rpe wrote:
| Oops, thank you :)
|
| regardless, it's certainly not MS.
| stonogo wrote:
| Microsoft owns npm outright and controls every aspect of
| the infrastructure that node.js relies on. It also sits
| on the board (and is one of the few platinum members) of
| the Linux Foundation, which controls openjs. It is
| certainly MS.
| jitl wrote:
| it starts fast and does better job than nodejs for their
| product
| simonw wrote:
| Because they needed something that could produce a single
| binary that works on every platform. They started
| shipping Claude Code with Bun back in July:
| https://x.com/jarredsumner/status/1943492457506697482
| LunaSea wrote:
| They could use the Node.js equivalent:
| https://nodejs.org/api/single-executable-
| applications.html#s...
| simonw wrote:
| They evidently evaluated Node.js in comparison to Bun
| (and Deno) earlier this year and came to a technical
| decision about which one worked best for their product.
| dvtkrlbs wrote:
| I highly doubt that the JS ecosystem is driven mostly by
| hype so I highly doubt the nodejs solution even put on a
| table in an internal issue tracker.
| simonw wrote:
| Claude Code shipped on top of Node.js for the first four
| months of its existence.
|
| Why wouldn't they consider their options for bundling
| that version into a single binary using Node.js tooling
| before adopting Bun?
| zstscrs wrote:
| Every time I see people mention things like this in node
| vs bun or deno conversations I wonder if they even tried
| them.
|
| >The single executable application feature currently only
| supports running a single embedded script using the
| CommonJS module system.
|
| >Users can include assets by adding a key-path dictionary
| to the configuration as the assets field. At build time,
| Node.js would read the assets from the specified paths
| and bundle them into the preparation blob. In the
| generated executable, users can retrieve the assets using
| the sea.getAsset() and sea.getAssetAsBlob() APIs.
|
| Meanwhile, here's all I need to do to get an exe out of
| my project right now with, assets and all:
|
| > bun build ./bin/start.ts --compile --outfile
| dist/myprogram.exe
|
| > [32ms] bundle 60 modules
|
| > [439ms] compile dist/myprogram.exe
|
| it detects my dynamic imports of jsons assets (language
| files, default configuration) and bundles them
| accordingly in the executable. I don't need a separate
| file to declare assets, declare imports, or do anything
| other than just run this command line. I don't need to
| look at the various bundlers and find one that works fine
| with my CLI tool and converts its ESM/TypeScript to CJS,
| Bun just knows what to do.
|
| Node is death through thousand cuts compared to the
| various experiences offered by Bun.
|
| Node adds quite the startup latency over Bun too and is
| just not too pleasant for making CLI scripts.
| heldrida wrote:
| I agree, they seem to have never tried it at all! Bun DX
| is the best, and Bun is the trend setter. Others are just
| catching up!
| LunaSea wrote:
| Yeah, just switch to a non-NPM compatible and inexistant
| ecosystem just because you need to specify a few
| parameters in a config.
|
| Anthropic is trying to IPO at a valuation of $300B so if
| their engineers nor their AI can be bothered to do this
| then maybe they're not as good as they think they are.
| giancarlostoro wrote:
| That was my thinking is, this would be useful for Claude
| Code.
| gkoberger wrote:
| If Anthropic wants to own code development in the future,
| owning the full platform (including the runtime) makes sense.
|
| Programming languages all are a balance between performance/etc
| and making it easy for a human to interact with. This balance
| is going to shit as AI writes more code (and I assume Anthropic
| wants a future where humans might not even see the code, but
| rather an abstraction of it... after all, all code we look at
| is an abstraction on some level).
| singularity2001 wrote:
| "the full platform"
|
| there are more languages than ts though?
|
| Acquisition of Apple Swift division incoming?
| tomashubelbauer wrote:
| TypeScript is the most popular programming language on the
| most popular software hosting platform though, owning the
| best runtime for that seems like it would fit Pareto's rule
| well enough:
|
| https://github.blog/news-insights/octoverse/octoverse-a-
| new-...
| bigyabai wrote:
| Why acquire Swift when you can write iOS apps in Typescript
| instead?
| giancarlostoro wrote:
| Which would use something like Bun ;)
| giancarlostoro wrote:
| According to a JetBrains dev survey (I forget the year)
| roughly 58% of devs deploy to the web. That's a big money
| pie right there.
| vlovich123 wrote:
| Bun isn't on the web. It's a server runtime.
| giancarlostoro wrote:
| It's a JS runtime, not specifically servers though? They
| essentially can bundle Claude Code with this, instead of
| ever relying on someone installing NodeJS and then
| running npm install.
|
| Claude will likely be bundled up nicely with Bun in the
| near future. I could see this being useful to let even a
| beginner use claude code.
|
| Edit:
|
| Lastly, what I meant originally is that most front-end
| work happens with tools like Node or Bun. At first I was
| thinking they could use it to speed up generating /
| pulling JS projects, but it seems more likely Claude Code
| and bun will have a separate project where they integrate
| both and make Claude Code take full advantage of Bun
| itself, and Bun will focus on tight coupling to ensure
| Claude Code is optimally running.
| vlovich123 wrote:
| Server here I used loosely - it obviously runs on any
| machine (eg if you wanted to deploy an application with
| it as a runtime). But it's not useful for web dev itself
| which was my point.
|
| Frontend work by definitions n doesn't happen with either
| Node nor Bun. Some frontend tooling might be using a JS
| runtime but the value add of that is minimal and a lot of
| JS tooling is actually being rewritten in Rust for
| performance anyway.
| rounce wrote:
| They could do that already, nothing in the license
| prohibited them from doing so.
| giancarlostoro wrote:
| Sure, but Bun was funded by VCs and needed to figure out
| how to monetize, what Anthropic did is ensure it is
| maintained and now they have fresh talent to improve
| Claude Code.
| gkoberger wrote:
| I think there's a potential argument to be made that
| Anthropic isn't trying to make it easier to write TS code,
| but rather that their goal is a level higher and the
| average person wouldn't even know what "language" is
| running it (in the same way most TS devs don't need to care
| the many layers their TS code is compiled via).
| Kwpolska wrote:
| They will own it, and then what? Will Claude Code end every
| response with "by the way, did you know that you can switch
| to bun for 21.37x faster builds?"
| BoorishBears wrote:
| They're baking the LORA as we speak, and it'll default to
| `bun install` too
| hobofan wrote:
| Even outside of code development, Anthropic seems to be very
| strongly leaning into code interpreter over native tool
| calling for advancing agentic LLM abilities (e.g. their
| "skills" approach). Given that those necessitate a runtime of
| sorts, owning/having access to a runtime like Bun that could
| e.g. allow them to very seamlessly integrate that
| functionality into their products better, this acquisition
| doesn't seem like the worst idea.
| BoorishBears wrote:
| It doesn't make sense, and you _definitely_ didn 't say why
| it'd make sense... but enough people are happy enough to see
| the Bun team reach an exit (especially one that doesn't kill
| Bun) that I think the narrative that it makes sense will win
| out.
|
| I see it as two hairy things canceling out: the accelerating
| trend of the JS ecosystem being hostage to VCs and Rauch is
| nonsensical, but this time a nonsensical acquisition is
| closing the loop as neatly as possible.
|
| (actually this reminds me of Harry giving Dobby a sock: on so
| many levels!)
| sankalpmukim wrote:
| Does this acquisition mean Claude Code the CLI is more valuable
| than entiriety of Bun?
| gehsty wrote:
| It certainly generated more revenue, so this is not
| surprising?
| re-thc wrote:
| > It certainly generated more revenue, so this is not
| surprising?
|
| Anything is greater than 0
| dangoodmanUT wrote:
| except for losing money?
| simonw wrote:
| Claude Code has an annual run rate of $1bn. Bun currently has
| an annual run rate of $0.
| throwaway290 wrote:
| No, just that people who borrowed bun 7 million dollars want
| some of it back...
| rvz wrote:
| It does actually.
|
| Claude Code is a 1B+ cash machine and Anthropic directly uses
| Bun for it.
|
| Acquiring Bun lowers the risk of the software being
| unmaintained as Bun made $0 and relied on VC money.
|
| Makes sense, but this is just another day in San Francisco of a
| $0 revenue startup being bought out.
| logsr wrote:
| Claude Code running on Bun is an obvious justification, but
| Buns features (high performance runtime, fast starts, native
| TS) are also important for training and inference. For
| instance, in inference you develop a logical model in code that
| maps to a reasoning sequence, and then execute the code to
| validate and refine the model, then use this to inform further
| reasoning. Bun, which is highly integrated and highly focused
| on performance, is an ideal fit for this. Having Bun in house
| means that you can use the feedback from all of automation
| driven execution of Bun to drive improvements to its core.
| myth_drannon wrote:
| First major success story for Zig language? (Not trying to
| diminish Bun's team success)
| Uninen wrote:
| I'd say Ghostty is a pretty big success story as well.
| Cieric wrote:
| Let's not forget about TigerBeetle either. They weren't
| bought (as far as I'm aware), but they seem to have some
| pretty good backing from customers.
| sgt wrote:
| Are the benefits of Zig really that amazing compared to
| Rust that it's worth choosing Zig, which is not even at 1.0
| and seems to be constantly changing? Also, Zig is not
| memory safe the same way.
|
| That said, I can easily imagine that the developer
| experience is superior for Zig. More fun.
| smileson2 wrote:
| Makes sense, I had idea how else the investors would have made
| money on a javascript bundler/jsc frontend
| ymsodev wrote:
| This somewhat answers the question of "how on earth is a JS
| runtime company going to profit?"
| iyn wrote:
| Curious about the deal value/price -- any clues whether it was
| just to make existing investors even (so say up to $30M) or are
| we talking some multiple? But if it's a multiple, even 2x sounds
| a bit crazy.
| dustingetz wrote:
| i don't get it either - bun being the foundation of tons of AI
| tools is like a best possible outcome, what were they hoping
| for when they raised the money? Or is this just an admission of
| "hey, that was silly, we need to land this however we can"? Or
| do they share major investors and the therefore this is just a
| consolidation? (Edit: indeed, KP did indeed invest $100M in
| Anthropic this year. I'm also confused - article states Bun
| raised 26M but the KP seed round was 7, did they do the A too
| but unannounced? Notably, the seed was summer 2022 and chatgpt
| was Nov 30, so the world is different, did the hypothesis
| change?)
| jtokoph wrote:
| One option is that the current Bun shareholders didn't see a
| profitable future and didn't even care if they were made even
| and a return of the remaining cash was adequate.
|
| Another option is that this was an equity deal where Bun
| shareholders believe there is still a large multiple worth up
| potential upside in the current Anthropic valuation.
|
| Plus many other scenarios.
| moralestapia wrote:
| What?
|
| Why?
| tibbydudeza wrote:
| Reminds me of Atlassian buying an AI browser.
| heinekan wrote:
| I'm curious to what the acquisition price was. Bun said they've
| raised $26 million so I'm assuming the price tag has to be a lot
| higher than that for investors to agree to an acquisition.
| yanis_t wrote:
| I don't get it. Why would Anthropic need to own a JS runtime?
| simonw wrote:
| Because they have a product that makes $1bn+ a year that
| depends on having a good, stable, cross-platform JS runtime.
| LunaSea wrote:
| You're describing Node.js which has existed for the last 15
| years
| dboreham wrote:
| And is owned by Microsoft. The theory is that by symmetry
| Anthropic should own a node competitor.
| joestrouth1 wrote:
| Microsoft doesn't own node.
| krashidov wrote:
| I'm still confused. Why not just pour a ton of resources into
| it since it's open source. I guess dev mindshare? It is a
| great product
| simonw wrote:
| Pouring a ton of resources into an open source project that
| raised $26m in VC doesn't guarantee that the project will
| stick around. Acquiring it does.
| krashidov wrote:
| Buying Bun to ensure it sticks around doesn't pass the
| smell test unless they had very few months of runway left
| simonw wrote:
| Bun had four years of runway left.
| sneak wrote:
| That doesn't require or benefit from acquiring Bun. Node
| continues to exist and serve fine.
| altmanaltman wrote:
| but they are a company that burns billions every year in
| losses and this seems like a pretty random acquisition.
|
| Bun is the product that depends on providing that good,
| stable, cross-platform JS runtime and they were already doing
| a good job. Why would Anthropic's acquisition of them make
| them better at what they were already doing?
| NewsaHackO wrote:
| >but they are a company that burns billions every year in
| losses
|
| No they don't.
| altmanaltman wrote:
| > As discussed previously, OpenAI lost $5 billion and
| Anthropic $5.3 billion in 2024, with OpenAI expecting to
| lose upwards of $8 billion and Anthropic -- somehow --
| only losing $3 billion in 2025. I have severe doubts that
| these numbers are realistic, with OpenAI burning at least
| $3 billion in cash on salaries this year alone, and
| Anthropic somehow burning two billion dollars less on
| revenue that has, if you believe its leaks, increased
| 500% since the beginning of the year.
|
| https://www.wheresyoured.at/why-everybody-is-losing-
| money-on...
| NewsaHackO wrote:
| You may have posted the wrong link, because what you
| posted was not a source, but rather an amatuer blogger's
| oponion about what anthrotic's and OpenAI revenue and
| losses are. Do you have the correct link to actual
| evidence that Anthropic has losses in the billions?
| simonw wrote:
| > Why would Anthropic's acquisition of them make them
| better at what they were already doing?
|
| Because now the Bun team don't have to redirect their
| resources to implementing a sustainable business model.
| altmanaltman wrote:
| It's Anthropic, not Microsoft. They already had a runway
| of 4 years, and honestly, that is preferable to hitching
| their wagon to a volatile startup like Antropic.
| pzo wrote:
| Ok but node is even more stable and mature - compare node api
| parity in bun and also issue of bun vs node
| the_mitsuhiko wrote:
| But they are not using node any more?
| baq wrote:
| Why would Sun then Oracle own Java? Why would Microsoft own
| .net? Why would Apple own swift?
|
| IOW look where the puck is going.
| fprotthetarball wrote:
| I'm wondering if Bun would be a good embedded runtime for
| Claude to think in. If it does sandboxing, or if they can add
| sandboxing, then they can standardize on a language and runtime
| for Claude Code and Claude Desktop and bake it into training
| like they do with other agentic things like tool calls. It'd be
| too risky to do unless they owned the runtime.
| Tiberium wrote:
| As someone who have been using Deno for the last few years, is
| there anything that Bun does better? Bun seems to use a different
| runtime (JSC) which is less tested than V8, which makes me assume
| it might perform worse in real-world tasks (maybe not anymore?).
| The last time I checked Bun's source code, it was... quite messy
| and spaghetti-like, plus Zig doesn't really offer many safety
| features, so it's not that hard to write incorrect code. Zig does
| force some safety with ReleaseSafe IIRC, but it's still not the
| same as even modern C++, let alone Rust.
|
| I'll admit I'm somewhat biased against Bun, but I'm honestly
| interested in knowing why people prefer Bun over Deno.
| ecares wrote:
| It has wayyyyy better nodejs compatibility (day 1 goal)
| Tiberium wrote:
| As far as I know, modern Node compat in Deno is also quite
| great - I just import packages via 'npm:package' and they
| work, even install scripts work. Although I remember that in
| the past Deno's Node compat was worse, yes.
| 0x457 wrote:
| Pretty sure one of the Deno day 1 goals was to correct
| mistakes made during the early days of Node.js.
| TheFlyingFish wrote:
| I haven't used Deno, but I do use Bun purely as a replacement
| for npm. It does the hard-linking thing that seems to be
| increasingly common for package managers these days (i.e. it
| populates your local node_modules with a bunch of hard links to
| its systemwide cache), which makes it vastly quicker and more
| disk-efficient than npm for most usage.
|
| Even with a cold cache, `bun install` with a large-ish
| dependency graph is significantly faster than `npm install` in
| my experience.
|
| I don't know if Deno does that, but some googling for "deno
| install performance vs npm install" doesn't turn up much, so I
| suspect not?
|
| As a runtime, though, I have no opinion. I did test it against
| Node, but for my use case (build tooling for web projects) it
| didn't make a noticeable difference, so I decided to stick with
| Node.
| homebrewer wrote:
| pnpm does all that on top of node. Also disables postinstall
| scripts by default, making the recent security incidents
| we've seen a non-issue.
| antihero wrote:
| I'm not sure why but bun still feels snappier.
| B56b wrote:
| This is why: https://bun.com/blog/behind-the-scenes-of-
| bun-install
| babyshake wrote:
| Aside from speed, what would the major selling points be
| on migrating from pnpm to bun?
| daheza wrote:
| Are there any popular packages that require postinstall
| scripts that this hurts?
| junon wrote:
| As the victim of the larger pre-Shai-Hulud attack,
| unfortunately the install script validation wouldn't have
| protected you. Also, if you already have an infected
| package on the whitelist, a new infection in the install
| script will still affect you.
| replete wrote:
| A whitelist in package.json is only a partial assist
| satvikpendem wrote:
| Deno does all that. Hell, yarn does too, or pnpm as the
| sibling mentioned.
| FINDarkside wrote:
| Sure, but pnpm is very slow compared to bun.
| agumonkey wrote:
| IIRC bun zig code base has a lot of fine optimization too. I
| think the lead did a conference explaining his work. Or maybe
| i'm confused.
| dolmen wrote:
| https://bun.com/blog/behind-the-scenes-of-bun-install
| agumonkey wrote:
| oh thanks yes, i couldn't find it, i was already lost
| thinking it was a conference by andrew kelley .. thanks a
| lot
| WorldMaker wrote:
| Deno does that. It also refrains from keeping a local
| node_modules at all until/unless you explicitly ask it to for
| whatever compatibility reason. There are plugins to things
| like esbuild to use the Deno resolver and not need a
| node_modules at all (if you aren't also using the Deno-
| provided bundler for whatever reason such as it disappeared
| for a couple versions and is still marked "experimental").
| user34283 wrote:
| I decided to stick with Node in general. I don't see any
| compelling reason to change it.
|
| Faster install and less disk space due to hardlink? Not
| really all that important to me. Npm comes with a cache too,
| and I have the disk space. I don't need it to be faster.
|
| With the old-school setup I can easily manually edit
| something in node_modules to quickly test a change.
|
| No more node_modules? It was a cool idea when yarn 2
| initially implemented it, but at the end of the day I prefer
| things to just work rather than debug what is and isn't
| broken by the new resolver. At the time my DevOps team also
| wasn't too excited about me proposing to put the dependencies
| into git for the zero-install.
| cesarvarela wrote:
| I've found it to be at least twice as fast with practically no
| compat issues.
| smarnach wrote:
| Twice as fast at executing JavaScript? There's absolutely
| zero chance this is true. A JavaScript engine that's twice as
| fast as V8 in general doesn't exist. There may be 5 or 10
| percent difference, but nothing really meaningful.
| johnfn wrote:
| You might want to revise what you consider to be
| "absolutely zero chance". Bun has an insanely fast startup
| time, so it definitely can be true for small workloads. A
| classic example of this was on Bun's website for a while[1]
| - it was "Running 266 React SSR tests faster than Jest can
| print its version number".
|
| [1]: https://x.com/jarredsumner/status/1542824445810642946
| smarnach wrote:
| I only claimed there is absolutely zero chance that Bun
| is twice as fast at executing general JavaScript as Deno.
| The example doesn't give any insight into the relative
| speeds of Bun and Deno, as fast as I can tell.
| johnfn wrote:
| johnfn@mac ~ % time deno eval 'console.log("hello
| world")' hello world deno eval
| 'console.log("hello world")' 0.04s user 0.02s system 87%
| cpu 0.074 total johnfn@mac ~ % time bun -e
| 'console.log("hello world")' hello world
| bun -e 'console.log("hello world")' 0.01s user 0.00s
| system 84% cpu 0.013 total
|
| That's about 560% faster. Yes, it's a microbenchmark. But
| you said "absolutely zero chance", not "a very small
| chance".
| ukblewis wrote:
| It depends on what. Bun has some major optimisations.
| You'll have to read into them if you don't believe me. The
| graphs don't come from nowhere
| jasnell wrote:
| Keep in mind that it's not just a matter of comparing the
| JS engine. The runtime that is built around the engine can
| have a far greater impact on performance than the choice of
| v8 vs. JSC vs. anything else. In many microbenchmarks, Bun
| routinely outperforms Node.js and Deno in most tasks by a
| wide margin.
| smarnach wrote:
| The claim I responded to is that Bun is "at least twice
| as fast" as Deno. This sounds a lot more general than Bun
| being twice as fast in cherry-picked microbenchmarks. I
| wasn't able to find any benchmark that found meaningful
| differences between the two runtimes for real-world
| workloads. (Example: https://hackernoon.com/myth-vs-
| reality-real-world-runtime-pe...)
| Aeolun wrote:
| Real world benchmarks include database queries and http
| requests? That'd quickly obviate any differences between
| runtimes.
|
| Lol, yeah, this person is running a performance test on
| postgres, and attributing the times to JS frameworks.
| oscargrouch wrote:
| We are in the "system engineering territory" and as such it
| might have more to do with the way the runtime is designed
| and how the javascript native runtime does things than the
| compiler optimizations. You have to measure syscalls,
| memory access, cpu cache locality and a bunch of design
| decisions that in the end contribute a lot to the running
| time. So depending on the decisions taken, it can easily
| happen.
| FragenAntworten wrote:
| Easily bundling and serving frontend code from your backend
| code is very appealing: https://bun.com/docs/bundler/fullstack
|
| Despite the page title being "Fullstack dev server", it's also
| useful in production (Ctrl-F "Production Mode").
| gre wrote:
| I had memory leaks in bun and not in deno or node for the same
| code. ymmv
| kenhwang wrote:
| I always figured Bun was the "enterprise software" choice,
| where you'd want to use Bun tools and libraries for everything
| and not need to bring in much from the broader NPM library
| ecosystem.
|
| Deno seems like the better replacement for Node, but it'd still
| be at risk of NPM supply chain attacks which seems to be the
| greater concern for companies these days.
| skybrian wrote:
| If you want to download open source libraries to be used in
| your Bun project then they will come from npm, at least by
| default. [1].
|
| So it seems odd to say that Bun is less dependent on the npm
| library ecosystem.
|
| [1] It's possible to use jsr.io instead:
| https://jsr.io/docs/using-packages
| kenhwang wrote:
| Yes, both can pull in open source libraries and I can't
| imagine either dropping that ability. Though they do seem
| to have different eagerness and competency on Node
| compatibility and Bun seems better on that front.
|
| From a long term design philosophy prospective, Bun seems
| to want to have a sufficiently large core and standard
| library where you won't need to pull in much from the
| outside. Code written for Node will run on Bun, but code
| using Bun specific features won't run on Node. It's the
| "embrace, extend, ..." approach.
|
| Deno seems much more focused on tooling instead of
| expanding core JS, and seems to draws the line at
| integrations. The philosophy seems to be more along the
| lines of having the tools be better about security when
| pulling in libraries instead of replacing the need for
| libraries. Deno also has it's own standard library, but
| it's just a library and that library can run on Node.
| skybrian wrote:
| That's true of some parts of Deno's standard libraries,
| but major functionality like Deno.test and Deno.serve are
| Deno-specific API's.
|
| Here are the Bun API's:
|
| https://bun.com/docs/runtime/bun-apis
|
| Here are the Deno API's:
|
| https://docs.deno.com/api/deno/
| gr4vityWall wrote:
| > I'll admit I'm somewhat biased against Bun?
|
| Why? Genuine question, sorry if it was said/implied in your
| original message and I missed it.
| Tiberium wrote:
| Good question, hard to say, but I think it's mainly because
| of Zig. At its core Zig is marketed as a competitor to C, not
| C++/Rust/etc, which makes me think it's harder to write
| working code that won't leak or crash than in other
| languages. Zig embraces manual memory management as well.
| ecshafer wrote:
| Rust is more of a competitor to C++ than C. Manual memory
| management is sometimes really helpful and necessary. Zig
| has a lot of safety features.
| AndyKelley wrote:
| > At its core Zig is marketed as a competitor to C, not
| C++/Rust/etc
|
| What gives you this impression?
|
| I directly created Zig to replace C++. I used C++ before I
| wrote Zig. I wrote Zig originally in C++. I recently ported
| Chromaprint from C++ to Zig, with nice performance results.
| I constantly talk about how batching is superior to RAII.
|
| Everyone loves to parrot this "Zig is to C as Rust is to
| C++" nonsense. It's some kind of mind virus that spreads
| despite any factual basis.
|
| I don't mean to disparage you in particular, this is like
| the 1000th time I've seen this.
| Aeolun wrote:
| I got to love that the author of the thing can show up
| and say "Why?! I never said any of that!"
|
| A lot of stuff related to older languages is lost in the
| sands of time, but the same thing isn't true for current
| ones.
| troad wrote:
| You have pretty explicitly framed Zig as a C replacement
| yourself, e.g.:
| https://www.youtube.com/watch?v=Gv2I7qTux7g
|
| More broadly, I think the observation tends to get
| repeated because C and Zig share a certain elegance and
| simplicity (even if C's elegance has dated). C++ is many
| things, but it's hardly elegant or simple.
|
| I don't think anyone denies that Zig can be a C++
| replacement, but that's hardly unusual, so can many other
| languages (Rust, Swift, etc). What's noteworthy here is
| that Zig is almost unique in having the potential to be a
| genuine C replacement. To its (and your) great credit, I
| might add.
|
| >> At its core Zig is marketed as a competitor to C, not
| C++/Rust/etc, which makes me think it's harder to write
| working code that won't leak or crash than in other
| languages. Zig embraces manual memory management as well.
|
| @GP: This is not a great take. All four languages are
| oriented around manual memory management. C++ inherits
| all of the footguns of C, whereas Zig and Rust try to
| sand off the rough edges.
|
| Manual memory management is and will always remain
| necessary. The only reason someone writing JS scripts
| don't need to worry about managing their memory is
| because someone has already done that work for them.
| oscargrouch wrote:
| Well if anything take as a compliment. As a C, C++ (and
| some Rust) who lately is enjoying Zig, I think Zig is the
| only programming language positioned to convince system
| programming die hard C programmers to use another
| programming language with simplicity and power backed in.
|
| But completely agree. Its a perfect replacement for C++
| and I would say the natural spiritual successor of C.
|
| I gave up using Rust for new projects after seeing the
| limitations for the kind of software I like to write and
| have been using Zig instead as it gives me the freedom I
| need without all the over-complication that languages
| like C++ and Rust bring to the table.
|
| I think people should first experiment see for themselves
| and only then comment as I see a lot of misinformation
| and beliefs more based on marketing than reality.
|
| Thank you very much for your wonderful work!
| fn-mote wrote:
| I mean, they said they looked at the source code and thought
| it was gross, so there's a justification for their concern,
| at least.
| gr4vityWall wrote:
| That's fair, but the word 'biased' felt unusual to describe
| how they perceive the runtime.
| satvikpendem wrote:
| Search for pointer exceptions or core dumps on Bun's GitHub
| issues and you'll see why people (should) use Deno over Bun, if
| only because Rust is a way more safe language than Zig.
| reactordev wrote:
| This is a non sequitur. Both Rust and Zig and any other
| language has the ability to end in an exception state.
| Whether it be kernel exception, pointer exception, or Rust's
| panic! - these things exist.
|
| The reason why you see so many GitHub issues about it is
| because that's where the development is. Deno is great. Bun
| is great. These two things can both be great and we don't
| have to choose sides. Deno has it's use case. Bun has it's.
| Deno want's to be secure and require permissions. Bun just
| wants to make clean, simple, projects. This fight between
| Rust vs The World is getting old. Rust isn't any "safer" when
| Deno can panic too.
| skipants wrote:
| I agree. Pointing at Github issues is a strange metric to
| me. If we want to use that as a canary then you shouldn't
| use Deno (2.4k open issues) or Bun (4.5k open issues) at
| all.
| satvikpendem wrote:
| Don't make a false equivalence, how many times does one get
| a panic from Deno versus a segmentation fault in Bun? It's
| not a similar number, and it's simply wrong to say that
| both are just as unsafe when that's plainly untrue.
| ricardobeat wrote:
| Anecodtally? Zero segfaults with bun since I started
| using it back in beta.
| reactordev wrote:
| The only time I got a segfault in Bun is when I used
| bun:ffi to wrap glfw and wgpu-native so I can threejs on
| the desktop. Ironically, the segfault was in wgpu. Which
| is Rust. But to be fair it was because the glfw surface
| had dirty flags for OpenGL and didn't have the Vulkan
| extensions. So anyone would have faulted.
| hu3 wrote:
| I use Bun in production. Well, one of my clients.
|
| We have yet to witness a segfault. Admitedly it's a bunch
| of micro services and not many requests/s (around 5k
| AVG).
| diarrhea wrote:
| > This is a non sequitur. Both Rust and Zig and any other
| language has the ability to end in an exception state.
|
| There are degrees to this though. A panic + unwind in Rust
| is clean and _safe_, thus preferable to segfaults.
|
| Java and Go are another similar example. Only in the latter
| can races on multi-word data structures lead to "arbitrary
| memory corruption" [1]. Even in those GC languages there's
| degrees to memory safety.
|
| 1: https://go.dev/ref/mem
| drannex wrote:
| I'll take a small panic and unwind any day over a total
| burnout crash. Matters in code and life.
| ignoramous wrote:
| > _A panic + unwind in Rust is clean and _safe_, thus
| preferable to segfaults_
|
| Curious about safety here: Are kernel / cross-thread
| resources (ex: a mutex/futex/fd) released on unwind
| (assuming the stack being unwound acquired those)?
| rvrb wrote:
| I haven't verified this, but I would be willing to bet that
| most of Bun's issues here have more to do with interfacing
| with JavaScriptCore through the C FFI than Zig itself. this
| is as much a problem in Rust as it is in Zig. in fact, it has
| been argued that writing unsafe Zig is safer than writing
| unsafe Rust: https://zackoverflow.dev/writing/unsafe-rust-vs-
| zig/
| polkchip2019 wrote:
| As someone who has researched the internals of Deno and
| Bun, your unverified vibe thoughts are flat out wrong. Bun
| is newer and buggier and that's just the way things go
| sometimes. You'll get over it.
| skybrian wrote:
| I've been using Deno too. Although npm support has improved and
| it's fine for me, I think Deno has more of a "rewrite the
| world" philosophy. For example, they created their own package
| registry [1] and their own web framework [2]. Bun seems much
| more focused on preexisting JavaScript projects.
|
| [1] https://jsr.io/ [2] https://fresh.deno.dev/
| Tiberium wrote:
| It's interesting that people have directly opposite opinions
| on whether Deno or Bun are meant to be used with the existing
| ecosystem - https://news.ycombinator.com/item?id=46125049
| hardwaregeek wrote:
| I don't think these are mutually exclusive takes. Bun is
| essentially taking Node and giving it a standard library
| and standard tooling. But you can still use regular node
| packages if you want. Whereas Deno def leaned into the
| clean break for a while
| bcye wrote:
| It just works. Whatever JavaScript/TypeScript file or
| dependencies I throw at it, it will run it without needing to
| figure out CJS or ESM, tsconfig, etc.
|
| I haven't had that experience with deno (or node)
| catapart wrote:
| Same. I had a little library I wrote to wrap indexedDB and
| deno wouldn't even compile it because it referenced those
| browser apis. I'm sure it's a simple flag or config file
| property, or x, or y, or z, but the simple fact is, bun
| didn't fail to compile.
|
| Between that and the discord, I have gotten the distinct
| impression that deno is for "server javascript" first, rather
| than just "javascript" first. Which is understandable, but
| not very catering to me, a frontend-first dev.
| bcye wrote:
| Even for server ~~java~~typescript, I almost always reach
| for Bun nowadays. Used to be because of typestripping,
| which node now has too, but it's very convenient to write a
| quick script, import libraries and not have to worry about
| what format they are in.
| pjmlp wrote:
| Agreed, the language would be interesting during the 1990's,
| nowadays not so much.
|
| The tools that the language offers to handle use after free is
| hardly any different from using Purify, Insure++ back in 2000.
| defen wrote:
| I find comments like this fascinating, because you're
| implicitly evaluating a counterfactual where Bun was built
| with Rust (or some other "interesting" language). Maybe Bun
| would be better if it were built in Rust. But maybe it would
| have been slower (either at runtime or development speed) and
| not gotten far enough along to be acquired by one of the
| hottest companies in the world. There's no way to know. Why
| did Anthropic choose Bun instead of Deno, if Deno is written
| in a better language?
| pjmlp wrote:
| Because maybe they reached out to them, and they didn't
| took the money, while Bun folks business model wasn't
| working out?
|
| Who knows?
|
| Besides, how are they going to get back the money spent on
| the acquisition?
|
| Many times the answer to acquisitions has nothing to do
| with technology.
| defen wrote:
| > Claude Code, FactoryAI, OpenCode, and others are all
| built with Bun.
|
| Anthropic chose to use Bun to build their tooling.
| pjmlp wrote:
| We can think of they making bun an internal tool, push
| roadmap items that fit their internal products, whatever,
| which doesn't answer the getting back money of the
| acquisition.
|
| Profit in those products has to justify having now their
| own compiler team for a JavaScript runtime.
| n42 wrote:
| Don't engage with this guy, he shows up in every one of
| these threads to pattern match back to his heyday without
| considering any of the nuance of what is actually different
| this time.
| pjmlp wrote:
| Look an admirer!
| Aeolun wrote:
| > Why did Anthropic choose Bun instead of Deno, if Deno is
| written in a better language?
|
| Something about moral and philosophical flexibility.
| silasdavis wrote:
| Stopped following Deno while they were rejecting the need for a
| package management solution. Used Bun instead.
| croes wrote:
| Isn't because packages are one of the problems deno tried to
| fix?
| WorldMaker wrote:
| They tried to realign package management with web standards
| and tools that browsers can share (URLs and importmaps and
| "cache, don't install"). They didn't offer compatibility
| with existing package managers (notably and notoriously
| npm) until late in that game and took multiple swings at
| URL-based package repositories (deno.land/x/ and JSR), with
| JSR eventually realizing it needed stronger npm
| compatibility.
|
| Bun did prioritize npm compatibility earlier.
|
| Today though there seems to be a lot of parity, and I think
| things like JSR and strong importmaps support start to
| weigh in Deno's favor.
| silasdavis wrote:
| Yeah it does look like things have moved on, but there
| were echoes from previous Go conversations around the
| idea of a standardised package and the attendant years of
| hurt that it turned me off a little while ago. I did try:
| https://github.com/denoland/deno/issues/4574#issuecomment
| -62...
| spiffytech wrote:
| I tried several times to port Node projects to Deno. Each time
| compatibility had "improved" but I still didn't have a working
| build after a few days of effort.
|
| I don't know how Deno is today. I switched to Bun and porting
| went a lot smoother.
|
| Philosophically, I like that Bun sees Node compatibility as an
| obvious top priority. Deno sees it as a grudging necessity
| after losing the fight to do things differently.
| fastball wrote:
| Which makes sense given that a big impetus for Deno's
| existence was the creator of Node/Deno (Ryan Dahl) wanting to
| correct things he viewed as design mistakes in Node.
| dmit wrote:
| > is there anything that Bun does better?
|
| Telling prospective employees that if you're not ready to work
| 60-hour weeks, then what the fuck are you doing here? for one.
|
| > Zig does force some safety with ReleaseSafe IIRC
|
| which Bun doesn't use, choosing to go with `ReleaseFast`
| instead.
| yieldcrv wrote:
| I've been using Bun since 2022 just to be trendy for
| recruitment (it worked, and still works despite it almost being
| 2026)
|
| Bun is fast, and its worked as a drop in replacement for npm in
| large legacy projects too.
|
| I only ever encountered one issue, which was pretty dumb,
| Amazon's CDK has hardcoded references to various package
| manager's lock files, and Bun wasn't one of them
|
| https://github.com/aws/aws-cdk/issues/31753
|
| This wasn't fixed till the end of 2024 and as you can see, only
| accidentally merged in but tolerated. It was promptly broken by
| a bun breaking change
|
| https://github.com/aws/aws-cdk/issues/33464
|
| but don't let Amazon's own incompetency be the confirmation
| bias you were looking for about using a different package
| manager in production
|
| you can use SST to deploy cloud resources on AWS and any cloud,
| and that package works with bun
| WorldMaker wrote:
| > Bun seems to use a different runtime (JSC) which is less
| tested than V8, which makes me assume it might perform worse in
| real-world tasks (maybe not anymore?).
|
| JSC is still the JS engine for WebKit-based browsers,
| especially Safari, and per Apple App Store regulations the only
| JS engine supposedly allowable in all of iOS.
|
| It's more "mature" than V8 in terms of predating it. (V8 was
| not a fork of it and was started from scratch, but V8 was
| designed to replace it in the Blink fork from WebKit.)
|
| It has different performance goals and performance
| characteristics, but "less tested" seems uncharitable and it is
| certainly used in plenty of "real-world tasks" daily in iOS and
| macOS.
| torginus wrote:
| Is it just me, but I don't find npm that slow? Sure it's not a
| speed demon, but I rarely need to do npm install anyways so
| it's not a bottleneck for me.
|
| For deploy, usually running the attached terraform script takes
| more time.
|
| So while a speed increase is welcome, but I don't feel it gives
| me such a boost.
| hinkley wrote:
| The speed shows up for large projects. Especially if you end
| up with multiple node_modules directories in your dev
| sandbox.
| dunham wrote:
| Is JSC less tested? I thought it was used in Safari, which has
| some market share.
|
| I used bun briefly to run the output of my compiler, because it
| was the only javascript runtime that did tail calls. But I
| eventually added a tail call transform to my compiler and
| switched to node, which runs 40% faster for my test case (the
| compiler building itself).
| kabirgoel wrote:
| My team has been using it in prod for about a year now. There
| were some minor bugs in the runtime's implementation of buffers
| in 1.22 (?), but that was about the only issue we ran into.
|
| The nice things:
|
| 1. It's fast.
|
| 2. The standard library is great. (This may be less of an
| advantage over Deno.)
|
| 3. There's a ton of momentum behind it.
|
| 4. It's closer to Node.js than Deno is, at least last I tried.
| There were a bunch of little Node <> Deno papercuts. For
| example, Deno wanted .ts extensions on all imports.
|
| 5. I don't have to think about JSR.
|
| The warts:
|
| 1. The package manager has some issues that make it hard for us
| to use. I've forgotten why now, but this in particular bit us
| in the ass: https://github.com/oven-sh/bun/issues/6608. We use
| PNPM and are very happy with it, even if it's not as fast as
| Bun's package manager.
|
| Overall, Deno felt to me like they were building a parallel
| ecosystem that I don't have a ton of conviction in, while Bun
| feels focused on meeting me where I am.
| creata wrote:
| Looking at Bun's website (the comparison table under "What's
| different about Bun?") and what people have said here, the only
| significant benefit of Bun over Node.js seems to be that it's
| more batteries-included - a bigger standard library, more
| tools, some convenience features like compiling JSX and
| stripping TypeScript types on-the-fly, etc.
|
| It's not clear to me why that requires creating a whole new
| runtime, or why they made the decisions they did, like choosing
| JSC instead of V8, or using a pre-1.0 language like Zig.
| bodge5000 wrote:
| I really want to like Deno and will likely try it again, but
| last time I did it was just a bit of a pain anytime I wanted to
| use something built for npm (which is most packages out there),
| whereas bun didn't have that problem.
|
| There's certainly an argument to be made that, like any good
| tool, you have to learn Deno and can't fall back on just
| reusing node knowledge, and I'd absolutely agree with that, but
| in that case I wanted to learn the package, not the package
| manager.
|
| Edit: Also it has a nice standard library, not a huge win
| because that stuff is also doable in Deno, but again, its just
| a bit less painless
| kamikazechaser wrote:
| At this stage I don't think either is better over the other.
| Deno has inexplicable high memory usage issues in Linux
| containers. Bun more or less suffers from the same with an
| added dose of segfaults.
|
| 1.
| https://github.com/denoland/deno/issues?q=is%3Aissue%20state...
| 2. https://github.com/oven-
| sh/bun/issues?q=is%3Aissue%20state%3...
|
| Node.js is a no-brainer for anyone shipping a TS/JS backend.
| I'd rather deal with poor DX and slightly worse performance
| than risk fighting runtime related issues on deployment.
|
| Linux needs to be a first class citizen for any
| runtime/langauge toolchain.
| Griffinsauce wrote:
| Crash. According to my experience trying it many times oves the
| past years.
|
| It feels like a very unfocused project, every few months they
| introduce a new feature that is to replace an entire class of
| tools, while the original promise of "drop in Node replacement"
| was never fulfilled (or at least, that was the vibe for the
| past years when I was still paying attention).
|
| We'll see how this works out but speed + lack of scope never
| works out well in the long term.
| kylecarbs wrote:
| Bun has completely changed my outlook on the JS ecosystem. Prior
| to Bun, there was little focus on performance. Now the entire
| space rallies around it.
|
| Congrats to Jarred and the team!
| nailer wrote:
| One important original point of node was that v8 made JS very
| fast by compiling to machine code, plus it's had multithreading
| built in for a decade.
| whizzter wrote:
| Machine code yes (along with Spidermonkey, JSC and Nashorn),
| the timeframe around 2005-2010 saw the introduction of JIT'ed
| JS runtimes. Back then however JS was firmly single-threaded,
| it was only with the introduction of SharedArrayBuffer that
| JS really started to receive multithreading features (outside
| of SharedArrayBuffer and other shareable/sendable types, a
| runtime could opt to run stuff like
| WebWorkers/WebAudioWorkers in separate processes).
|
| Early Node f.ex. had a multi-process setup built in, Node
| initially was about pushing the async-IO model together with
| a fast JS runtime.
|
| Why Bun (and partially Deno) exists is because TypeScript
| helps so damn much once projects gets a tad larger, but usage
| with Node hot-reloading was kinda slow, multiple seconds from
| saving a file until your application reloads. Even mainline
| node nowadays has direct .ts file loading and type erasing to
| quicken the workflow.
| stefan_ wrote:
| That is the most absurd thing I've heard in 20 years. Chrome
| literally was launched on performance, for JS and beyond.
|
| The reality is that the insane "JS ecosystem" will rally around
| whatever is the latest hotness.
| satvikpendem wrote:
| That's because it's not written in JS at all but a compiled
| systems language, no wonder it's gonna be fast.
| denismenace wrote:
| Virtually all JavaScript engines are written in compiled
| languages. (Most runtimes for that matter nut just JS)
| satvikpendem wrote:
| My mistake, I was thinking of the wider ecosystem not the
| runtime, ie formatters, bundles and linters like Biome,
| oxc, etc being written in Rust or other compiled languages.
| That's where I saw the biggest speedup, because developers
| of them decided to use a compiled language to write them in
| instead of JS via a JS runtime where you'll inherently be
| limited by even a JIT language.
| krig wrote:
| > Prior to Bun, there was little focus on performance.
|
| This is just completely insane. We went through more than a
| decade of performance competition in the JS VM space, and the
| _only_ justification that Google had for creating V8 was
| performance.
|
| > The V8 engine was first introduced by Google in 2008,
| coinciding with the launch of the Google Chrome web browser. At
| the time, web applications were becoming increasingly complex,
| and there was a growing need for a faster, more efficient
| JavaScript engine. Google recognized this need and set out to
| create an engine that could significantly improve JavaScript
| performance.
|
| I guess this is the time we live in. Vibe-coded projects get
| bought by vibe-coded companies and are congratulated in vibe-
| coded comments.
| logsr wrote:
| > Vibe-coded projects get bought by vibe-coded companies
|
| this is so far from the truth. Bun, Zig, and uWebsockets are
| passion projects run by individuals with deep systems
| programming expertise. furthest thing from vibe coding
| imaginable.
|
| > a decade of performance competition in the JS VM space
|
| this was a rising tide that lifted all boats, including Node,
| but Node is built with much more of the system implemented in
| JS, so it is architecturally incapable of the kind of
| performance Bun/uWebsockets achieves.
| creata wrote:
| > Node is built with much more of the system implemented in
| JS, so it is architecturally incapable of the kind of
| performance Bun/uWebsockets achieves
|
| That sounds like an implementation difference, not an
| architectural difference. If they wanted to, what would
| prevent Node or a third party from implementing parts of
| the stdlib in a faster language?
| logsr wrote:
| uWebsockets, which is the foundation of the network and
| http server stack in Bun, as I understand it, is a
| compatible 3rd party extension to Node.js that gives it
| similar performance on HTTP implementation.
|
| The key architectural difference is that Node.js
| implements the HTTP stack and other low level libraries
| in JavaScript, which gives it memory safety guarantees
| provided by the v8 runtime, while Bun/uWebsockets are a
| zig/C++ implementation. for Node.js, which is focused on
| enterprise adoption, the lower performance JS approach
| better aligns with the security profile of their
| enterprise adoption target.
| krig wrote:
| > Bun, Zig, and uWebsockets are passion projects run by
| individuals with deep systems programming expertise.
| furthest thing from vibe coding imaginable.
|
| Sure, I definitely will not throw projects like Zig into
| that bucket, and I don't actually think Bun is vibe-coded.
| At least that _used_ to be true, we'll see I guess...
|
| Don't read a snarky comment so literally ;)
| Meneth wrote:
| From the article: "Over the last several months, the
| GitHub username with the most merged PRs in Bun's repo is
| now a Claude Code bot."
| tibbar wrote:
| This missed the mark - Bun optimized systems whose
| predecessors were often implemented as JS libraries with a
| high number of syscalls. V8 is super fast for web usecases
| but your typical webpack / react compiler as implemented in
| JS had tons of unnecessary bottlenecks.
| umanwizard wrote:
| > Prior to Bun, there was little focus on performance
|
| v8 is one of the most advanced JIT runtimes in the world. A lot
| of people have spent a lot of time focusing on its performance.
| renewiltord wrote:
| Hahaha congratulations. This is amazing. The most unlikely
| outcome for a devtools team. Fascinating stuff.
|
| This is promising for Astral et al who I really like but worried
| about their sustainability. It does point to being as close to
| the user as possible mattering.
| andrewl-hn wrote:
| I'll be honest, while I have my doubts about the match of
| interests and cohesion between an AI company and a JS runtime
| company I have to say this is the single best acquisition
| announcement blog post I've seen in 20 years or so.
|
| Very direct, very plain and detailed. They cover all the bases
| about the why, the how, and what to expect. I really appreciate
| it.
|
| Best of luck to the team and hopefully the new home will support
| them well.
| raw_anon_1111 wrote:
| But how is another company that is also VC backed and losing
| money providing stability for Bun?
|
| How long before we hear about "Our Amazing Journey"?
|
| On the other hand, I would rather see someone like Bun have a
| successful exit where the founders seem to have started out
| with a passion project, got funding, built something out they
| were excited about and then exit than yet another AI company by
| non technical founders who were built with the sole purpose of
| getting funding and then exit.
| simonw wrote:
| Anthropic may be losing money, but a company with $7bn
| revenue run rate (https://www.anthropic.com/news/statement-
| dario-amodei-americ...) is a whole lot healthier than a
| company with a revenue of 0.
| tyingq wrote:
| If I had the cash, I could sell dollar bills for 50 cents
| and do a $7b run rate :)
| simonw wrote:
| If that was genuinely happening here - Anthropic were
| selling inference for less than the power and data center
| costs needed to serve those tokens - it would indeed be a
| very bad sign for their health.
|
| I don't think they're doing that.
|
| Estimates I've seen have their inference margin at ~60% -
| there's one from Morgan Stanley in this article, for
| example: https://www.businessinsider.com/amazon-
| anthropic-billions-cl...
| hollerith wrote:
| The leaders of Anthropic, OpenAI and DeepMind all hope to
| create models that are _much_ more powerful than the ones
| they have now.
|
| A large portion of the many tens of billions of dollars
| they have at their disposal (OpenAI alone raised 40
| billion in April) is probably going toward this ambition
| --basically a huge science experiment. For example, when
| an AI lab offers an individual researcher a $250 million
| pay package, it can only be because they hope that the
| researcher can help them with something very ambitious:
| there's no need to pay that much for a single employee to
| help them reduce the costs of serving the paying
| customers they have now.
|
| The point is that you can be right that Anthropic is
| making money on the marginal new user of Claude, but
| Anthropic's investors might still get soaked if the huge
| science experiment does not bear fruit.
| JumpCrisscross wrote:
| > _their investors might still take a bath if the very-
| ambitious aspect of their operations do not bear fruit_
|
| Not really. If the technology stalls where it is, AI
| still have a sizable chunk of the dollars previously paid
| to coders, transcribers, translators and the like.
| bpavuk wrote:
| but those AI/ML researchers aka LLM optimization staff
| are not cheap. their salaries have skyrocketed, and some
| are being fought for like top-tier soccer stars and
| actors/actresses
| 1shooner wrote:
| >The bank's analysts then assumed Anthropic gross profit
| margins of 60%, and estimated that 75% of related costs
| are spent on AWS cloud services.
|
| Not estimate, assumption.
| simonw wrote:
| If Morgan Stanley are willing to stake their credibility
| on an assumption I'm going to take that assumption
| seriously.
| SiempreViernes wrote:
| Calling this unmotivated assumption an "estimate" is just
| plain lying though, regardless of the faith uou have in
| the source of the assumption.
| simonw wrote:
| I've seen a bunch of other estimates / claims of a %50-60
| margin for Anthropic on serving. This was just the first
| one I found a credible-looking link I could drop into
| this discussion.
|
| The best one is from the Information, but they're behind
| a paywall so not useful to link to.
| https://www.theinformation.com/articles/anthropic-
| projects-7...
| skywhopper wrote:
| This is pretty silly thing to say. Investment banks
| suffer zero reputational damage when their analysts get
| this sort of thing wrong. They don't even have to care
| about accuracy because there will never be a way to even
| check this number, if anyone even wanted to go back and
| rate their assumptions, which also never happens.
| simonw wrote:
| Fair enough. I was looking for a shortcut way of saying
| "I find this guess credible", see also:
| https://news.ycombinator.com/item?id=46126597
| copedetector wrote:
| Cope detected. Classification code: ANT
| robotresearcher wrote:
| Those are estimates. Notice they didn't assume 0% or a
| million %. They chose numbers that are a plausible
| approximation of the true unknown values, also known as
| an estimate.
| verdverm wrote:
| I've been wondering about this generally... Are the per-
| request API prices I'm paying at a profit or a loss? My
| billing would suggest they are not making a profit on the
| monthly fees (unless there are a bunch of enterprise
| accounts in group deals not being used, I am one of those
| I think)
| viscanti wrote:
| They had pretty drastic price cuts on Opus 4.5. It's
| possible they're now selling inference at a loss to gain
| market share, or at least that their margins are much
| lower. Dario claims that all their previous models were
| profitable (even after accounting for research costs),
| but it's unclear that there's a path to keeping their
| previous margins and expanding revenue as fast or faster
| than their costs (each model has been substantially more
| expensive than the previous model).
| simonw wrote:
| It wouldn't surprise me if they found ways to reduce the
| cost of serving Opus 4.5. All of the model vendors have
| been consistently finding new optimizations over the last
| few years.
| manmal wrote:
| I sure hope serving Opus 4.5 at the current cost is
| sustainable. It's the first model I can actually use for
| serious work.
| mgfist wrote:
| Surely you understand the bet Anthropic is making, and
| why it's a bit different than selling dollars at a
| discount
| myhf wrote:
| Because discounted dollar bills are still a tangible
| asset, but churning language models are intangible?
| beepbooptheory wrote:
| Maybe for those of us not-too-clever ones, what _is_ the
| bet? _Why_ is it different? Would be pretty great to have
| like a clear articulation of this!
| shwaj wrote:
| The bet, (I would have thought) obviously, is that AI
| will be a huge part of humanity's future, and that
| Anthropic will be able to get a big piece of that pie.
|
| This is (I would have thought) obviously different from
| selling dollars for $0.50, which is a plan with zero
| probability of profit.
|
| Edit: perhaps the question was meant to be about how Bun
| fits in? But the context of this sub-thread has veered to
| achieving a $7 billion revenue.
| beepbooptheory wrote:
| The question is/was about how they intend to obtain that
| big piece of pie, what that looks like.
| throwaway-0001 wrote:
| Do you know any translators? They all pretty much lost
| much of their clients.
|
| Devs can write at a very fast rate with ai.
| econ wrote:
| Machine translations are really good now. Early on I
| would translate the same sentence back and forwards while
| "engineering" the "prompt".
|
| You still need to check it or at least be aware it's a
| translation. The problem of extra puns remains.
|
| Wo Bu Hui Shuo Ren He Yu Yan ,Wo Fou Ren Yi Qie
| liuliu wrote:
| You are saying that you can raise $7b debt at double-
| digit interest rate. I am doubtful. While $7b is not a
| big number, the Madoff scam is only ~$70b in total over
| many years.
| tyingq wrote:
| No, I'm scamming myself. Halving my fortune because I
| believe karma will somehow repay me ten fold some time
| later.
| ineedasername wrote:
| _Somehow_? I 've been keeping an eye on my inbox, waiting
| to get a karma vesting plan from HN, for ages. What's
| this talk of _somehow_?
| robocat wrote:
| > the Madoff scam is only ~$70b in total
|
| Incorrect - that was the fraudulent NAV.
|
| An estimate for true cash inflow that was lost is about
| $20 billion (which is still an enormous number!)
| mritchie712 wrote:
| you have anthropic confused with something like lovable.
|
| anthropic's unit margins are fine, many lovable-like
| businesses are not.
| tyingq wrote:
| Or I'm just saying revenue numbers alone don't prove
| anything useful when you have deep pockets.
| weakfish wrote:
| Idk, I'm no business expert by any means, but I'm a hell of
| a lot more _scared_ by a company burning so much that's $7b
| is still losing
| indemnity wrote:
| I am fairly skeptical about many AI companies, but as
| someone else pointed out, Anthropic has 10x'ed their
| revenue for the past 3 years. 100m->1b->10b. While past
| performance no predictor of future results, their product
| is solid and to me looks like they have found PMF.
| Sephr wrote:
| They don't need revenue, they need a community. I don't
| know how this acquisition will affect that.
| rvnx wrote:
| Often it happens that VCs buy out companies from funds
| belonging to a fresh because the selling fund wants to show
| performance to their investors until "the big one", or move
| cash one from wealthy pocket to another one.
|
| "You buy me this, next time I save you on that", etc...
|
| "Raised $19 million Series A led by Khosla Ventures + $7
| million"
|
| "Today, Bun makes $0 in revenue."
|
| Everything is almost public domain (MIT) and can be forked
| without paying a single dollar.
|
| Questionable to claim that the technology is the real reason
| this was bought.
| raw_anon_1111 wrote:
| If it was an acquihire, still a lot less slimy than just
| offering the employees they care about a large compensation
| package and leaving the company behind as a husk like
| Amazon, Google and Microsoft have done recently.
| KK7NIL wrote:
| Is it? What's wrong with hiring talent for a higher
| salary?
|
| You have no responsibility for an unrelated company's
| operations; if that was important to them they could have
| paid their talent more.
| JumpCrisscross wrote:
| From the acquirer's perspective, you're right. (Bonus: it
| diminishes your _own_ employees' ability to leave and
| fundraise to compete with you.)
|
| From an ecosystem perspective, acquihires trash the
| funding landscape. And from the employees' perspective,
| as an investor, I'd see them being on an early founding
| team as a risk going forward. But that isn't relevant if
| the individual pay-off is big.
| KK7NIL wrote:
| > And from the employees' perspective, as an investor,
| I'd see them being on an early founding team as a risk
| going forward.
|
| Every employee is a flight risk if you don't pay them a
| competitive salary; that's just FUD from VC bros who are
| getting their playbook (sell the company to the highest
| bidder and let early employees get screwed) used against
| them.
| JumpCrisscross wrote:
| > _Every employee is a flight risk if you don 't pay them
| a competitive salary_
|
| Not relevant to acquihires, who typically aren't hired
| away with promises of a salary but instead large signing
| bonuses, _et cetera_ , and aren't typically hired
| individually but as teams. (You can't solve key man
| problems with compensation alone, despite what every CEO
| compensation committee will lead one to think.)
|
| > _that 's just FUD_
|
| What does FUD mean in this context? I'm precisely
| relaying a personal anecdote.
| KK7NIL wrote:
| > aren't hired away with promises of a salary but instead
| large signing bonuses
|
| Now you're being nitpicky. Take the vesting period of the
| sign on bonus, divide the bonus amount by that and add it
| to the regular salary and you get the effective salary.
|
| > aren't typically hired individually but as teams.
|
| So? VC bros seem to forget the labor market is also a
| free market as soon it hurts their cashout opportunity.
|
| > What does FUD mean in this context? I'm precisely
| relaying a personal anecdote.
|
| Fear, Uncertainty and Doubt. Your anecdote is little more
| than a scare story. It can be summarized as: if you don't
| let us cashout this time, we'll hold this against you in
| some undefined future.
| JumpCrisscross wrote:
| > _Now you 're being nitpicky. Take the vesting period of
| the sign on bonus, divide the bonus amount by that and
| add it to the regular salary and you get the effective
| salary_
|
| These aren't the same things and nobody negotating and
| acquisition or acqhihire converts in this way. (I've done
| both.)
|
| > _Fear, Uncertainty and Doubt. Your anecdote is little
| more than a scare story. It can be summarized as: if you
| don 't let us cashout this time, we'll hold this against
| you in some undefined future_
|
| It's a personal anecdote. There shouldn't be any
| uncertainty about what I personally believe. I've
| literally negotiated acquihires. If you're getting a
| multimillion dollar payout, you shouldn't be particularly
| concerned about your standing in the next founding team
| unless you're a serial entrepreneur.
|
| Broader online comment, invoking FUD seems like shorthand
| for objecting to something without knowing (or wanting to
| say) why.
| raw_anon_1111 wrote:
| And the secretary, sales, project managers, etc who get
| left behind because the founders and key people were
| taken away? In an acquisition, they may still be let go.
| But they also would make money from their equity
| dlgeek wrote:
| You want those people specifically. To get them, you need
| to hire them for a lot more money than you pay your
| current folks. That causes a lot of resentment with folks
| and messes up things like salary bands, etc.
|
| But since they own equity in the current company, you can
| give them a ton of money by buying out that equity/paying
| acquisition bonuses that are conditional on staying for
| specific amounts of time, etc. And your current staff
| doesn't feel left out because "it's an acquisition" the
| way they would if you just paid some engineers 10x or
| 100x what you pay them.
| raw_anon_1111 wrote:
| I left out the part that the motivations for the
| acquirers were not to save money or to be slimy. It was
| the only way to get around overzealous government
| regulators making it harder to acquirer companies.
| raw_anon_1111 wrote:
| Who should be paying the founders more? The ones that
| made a deal with the VCs? They would be hired away from
| the company.
| skipants wrote:
| It's an acquihire. If Anthropic is spending significant
| resources, or see that they will have to, to improve Bun
| internally already it makes a lot of sense. No nefarious
| undertones required.
|
| An analogous example off the top of my head is Shopify
| hired Rafael Franca to work on Rails full-time.
| nathan-wall wrote:
| > But how is another company that is also VC backed and
| losing money providing stability for Bun?
|
| Reminds me of when Tron, the crypto company, bought
| BitTorrent.
| wmf wrote:
| The difference is that Tron is a scam and BitTorrent Inc
| was nothing special either.
| hamdingers wrote:
| Match made in heaven considering BitTorrent Inc bundles
| crypto miners and other malware with mTorrent.
| dhosek wrote:
| GIF of Pam from the office saying, "They're the same
| picture."
| lacker wrote:
| The real risk is not that Anthropic will run out of money,
| but that they will change their strategy to something that
| isn't Bun-based, and supporting Bun won't make sense for them
| any more.
| manmal wrote:
| Is there anything you'd need from bun in the future that
| can't be done by forking it?
| kelvinjps10 wrote:
| I misread Amazon, implying that Amazon might buy Anthropic,
| and I think that's what will end up happening.
| raw_anon_1111 wrote:
| In my three or four non chatbot related projects, I've
| found Amazon's Nova models to be just as good as
| Anthropic's.
| moritzwarhier wrote:
| Ditto, and I got to know Bun via HN. It seemed intriguing, but
| also "why another JS runtime" etc.
|
| If Bun embraces the sweet spot around edge computing, modern
| JS/TS and AI services, I think their future ahead looks bright.
|
| Bun seems more alive than Deno, FWIW.
| jjcm wrote:
| One thing I like about this, despite it meaning Bun will be
| funded, is Anthropic is a registered public benefit
| corporation. While this doesn't mean Anthropic _cant_ fuck over
| the users of Bun, it at least puts in some roadblocks. The path
| of least-resistance here should be to improve Bun for users,
| not to monetize it to the point where it 's no longer valuable.
| echelon wrote:
| > Anthropic is a registered public benefit corporation
|
| Does that mean _anything_ at all?
|
| OpenAI is a public benefit corporation.
| laserbeam wrote:
| I admit, it is a good acquisition announcement. I can't
| remember the last acquisition announcement that was kept for
| more than 1-2 years. Leadership changes, priorities shift...
| juddlyon wrote:
| I had the same impression: bottom line up front, didn't bury
| the lede, no weasel language.
| ctoth wrote:
| This decision is honestly very confusing to me as a constant user
| of Claude Code (I have 3 of them open at the moment.)
|
| So many of the issues with it seem to be because ... they wrote
| the damn thing in JavaScript?
|
| Claude is pretty good at a constrained task with tests --
| couldn't you just port it to a different language? With Claude?
|
| And then just ... the huge claude.json which gets written on
| every message, like ... SQLite exists! Please, please use it! The
| scrollback! The Keyboard handling! Just write a simple Rust or Go
| or whatever CLI app with an actual database and reasonable TUI
| toolkit? Why double down and buy a whole JavaScript runtime?
| mccoyb wrote:
| Boggles the mind.
| dboon wrote:
| Ink (and modern alternatives) probably _are_ the best TUI
| toolkit. If you want to write a UI that 's genuinely good, you
| need e.g. HTML, or some way to express divs and flex box. There
| isn't really another way to build professional grade UIs; I
| love immediate mode UI for games, but the breadth of features
| handled by the browser UI ecosystem is astonishing. It is a
| genuinely hard problem.
|
| And if you're expressing hierarchical UI, the best way to do it
| is HTML and CSS. It has the richest ecosystem, and it is one of
| the most mature technologies in existence. JS / TS are the
| native languages for those tools. Everything is informed by
| this.
|
| Of course, there are other options. You could jam HTML and CSS
| into (as you mention) Rust, or C, or whatever. But then the
| ecosystem is extremely lacking, and you're reinventing the
| wheel. You could use something simpler, like QML or handrolled.
| But then you lose the aforementioned breadth of features and
| compatibilities with all the browser code ever written.
|
| TypeScript is genuinely, for my money, the best option. The big
| problem is that the terminal backends aren't mature (as you
| said, scrollback, etc). But, given time and money, that'll get
| sorted out. It's much easier to fix the terminal stuff than to
| rewrite all of the browser.
| frumplestlatz wrote:
| The idea that you need or want HTML or CSS to write a TUI is
| missing the entire point of what made TUIs great in the first
| place. They were great precisely because they were clean,
| fast, simple, focused -- and didn't require an entire web
| stack to draw colored boxes.
| hiAndrewQuinn wrote:
| I'm not so sure about that. I've written some nontrivial
| TUIs in my time, the largest one being [1], and as the
| project got more complicated I did find myself often
| thinking "It sure would be nice if I could somehow just
| write this stuff with CSS instead of tiny state machines
| and control codes for coloration". There's no reason these
| languages couldn't compile down to a TUI as lean as hand-
| coloring everything yourself.
|
| [1]: https://taskusanakirja.com/
| frumplestlatz wrote:
| I'm certainly not advocating for a return to C + ncurses,
| but there's a wide ocean of options between that and
| HTML+CSS+JS in the terminal.
| dboon wrote:
| Yes, for simple projects, absolutely. But when you're
| shipping something as widely adopted as CC, I disagree.
| At the end of the day, you're making a UI. It happens to
| be rendered via the terminal. You still need
| accessibility, consistent layouts, easy integration with
| your backend services, inputs, forms, and so on. If you
| don't need that stuff, there are lots of other, simpler
| options. But if you do, your other options begin to
| resemble a half baked, bug filled reimplementation of the
| web. So just use the web.
| frumplestlatz wrote:
| I don't think you and I live on the same planet when it
| comes to engineering, but I'm used to that when it comes
| to folks who have spent their entire career in the web
| stack.
|
| The web is the half-baked, bug-filled reimplementation of
| the native application stack. We figured these problems
| out a long time ago, and the constant wheel re-invention
| from folks who only know and refuse to use anything but
| the web is getting old. I'm tired of everything you
| produce being slow, buggy, and consuming gigabytes of
| RAM.
| EMM_386 wrote:
| Ink seems to be the root cause of a major issue with the
| Claude Code CLI where it flickers horribly when it needs to
| repeatedly clear the screen and redraw.
|
| I don't know why it's even necessary for this.
|
| https://github.com/atxtechbro/test-ink-flickering
|
| Issue on Claude Code GitHub:
|
| https://github.com/anthropics/claude-code/issues/769
| morshu9001 wrote:
| I like JS for this use case, and React on web, but really not
| fond of the Ink usage. Idk if it's Ink itself or the way it
| gets used, but somehow people are making CLIs that lag and
| waste terminal space now.
| frumplestlatz wrote:
| I have to admit this was my first thought, too. I'm pretty
| obsessed with Claude Code, but the actual app is so incredibly
| poorly engineered for something that doesn't even do that much.
|
| Rust, Go, whatever -- writing a good TUI isn't that hard of a
| problem. Buying an entire VC funded JS runtime company isn't
| how you solve it.
| rprend wrote:
| "Port it to a different language" a language that's more out of
| distribution? Bad devex. Store data as an unreadable binary
| file? Bad devex.
|
| Stay in distribution and in the wave as much as possible.
|
| Good devex is all you need. Claude code team iterates and ships
| fast, and these decisions make total sense when you realize
| that dev velocity is the point.
| asim wrote:
| It's more honest than the Replicate answer but I think inevitably
| if you can't raise the next round and you get distracted by the
| shiny AI that this is the path taken by many teams. There is
| absolutely nothing wrong with that. There was an exuberant time
| when all the OSS things were getting funded, and now all AI
| things get funded. For many engineer founders, it's a better fit
| to go build deep technical stuff inside a bigger company. If I
| had that chance I would probably have taken it too. Good luck to
| the Bun team!
| copperroof wrote:
| Well this just created a lot of work for me. Everything's turning
| to shit at an alarming rate.
| kace91 wrote:
| >If most new code is going to be written, tested, and deployed by
| AI agents
|
| That perspective following "in two-three years" makes me shudder,
| honestly.
| mritchie712 wrote:
| > At the time of writing, Bun's monthly downloads grew 25% last
| month (October, 2025), passing 7.2 million monthly downloads. We
| had over 4 years of runway to figure out monetization. We didn't
| have to join Anthropic.
|
| I believe this completely. They didn't _have_ to join, which
| means they got a solid valuation.
|
| > Instead of putting our users & community through "Bun, the VC-
| backed startups tries to figure out monetization" - thanks to
| Anthropic, we can skip that chapter entirely and focus on
| building the best JavaScript tooling.
|
| I believe this a bit less. It'll be nice to not have some weird
| monetization shoved into bun, but their focus will likely shift a
| bit.
| drakythe wrote:
| Given the worries about LLM focused companies reaching
| profitability I have concerns that Bun's runway will be
| hijacked... I'd hate for them to go down with the ship when the
| bubble pops.
| Karrot_Kream wrote:
| This is my fear. It's one thing to lose a major sponsor. It's
| another to get cut due to a focus on profitability later down
| the line.
| someguyiguess wrote:
| At least Anthropic itself has the stated goal of creating
| ethical AI that benefits humanity. That's more than can be
| said for any other AI companies. Time will tell though.
| Google's motto used to be "don't be evil" and now it's
| basically the opposite.
| serial_dev wrote:
| > I believe this a bit less.
|
| They weren't acquired and got paid just to build tooling as
| before and now completely ignoring monetization until the end
| of times.
| velcrovan wrote:
| Maybe they were though. Maybe Anthropic just wanted to bring
| a key piece of the stack in-house.
| someguyiguess wrote:
| This is most likely the reason.
| ambicapter wrote:
| Good for them, could be bad for actual users.
| someguyiguess wrote:
| It's good for users of Claude though
| n2d4 wrote:
| > They didn't have to join, which means they got a solid
| valuation.
|
| This isn't really true. It's more about who _wanted_ them to
| join. Maybe it was Anthropic who really wanted to take over Bun
| /hire Jarred, or it was Jarred who got sick of Bun and wanted
| to work on AI.
|
| I don't really know any details about this acquisition, and I
| assume it's the former, but acquihires are also done for other
| reasons than "it was the only way".
| n2d4 wrote:
| Can't edit my comment anymore but Bun posted a pretty
| detailed explanation of their motivation here:
| https://bun.com/blog/bun-joins-anthropic
|
| Sounds like "monetizing Bun is a distraction, so we're
| letting a deep-pocketed buyer finance Bun moving forward".
| brabel wrote:
| Isn't Anthropic itself also burning investors money? I
| thought no AI company is making any profit.
| someguyiguess wrote:
| This is correct
| Karrot_Kream wrote:
| > They didn't have to join, which means they got a solid
| valuation.
|
| Did they? I see a $7MM seed round in 2022. Now to be clear
| that's a great seed round and it looks like they had plenty of
| traction. But it's unclear to me how they were going to
| monetize enough to justify their $7MM investment. If they
| continued with the consultancy model, they would need to pay
| back investors from contracts they negotiate with other
| companies, but this is a fraught way to get early cashflow
| going.
|
| Though if I'm not mistaken, Confluent did the same thing?
| robertjpayne wrote:
| They had a second round that was $19m in late 2023. I don't
| doubt for a second that they had a long runway given the
| small team.
| steve_adams_86 wrote:
| I don't like all of the decisions they made for the
| runtime, or some of the way they communicate over social
| media/company culture, but I do admire how well-run the
| operation seems to have been from the outside. They've done
| a lot with (relatively) little, which is refreshing in our
| industry. I don't doubt they had a long runway either.
| Karrot_Kream wrote:
| Thanks I scrolled past that in the announcement page.
|
| With more runway comes more investor expectations too
| though. Some of the concern with VC backed companies is
| whether the valuation remains worthwhile. $26mm in funding
| is plenty for 14 people, but again the question is whether
| they can justify their valuation.
|
| Regardless happy for the Oven folks and Bun has been a
| great experience (especially for someone who got on the JS
| ecosystem quite late.) I'm curious what the structure of
| the acquisition deal was like.
| baby wrote:
| I really don't understand why investors poured so much
| money into Bun, I guess they saw another potential Vercel
| play? An acquisition doesn't sound like a very good outcome
| for these investors, even by Anthropic, I would imagine
| someguyiguess wrote:
| Good thing they got acquired by a company that also has a
| snowballs chance in hell of ever paying back their investment
| papichulo2023 wrote:
| Anthropic is still a new company and so far they seem
| "friendly". That being said, I still feel this can go either
| way.
| VerifiedReports wrote:
| Yep. Remember when "Open"AI took a bunch of grant money and
| then turned for-profit?
|
| And kept their fraudulent name.
| someguyiguess wrote:
| That's kind of why Anthropic became a separate company in
| the first place though isn't it? Dario Amodei was former
| head of research at OpenAI and left along with 6 or 7
| others to form Anthropic.
| VerifiedReports wrote:
| Maybe! Sounds like you know a lot more about it than I
| do.
|
| I hope they won't be as douchey.
| ojosilva wrote:
| Yeah, now they are part of Anthropic, who haven't figured out
| monetization themselves. Shikes!
|
| I'm a user of Bun and an Anthropic customer. Claude Code is
| great and it's definitely where their models shine. Outside of
| that Anthropic sucks,their apps and web are complete crap,
| borderline unusable and the models are just meh. I get it, CC's
| head got probably a powerplay here given his department is
| towing the company and his secret sauce, according to marketing
| from Oven, was Bun. In fact VSCode's claude backend is
| distributed in bun-compiled binary exe, and the guy is featured
| on the front page of the Bun website since at least a week or
| so. So they bought the kid the toy he asked for.
|
| Anthropic needs urgently, instead, to acquire a good team
| behind a good chatbot and make something minimally decent. Then
| make their models work for everything else as well as they do
| with code.
| JimDabell wrote:
| > Yeah, now they are part of Anthropic, who haven't figured
| out monetization themselves.
|
| Anthropic are on track to reach $9BN in annualised revenue by
| the end of the year, and the six-month-old Claude Code
| already accounts for $1BN of that.
| Attrecomet wrote:
| Not sure if that counts as "figured out monetization" when
| no AI company is even close to being profitable -- being
| able to get some money for running far more expensive
| setups is not nothing, but also not success.
| JimDabell wrote:
| Monetisation is not profitability, it's just the
| existence of a revenue stream. If a startup says they are
| pre-monetisation it doesn't mean they are bringing in
| money but in the red, it means they haven't created any
| revenue streams yet.
| someguyiguess wrote:
| How is their Web app any different than any other AI? I feel
| like it's on par with all of them. It works great for me.
| Although I mostly use Claude code.
| nrhrjrjrjtntbt wrote:
| "We were maybe gonna fuck ya, buy now we promise we wont"
| gjvc wrote:
| apart from the unfortunate typo, this is accurate.
|
| like when a political leader says they have full faith in one
| of their ministers, you know said minister will be gone by
| next week.
| nrhrjrjrjtntbt wrote:
| lol. maybe more correct with the typo. if you buy you
| hopefully become the customer!
| a-dub wrote:
| they acquihired the team and derisked their investment in
| building claude code on top of bun. makes sense to me.
|
| moreover, now they can make investments in order to make it an an
| even more efficient and secure runtime for model workspaces.
| ptak wrote:
| What a trip. Love both, so all good I guess.
| mhitza wrote:
| This acquisition makes no sense.
|
| Investors must be happy because Bun never had to find out how to
| become profitable.
| baq wrote:
| It's enough Anthropic finds it profitable to run Claude Code on
| it.
| dboreham wrote:
| > This acquisition makes no sense.
|
| except this sense:
|
| > Investors must be happy because Bun never had to find out how
| to become profitable.
| odie5533 wrote:
| But what is the upside for anthropic?
| umanwizard wrote:
| Hard to say it makes no sense when you don't know how much they
| were acquired for. I would guess it is a trivial amount
| relative to Anthropic's war chest.
| zwnow wrote:
| Well not gonna use Bun anymore I guess
| jjice wrote:
| Why not?
| zwnow wrote:
| Because I avoid all major AI players with everything I got as
| all of them are thieves.
| jekrb wrote:
| ...you do know that YC has backed several AI companies,
| right?
| zwnow wrote:
| Does that make it a big AI player? I only read shit on
| here.
| rvz wrote:
| Did you donate money or time to Bun?
| zwnow wrote:
| Why would I
| rvz wrote:
| There you go.
|
| Thank you for showing exactly why acquisitions like this
| will continue to happen.
|
| If you don't support tools like Bun, don't be surprised
| to see them raise money from VCs and get bought out by
| large companies.
| zwnow wrote:
| I make 2k a month i dont have the financial freedom to
| support Javascript runtimes
| suralind wrote:
| Good luck, always worried about stuff like that because it
| happened so many times and the product got worse eventually. At
| the same time, ai understand how much effort went into building
| something like Bun and people need to fund their life's somehow,
| so there's that.
| beanjuiceII wrote:
| anthropic wont win, and will just get bought out by an ibm or
| oracle in the end...time to migrate from bun now
| mrweasel wrote:
| If Bun ends up at either IBM or Oracle, then it's a pretty safe
| platform, it could stay around for 50 years.
| focusgroup0 wrote:
| Congratulations to Jared. He and the team are Real Ziggers.
| Looking forward to a faster Claude Code!
| polskibus wrote:
| Wouldn't it make more sense to write the same functionality using
| a more performant, no-gc language? Aren't competitors praised for
| their CLIs being faster for that reason?
| munificent wrote:
| With AI tooling, we are in the era where rapid iteration on
| product matters more than optimal runtime performance. Given
| that, implementing your AI tooling in a language that maximizes
| engineer productivity makes sense, and I believe GC does that.
| logsr wrote:
| JS/TS has a fundamental advantage, because there is more open
| source JS/TS than any other language, so LLMs training on
| JS/TS have more to work with. Combine that with having the
| largest developer community, which means you have more people
| using LLMs to write JS/TS than any other language, and people
| use it more because it works better, then the advantage
| compounds as you retrain on usage data.
| timeon wrote:
| One would expect that "AI tooling" is there for rapid
| iteration and one can use it with performant languages. We
| already had "rapid iteration" with GC languages.
| munificent wrote:
| If "AI tooling" makes developers more productive regardless
| of language, then it's still more productive to use a more
| productive language. If JS is more productive than C++,
| then "N% more productive JS" is still more productive than
| "N% more productive C++", for all positive N.
| kurtis_reed wrote:
| Codex is written in Rust
| ximeng wrote:
| I use bun in a project but Claude Code always uses node to run
| throwaway scripts. Maybe they can persuade it to use bun as part
| of this acquisition?
| simlevesque wrote:
| I bet CC will become a binary with bun included and it'll use
| it's internal JS engine to run most scripts.
| runjake wrote:
| I always tell it to use Bun and it works? Am I
| misunderstanding?
| ximeng wrote:
| It seems the default is node (despite the project docs saying
| to use bun and all example script documentation using bun).
| It will use bun if told, but there's definitely nothing
| saying to use node and it uses that anyway.
| threetonesun wrote:
| Oddly I saw it try to use bun the other day, and was confused
| because everything in the project is in node.
| dzonga wrote:
| it boils down to - we didn't have full conviction that over the
| long run we will prove superior to node.js, however a.i company
| burning a lot of cash, has invested in us by basing their
| toolchain on us - so they have no option to acquire-hire us.
| hu3 wrote:
| quite the uncharitable take.
|
| On the opposite spectrum it's just that Claude and Bun are
| great technologies that joined forces.
| dboon wrote:
| Incredible news on so, so many levels!
|
| (1) Bun is what technical startups should be. Consistently
| excellent decisions, hyper focused on user experience, and a
| truly excellent technical product.
|
| (2) We live in a world where TUIs are causing billion dollar
| acquisitions. Think about that. Obviously, Bun itself is largely
| orthogonal to the TUIs. Just another use case. But also
| obviously, they wouldn't have been acquired like this without
| this use case.
|
| (3) There's been questions of whether startups like Bun can
| exist. How will they make money? When will they have to sell out
| one of the three principles in (1) to do so? The answer seems to
| be that they don't; at least, not like we expected, and in my
| opinion not in a sinister way.
|
| A sinister or corrupting sell out would be e.g. like Conan. What
| started as an excellent tool became a bloated, versioned mess as
| they were forced to implement features to support the corporate
| customers that sustained them.
|
| This feels different. Of course, there will be some selling out.
| But largely the interests of Anthropic seem aligned with "build
| the best JS runtime", since Anthropic themselves must be laser
| focused on user experience with Claude Code. And just look at
| Opencode [^1] if you want to see what leaning all the way into
| Bun gets you. Single file binary distribution, absurdly fast,
| gorgeous. Their backend, OpenTUI [^2], is a large part of this,
| and was built in close correspondence with the Bun folks. It's
| not something that could exist without Bun, in my opinion.
|
| (4) Anthropic could have certainly let Bun be a third party to
| which they contributed. They did not have to purchase them. But
| they did. There is a strange not-quite altruism in this; at
| worst, a casting off of the exploitation of open source we often
| see from the biggest companies. Things change; what seems almost
| altruistic now could be revealed to be sinister, or could morph
| into such. But for now, at least, it feels good and right.
|
| [^1]: https://github.com/sst/opencode [^2]:
| https://github.com/sst/opentui
| Simran-B wrote:
| Classic - brand new blog post:
|
| > We're hiring engineers.
|
| Careers page:
|
| > Sorry, no job openings at the moment.
| adpirz wrote:
| It's the Anthropic careers page that you're likely looking for
| now:
|
| https://www.anthropic.com/jobs?team=4050633008
| prathamtharwani wrote:
| Is it just me or does this page keep jumping back to the top
| when I try to scroll?
| noboostforyou wrote:
| It's doing that for me as well (desktop Safari).
| serial_dev wrote:
| Same on iOS. It was probably vibe coded.
| stack_framer wrote:
| It's doing it to me as well in Brave on macOS.
| antihero wrote:
| Maybe the engineers are Claude agents.
| fishmicrowaver wrote:
| My first thought went to how openai used Rust to build their CLI
| tool and Anthropic's CEO bought influence over Zig as a reaction.
| ivanjermakov wrote:
| > bought influence over Zig as a reaction
|
| Elaborate? I believe Zig's donors don't get any influence and
| decision making power.
| hu3 wrote:
| That would require them to hire/buy Zig team. Which is not the
| case.
| dkmar wrote:
| Jarred just tweeted a few days ago about how little influence
| over zig he has, funnily enough.
|
| https://x.com/jarredsumner/status/1994950394955665486?s=20
| sherbondy wrote:
| Congrats Jarred and team! You have saved humanity many hours
| already, and I'm sure with Anthropic's backing, you will spare us
| many more. Farewell would-be headaches from Node & NPM tooling
| and waiting for builds and tests and package updates. Exciting
| times ahead!
|
| Using bun on a side project reinvigorated my love of software
| development during a relatively dark time in my life, and part of
| me wonders if I would have taken the leap onto my current path if
| it weren't for the joy and feeling of speed that came from
| working with bun!
| giancarlostoro wrote:
| Sounds like the goal is to bundle up Bun with Claude Code
| insanely tightly, to the point where it doesn't matter if you
| have nodejs installed locally, but also they can optimize key
| things for Claude Code's Bun runtime as needed. It's a brilliant
| acquisition, and bun stays open source, which allows it to
| continue to grow, to Anthropics benefit and everyone else's.
| mpeg wrote:
| A nice start would probably be for Claude Code to stop trying
| to use npm when it detects a bun lockfile and vice versa...
| giancarlostoro wrote:
| Yeah Claude is very good, but it definitely needs to get
| "smarter" in some nuanced areas.
| christophilus wrote:
| I just ln bun to npm, npx, and node. This has the added
| benefit of letting ts_ls and various other tools work without
| requiring me to have both node and bun installed locally.
| mokarma wrote:
| Quote from the CEO of Anthropic in March 2025: "I think we'll be
| there in three to six months where AI is writing 90% of the code
| and then in 12 months we may be in a world where AI is writing
| essentially all of the code"
| WhyOhWhyQ wrote:
| I actually like claude code, but that was always a risky thing
| to say (actually I recall him saying their software is 90% AI
| produced) considering their cli tool is literally infested with
| bugs. (Or it least it was last time I used it heavily. Maybe
| they've improved it since.)
| johnfn wrote:
| AI writes about 90% of my code.
| smcleod wrote:
| Probably about 95% of mine now. Much better than I could for
| the most part.
| bopbopbop7 wrote:
| Weird, AI writes terrible code for me that would never pass
| a code review. I guess people have different standards for
| good code.
| sinatra wrote:
| Hah. It can't be "I need to spend more time to figure out
| how to use these tools better." It is always "I'm just
| smarter than other people and have a higher standard."
| smcleod wrote:
| Spot on.
| wry_discontent wrote:
| The tools produce mediocre, usually working in the most
| technical sense of the word, and most developers are
| pretty shit at writing code that doesn't suck (myself
| included).
|
| I think it's safe to say that people singularly focused
| on the business value of software are going to produce
| acceptable slop with AI.
| samdoesnothing wrote:
| Show us your repos.
| smcleod wrote:
| https://github.com/sammcj/mcp-devtools
| johnfn wrote:
| My stack is React/Express/Drizzle/Postgres/Node/Tailwind.
| It's built on Hetzner/AWS, which I terraformed with AI.
|
| It's a private repo, and I won't make it open source just
| to prove it was written with AI, but I'd be happy to
| share the prompts. You can also visit the site, if you'd
| like: https://chipscompo.com/
| smcleod wrote:
| I suspect you do not know how to use AI for writing code.
| No offence intended - it is a journey for everyone.
|
| You have to be setup with the right agentic coding tool,
| agent rules, agent tools (MCP servers), dynamic context
| acquisition and workflow (working with the agent operate
| from a plan rather than simple prompting and hoping for
| the best).
|
| But if you're lazy, don't put the effort in to understand
| what you're working with and how to approach it with an
| engineering mindset - you'll be be left on the outside
| complaining and telling people how it's all hype.
| brobdingnagians wrote:
| Do you know of any YouTube videos where you would say
| they do a very good job of showing off this style of
| coding?
| simonw wrote:
| I made this one recently:
| https://www.youtube.com/watch?v=qy4ci7AoF9Y - notes here:
| https://simonwillison.net/2025/Nov/6/upgrading-datasette-
| plu...
|
| My best writing on this topic is still this though (which
| doesn't include a video):
| https://simonwillison.net/2025/Mar/11/using-llms-for-
| code/
| smj-edison wrote:
| Thanks for this! I've been looking for a good guide to an
| LLM based workflow, but the modern style of YouTube
| coding videos really grates on me. I think I might even
| like this :D
| smcleod wrote:
| Always enjoy reading your blog Simon!
| brobdingnagians wrote:
| Thank you
| smcleod wrote:
| This one is a bit old now so a number of things have
| changed (I mostly use Claude Code now, Dynamic context
| (Skills) etc...) but here's a brief TLDR I did early this
| year https://www.youtube.com/watch?v=dDSLw-6vR4o
| the_overseer wrote:
| Always the same answer. It's the user not the AI being
| blown out of proportion. Tell me, where are all those
| great amazin applications that were coded 95-100% by AI?
| Where is the great progress the great new algorithms the
| great new innovations hiding?
| DaiPlusPlus wrote:
| Well, there was this:
| https://martin.janiczek.cz/2025/11/21/fawk-llms-can-
| write-a-...
| the_overseer wrote:
| From the link:
|
| "For now, I'll go dogfood my shiny new vibe-coded black
| box of a programming language on the Advent of Code
| problem (and as many of the 2025 puzzles as I can), and
| see what rough edges I can find. I expect them to be
| equal parts "not implemented yet" and "unexpected
| interactions of new PL features with the old ones".
|
| If you're willing to jump through some Python project
| dependency hoops, you can try to use FAWK too at your own
| risk, at Janiczek/fawk on GitHub."
|
| That doesn't sound like some great success. It mostly
| compiles and doesn't explode. Also I wouldn't call a toy
| "innovation" or "revolution".
| DaiPlusPlus wrote:
| I did take a look at the generated sources when I first
| saw the article and it seemed coherent and organised,
| though.
| johnfn wrote:
| My stack is React/Express/Drizzle/Postgres/Node/Tailwind.
| It's built on Hetzner/AWS, which I terraformed with AI.
| Probably 90-95% of it is AI driven.
|
| It's a private repo, and I won't make it open source just
| to prove it was written with AI, but I'd be happy to
| share the prompts. You can also visit the site, if you'd
| like: https://chipscompo.com/
| samdoesnothing wrote:
| Post a repo
| smcleod wrote:
| https://github.com/sammcj/mcp-devtools
| bopbopbop7 wrote:
| Your best example of something you made with AI is
| another AI code generator... definitely not beating the
| AI bubble allegations anytime soon.
| smcleod wrote:
| 1. I didn't say it was a best example, I replied to a
| comment asking me to "Post a repo" - I posted a repo. 2.
| Straw man argument. I was asked for a repo, I posted a
| repo and clearly you didn't look at the code as it's not
| an "AI code generator".
| bopbopbop7 wrote:
| 1. I didn't ask for a repo. 2. Still wasn't me. Maybe an
| AI agent can help you check usernames? 3. Sorry, a plugin
| for an AI code generator, which is even worse of an
| example.
| samdoesnothing wrote:
| How much time do you think you saved versus writing it
| yourself if you factored in the time you spent setting up
| your AI tooling, writing prompts, contexts etc?
| Aeolun wrote:
| https://github.com/Aeolun/cool-rust-terminal
|
| I was honestly baffled how fast Claude knocked this out.
| bopbopbop7 wrote:
| How many agents, tools, MCP & ACP servers, claude hooks,
| and workflows do I need to set up before English becomes
| a good programming language?
| smcleod wrote:
| One agent, a few sub-agents, 1 MCP server, no "ACP"
| (never seen that used), no hooks, one workflow that I
| usually follow.
| sulam wrote:
| Or maybe he's working in a space that is less out of
| distribution than the work you're doing?
| bopbopbop7 wrote:
| You're right, I'm not making a nextjs/shadcn/clerk/vercel
| ai wrapper startup.
| smcleod wrote:
| I don't remember saying I worked with nextjs, shadcn,
| clerk (I don't even know what that one is), vercel or
| even JS/TS so I'm not sure how you can be right but I
| should know better than to feed the trolls.
| pjmlp wrote:
| Only 10% to go for a full replacement.
| WesleyJohnson wrote:
| What languages and frameworks? What is the domain space
| you're operating in? I use Cursor to help with some tasks,
| but mainly only use the autocomplete. It's great; no
| complaints. I just don't ever see being able to turn over
| anywhere close to 90% with the stuff we work on.
| johnfn wrote:
| My stack is React/Express/Drizzle/Postgres/Node/Tailwind.
| It's built on Hetzner/AWS, which I terraformed with AI.
|
| You can see my site here, if you'd like:
| https://chipscompo.com/
| jsheard wrote:
| Maybe he was correct in the extremely literal sense of AI
| producing more new lines of code than humans, because AI is no
| doubt very good at producing huge volumes of Stuff very
| quickly, but how much of that Stuff actually justifies its
| existence is another question entirely.
| rsyring wrote:
| Do you have a source for the quote?
| rglover wrote:
| https://www.youtube.com/watch?v=9Shl1-ZJI6E
| jomohke wrote:
| Is this why everyone only seems to know the first half of
| Dario's quote? The guy in that video is commenting on a 40
| second clip from twitter, not the original interview.
|
| I posted a link and transcription of the rest of his "three
| to six months" quote here:
| https://news.ycombinator.com/item?id=46126784
| rsyring wrote:
| Thank you.
| mjr00 wrote:
| Why didn't they just use AI to write their own Bun instead of
| wasting 8-9 figures on this company? Makes no sense.
| fredoliveira wrote:
| "Wasting" is doing a lot of work in that sentence.
|
| They're effectively bringing on a team that's been focused on
| building a runtime for years. The models they could throw at
| the problem can't be tapped on the shoulder, and there's no
| guarantee they'd do a better job at building something like
| Bun.
| ok_dad wrote:
| Let me refer you back to the GP, where the CEO of Anthropic
| says AI will be writing most code in 12 months. I think the
| parent comment you replied to was being somewhat facetious.
| furyofantares wrote:
| From the article, Claude Code is being used extensively to
| develop Bun already.
|
| > Over the last several months, the GitHub username with the
| most merged PRs in Bun's repo is now a Claude Code bot. We
| have it set up in our internal Discord and we mostly use it
| to help fix bugs. It opens PRs with tests that fail in the
| earlier system-installed version of Bun before the fix and
| pass in the fixed debug build of Bun. It responds to review
| comments. It does the whole thing.
|
| You do still need people to make all the decisions about how
| Bun is developed, and to use Claude Code.
| mjr00 wrote:
| > You do still need people to make all the decisions about
| how Bun is developed, and to use Claude Code.
|
| Yeah but do you really need external hires to do that?
| Surely Anthropic has enough experienced JavaScript
| developers internally they could decide how their JS
| toolchain should work.
|
| Actually, this is thinking too small. There's no reason
| that each developer shouldn't be able to customize their
| own developer tools however they want. No need for any one
| individual to control this, just have devs use AI to spin
| up their own npm-compatible package management tooling
| locally. A good day one onboarding task!
| jomohke wrote:
| They likely have other things to do.
| delaminator wrote:
| Deciding what to Implement
|
| and
|
| Implementing the Decisions
|
| are complementary, one of these is being commoditised.
|
| And, in fact, decimated.
|
| Personally I am benefitting almost beyond measure because I
| can spend my time as the architect rather than the builder.
| solumunus wrote:
| Same. I don't understand how people aren't getting this
| yet. I'm spending all day thinking, planning and
| engineering while spending very little time typing code. My
| productivity is through the roof. All the code in my
| commits is of equal quality to what I would produce myself,
| why wouldn't it be? Sure one can just ask AI to do stuff
| and not review it and iterate, but why on earth would one
| do that? I'm starting to feel that anyone who's not getting
| this positive experience simply isn't good at development
| to begin with.
| postalrat wrote:
| Because 90% is not 100%.
| brobdingnagians wrote:
| I'm curious what people think of quotes like these. Obviously
| it makes an explicit, falsifiable prediction. That prediction
| is false. There are so many reasons why someone could predict
| that it would be false. Is it just optimistic marketing speech,
| or do they really believe it themselves?
| OkayPhysicist wrote:
| Everybody knows that marketing speech is optimistic. Which
| means if you give realistic estimates, then people are going
| to assume those are also optimistic.
| thesdev wrote:
| Why didn't they have the AI write a JS runtime instead of this
| acquisition?
| delaminator wrote:
| The big picture of "build a runtime" is an easier idea than
| "what would make this runtime better and how should the parts
| interact".
| somebodythere wrote:
| I think this wound up being close enough to true, it's just
| that it actually says less than what people assumed at the
| time.
|
| It's basically the Jevons paradox for code. The price of lines
| of code (in human engineer-hours) has decreased a lot, so there
| is a bunch of code that is now economically justifiable which
| wouldn't have been written before. For example, I can prompt
| several ad-hoc benchmarking scripts in 1-2 minutes to
| troubleshoot an issue which might have taken 10-20 minutes each
| by myself, allowing me to investigate many performance angles.
| Not everything gets committed to source control.
|
| Put another way, at least in my workflow and at my workplace,
| the volume of code has increased, and most of that increase
| comes from new code that would not have been written if not for
| AI, and a smaller portion is code that I would have written
| before AI but now let the AI write so I can focus on harder
| tasks. Of course, it's uneven penetration, AI helps more with
| tasks that are well-described in the training set (webapps,
| data science, Linux admin...) compared to e.g. issues arising
| from quirky internal architecture, Rust, etc.
| howdyhowdy123 wrote:
| That's ridiculous. Not it isn't even close.
| goosejuice wrote:
| At an individual level, I think it is for some people.
| Opus/Sonnet 4.5 can tackle pretty much any ticket I throw
| at it on a system I've worked on for nearly a decade.
| Struggles quite a bit with design, but I'm shit at that
| anyway.
|
| It's much faster for me to just start with an agent, and I
| often don't have to write a line of code. YMMV.
|
| Sonnet 3.7 wasn't quite at this level, but we are now. You
| still have to know what you're doing mind you and there's a
| lot of ceremony in tweaking workflows, much like it had
| been for editors. It's not much different than instructing
| juniors.
| rprend wrote:
| Accurate for me. Accurate for basically every startup from the
| past 12 months. Prob not for legacy codebases, though.
| jomohke wrote:
| Why do people always stop this quote at the breath? The rest of
| it says that he still thinks they need tech employees.
|
| > .... and in 12 months, we might be in a world where the ai is
| writing essentially all of the code. But the programmer still
| needs to specify what are the conditions of what you're doing.
| What is the overall design decision. How we collaborate with
| other code that has been written. How do we have some common
| sense with whether this is a secure design or an insecure
| design. So as long as there are these small pieces that a
| programmer has to do, then I think human productivity will
| actually be enhanced
|
| (He then said it would continue improving, but this was not in
| the 12 month prediction.)
|
| Source interview:
| https://www.youtube.com/live/esCSpbDPJik?si=kYt9oSD5bZxNE-Mn
| LauraMedia wrote:
| Given the horrible stability of Windows this year, it seems
| like Microsoft went all in on that
| solumunus wrote:
| It's writing 90% of my code now but it's 100% reliant on me to
| do that effectively.
| tolerance wrote:
| Shouts out to the fellow who half-broke the news in this
| submission that was presumably killed because of the aggressive
| paywall: https://news.ycombinator.com/item?id=46123627
|
| And apparently the submission's source for being the only org I
| can tell that anticipated this:
| https://www.theinformation.com/articles/anthropic-advanced-t...
| hedayet wrote:
| No strategic roadmap is ever going to tell you: "Build a
| $0-revenue JavaScript runtime and one day an AI company will
| acquire you"
| supportengineer wrote:
| Well, that was the playbook in the 1999-2001 dotcom days.
| Windchaser wrote:
| Which is probably why no one's going to recommend it these
| days
|
| ...but hey, things are different during a bubble.
| wmf wrote:
| Honestly that's probably the best play. Monetizing dev tools
| directly is a nightmare.
| reddalo wrote:
| And you risk ending up like Postman or Insomnia, once
| beautiful software which is now widely hated by developers.
| morkalork wrote:
| Countdown till Astral is acquired?
| ironmagma wrote:
| It reminds me of hearing that music majors often do well in
| medical school. Want to go to medical school? Just major in
| music, duh.
| OkayPhysicist wrote:
| Ha, Physics majors get the same talk about law school. It's
| just the selection bias of selecting for people willing to
| make hard pivots filtering out the under-achieving, go-with-
| the-flow types.
| westoque wrote:
| i really think this is part of the pitch deck for bun's
| funding. that a bigger company would acquire it for the
| technology. the only reason an AI company or any company for
| that matter would acquire it would be to:
|
| 1. acquire talent.
|
| 2. control the future roadmap of bun.
|
| i think it's really 1.
| mitchell_h wrote:
| I had the same thought when openai acquired rockset.
| pizlonator wrote:
| Lots of strategists will tell you something like: "Build
| something that's useful and then there will be money".
|
| That's 100% what happened to Bun. It's useful (like really
| useful) and now they're getting rewarded
| klysm wrote:
| This wasn't very high up on my list for acquisitions but props to
| the bun team for cashing in on the AI hype somehow!
| tolerance wrote:
| Who is expects Anthropic to migrate all their code to Codeberg.
| _pdp_ wrote:
| It makes total sense to me.
| NiloCK wrote:
| This morning I found myself muttering something I won't repeat as
| a reaction to Claude Code's remarkably slow startup time.
|
| Put the Bun folks directly on that please and nothing else.
| supportengineer wrote:
| Curious, how did he pay the bills when spending these years
| developing Bun?
| skybrian wrote:
| Bun was VC funded.
| supportengineer wrote:
| I thought it said he was building a voxel game in the
| browser?
| krig wrote:
| This announcement made me check in on the arbitrary code
| execution bug I reported that the Bun Claude bot created a PR for
| about 3 weeks ago:
|
| https://github.com/oven-sh/bun/pull/24578
|
| So far, someone from the bun team has left a bunch of comments
| like
|
| > Poor quality code
|
| ...and all the tests still seem to be failing. I looked through
| the code that the bot had generated and to me (who to be fair is
| not familiar with the bun codebase) it looks like total dogshit.
|
| But hey, maybe it'll get there eventually. I don't envy
| "taylordotfish" and the other bot-herders working at Oven though,
| and I hope they get a nice payout as part of this sale.
| bopbopbop7 wrote:
| So you pushed a PR that breaks a bunch of tests, added a 5
| layer nested if branch block that mixes concerns all over the
| place, then ignored the reviewer for three weeks, and you're
| surprised they didn't approve it?
| throwaway290 wrote:
| > So you pushed a PR that breaks a bunch of tests, added a 5
| layer nested if branch block that mixes concerns all over the
| place, then ignored the reviewer for three weeks, and you're
| surprised they didn't approve it?
|
| ...Did you miss the part where Bun used Claude to generate
| that PR?:)
| simonw wrote:
| I misinterpreted that first comment too. To clarify:
|
| 1. User krig reports an issue against the Bun repo:
| https://github.com/oven-sh/bun/issues/24548
|
| 2. Bun's own automated "bunbot" filed a PR with a potential
| fix: https://github.com/oven-sh/bun/pull/24578
|
| 3. taylordotfish (not an employee of Bun as far as I can
| tell, but quite an active contributor to their repo) left a
| code review pointing out many flaws:
| https://github.com/oven-
| sh/bun/pull/24578#pullrequestreview-...
| krig wrote:
| Right, this is accurate. Except I thought taylordotfish
| worked for bun, so I guess no one at bun has looked at it
| at all then.
| bopbopbop7 wrote:
| I did.
| Master_Odin wrote:
| The OP directly says:
|
| > that the Bun Claude bot created a PR for about 3 weeks ago
|
| The PR with bad code that's also been ignored was made by the
| bot that Bun made, and brags about in their acquisition post.
| krig wrote:
| I just reported the bug, it was the bot that was proudly
| mentioned in the announcement which created the PR and the
| code...
| hprotagonist wrote:
| So, we can anticipate that the new Anthropic browser will now
| have the interpreter Ken Thompson previewed for us 41-odd years
| ago?
| valbaca wrote:
| > If Bun breaks, Claude Code breaks. Anthropic has direct
| incentive to keep Bun excellent.
|
| and when this bubble pops down goes bun
| sgt wrote:
| Not really, we can just fork it?
| ChrisbyMe wrote:
| Interesting that this announcement is tied in with one for Claude
| Code revenue.
|
| Feels like maybe AI companies are starting to feel the questions
| on their capital spending? They wanna show that this is a
| responsible acquisition.
| TekMol wrote:
| What is the business model behind open source projects like bun?
| How can a company "aquire" it and why does it do that?
|
| In the article they write about the early days
| We raised a $7 million seed round
|
| Why do investors invest into people who build something that they
| give away for free?
| rglover wrote:
| Either for a modest return when it sells or as a tax write off
| when it fails.
| bcye wrote:
| VCs do not invest for a modest return.
| rglover wrote:
| No, but faced with either a loss or a modest return,
| they'll take the modest return (unless it's more beneficial
| to _not_ come tax season). Unicorns are called unicorns for
| a reason.
| bcye wrote:
| The question was why do investors _invest_
| ChrisbyMe wrote:
| I mean if you're getting X number of users per day and you
| don't need to pay for bandwidth or anything, there's gotta be
| SOME way to monetize down the line.
|
| If your userbase or the current CEO likes it or not.
| koakuma-chan wrote:
| Ads. Have you seen the dotenv JavaScript package?
| taylorlapeyre wrote:
| The post mentions why - Bun eventually wanted to provide some
| sort of cloud-hosting saas product.
| TekMol wrote:
| Everyone could offer a cloud-hosted saas product that
| involves bun, right?
|
| Why invest into a company that has the additional burden of
| developing bun, why not in a company that does only the
| hosting?
| simonw wrote:
| The standard argument here is that the maintainers of the
| core technology are likely to do a better job of hosting it
| because they have deeper understanding of how it all works.
|
| There's also the trick Deno has been trying, where they can
| use their control of the core open source project to build
| features that uniquely benefit their cloud hosting:
| https://til.simonwillison.net/deno/deno-kv#user-content-
| the-...
| simpsond wrote:
| Hosting is a commodity. Runtimes are too. In this case, the
| strategy is to make a better runtime, attract developers,
| and eventually give them a super easy way to run their
| project in the cloud. Eg: bun deploy, which is a reserved
| no op command. I really like Buns DX.
| morshu9001 wrote:
| Yep. This strategy can work, and it has also backfired
| before, like with Docker trying to monetize something
| they gave away for free.
| knowitnone3 wrote:
| Except Amazon would beat them to it
| Supercompressor wrote:
| Free now isn't free forever. If something has inherent value
| then folks will be willing to pay for it.
| aizk wrote:
| Well, if they suddenly changed the license, we'd get a new
| Redis --> Valkey situation. Or even more recently, look at
| minio no longer maintaining their core open source project!
| catapart wrote:
| oh well. it was cool while it lasted! I guess I'll figure out how
| to make deno do what I want, now.
| reactordev wrote:
| Bun is such a great runtime. If you haven't tried it, try it.
| It's got bells and whistles.
|
| This will make sure Bun is around for many, _many_ , years to
| come. Thanks Anthropic.
|
| Why Bun?
|
| Easy to setup and go. _bun run <something.ts>_
|
| Bells and whistles. (SQL, Router, SPA, JSX, Bundling, Binaries,
| Streams, Sockets, S3)
|
| Typescript Supported. (No need to tsc, bun can transpile for you)
|
| Binary builds. (single executables for easy deployment)
|
| Full Node.js Support. (The whole API)
|
| Full NPM Support. (All the packages)
|
| Native modules. (90% and getting better thanks to Zig's interop)
|
| S3 File / SQL Builtin. (Blazingly Fast!)
|
| You should try it. Yes, others do these things too, but we're
| talking about Bun.
| dawnerd wrote:
| > This will make sure Bun is around for many, many, years to
| come.
|
| Well, until the bubble bursts and Anthropic fizzles out or gets
| acquired themselves.
| reddalo wrote:
| ...and then it's going to be time for an "incredible journey"
| post.
| holysoles wrote:
| If they keep it MIT licensed, if/when things come crashing
| down, I think its reasonable to think Bun would continue on
| in some form, even if development slows pace without paid
| contributors.
| croes wrote:
| Does it have permission flags yet like deno has?
| johncolanduoni wrote:
| I've never understood the security utility of the Deno flags.
| What practical attack would they protect you from? Supply
| chain seems to be the idea, but how many npm packages do
| people use that neither:
|
| * Get run by devs with filesystem permissions
|
| * Get bundled into production
| mtoner23 wrote:
| It'll be around until they realize it makes 0$, and costs them
| millions per year in salaries/stock. then it will quietly die
| oheyadam wrote:
| You think they wouldn't have done that napkin math before
| deciding to acquire it?
| reactordev wrote:
| Anthropic uses a lot of bun. In fact, they bet the farm on
| it.
| tpetry wrote:
| Its not 100% nodejs compatible. I see enough non-green dots in
| their own official report https://bun.com/docs/runtime/nodejs-
| compat
|
| And even in packages with full support you can find many github
| issues that bun behaves directly which leads to some bugs.
| reactordev wrote:
| Not saying it's 100%, there's still the repl missing but all
| of node's API is available in the sense that it's ABI
| compatible (or will be very near term).
| everlier wrote:
| So many comments about reasoning here, yet none about the very
| obvious one, it's not stability of the infrastructure, it's
| future direction of a product like Claude Code. They need to know
| how to continue their optimisation machine to fit developers
| needs the best way possible (for good or for worse).
|
| I guess we should wait for some opt-out telemetry some time soon.
| It'll be nothing too crazy at first, but we'll see how hungry
| they are for the data.
| sulam wrote:
| Don't they already have a ton of telemetry from Claude Code
| itself? I'd be shocked and expect an instant fork if Anthropic
| telemetry was added to Bun.
| egorfine wrote:
| Well, Bun is MIT-licensed. So once they change the license and/or
| kill the project, the community can fork it easily.
| wmf wrote:
| The point of this deal is that they do not need to change the
| license. Nobody will ever pay for Bun and now they don't have
| to force it.
| egl2020 wrote:
| Can anyone provide some color around this: "I started porting
| esbuild's JSX & TypeScript transpiler from Go to Zig"?
| Hypothetical benefits include monolanguage for development,
| better interoperability with C and C++, no garbage collection,
| and better performance. What turned out to be realized and
| relevant here? Please, no speculation or language flames or wars.
| ryanvogel wrote:
| video covering it
|
| https://www.youtube.com/watch?v=6hEiUq8jWIg
| lkqjweflkj wrote:
| Not to be confused with Bunn [1], the coffee maker makers.
|
| [1] www.bunn.com
| clot27 wrote:
| deno won, rust won
| joewhale wrote:
| why couldn't Anthropic simply use Claude Code to write Bun over
| the weekend??
| Thrymr wrote:
| It is open source (MIT license), Claude should have a pretty
| good start on it already.
| jaredcwhite wrote:
| My long-term bet on Node being "boring" and "stable" continues to
| pay major dividends. So glad I never invested any time and effort
| on this ecosystem...
| pjmlp wrote:
| That is the way, when one is long time around, there are these
| alternatives coming and going, while the reference platforms
| keep going.
| fud101 wrote:
| must be nice to have a 1gb node_modules folder for hello world
| kelvinjps10 wrote:
| on the post they try to reassure the following question "If I bet
| my work project or company's tech stack on Bun, will it still be
| around in five or ten years?" and the thing is that we don't know
| if Anthropic itself will be around 5 to ten years
| threecheese wrote:
| Interesting. Looking through a strategic lens, I feel like this
| is related to the $1,000 free credit for Claude Code Web (I used
| a few hundred). What the heck are they aiming for? CodeAct?
| (https://arxiv.org/abs/2402.01030)
| zecheng wrote:
| So Anthropic sees its CLI (in TypeScript) as the first-class
| product and maybe planning to expand the claude code with more JS
| based agents / ecosystem? Especially owning the runtime gives a
| lot of control over developer experience.
| forrestthewoods wrote:
| Why the hell is a CLI coding agent built in JavaScript?
|
| It's wild what happens when a generation of programmers doesn't
| know anything except webdev. How far from grace we have fallen.
| simonw wrote:
| The big advantage of a language like JavaScript of Python for a
| CLI tool of this nature is that they naturally support adding
| extensions or plugins.
|
| That's quite a bit harder if your tool is built using a
| compiled language like Go.
| forrestthewoods wrote:
| Ehhhh. In either case you have to define a neat clean plugin
| API. Whether it loads a DLL/SO or just some scripts isn't
| that huge of a difference.
| gethly wrote:
| > I started porting esbuild's JSX & TypeScript transpiler from Go
| to Zig
|
| How was Go involved there before Zig?
| simonw wrote:
| esbuild is still a Go app today:
| https://github.com/evanw/esbuild
|
| The first hints of what become Bun were when Jared experimented
| at porting that to Zig.
| hinkley wrote:
| I wonder if this is a sign of AI companies trying to pivot?
|
| > Bun will ship faster.
|
| That'll last until FY 2027. This is an old lie that acquirers
| encourage the old owner to say because they have no power to
| enforce it, and they didn't actually say it so they're not on the
| hook. It's practically a cheesy pickup line, and given the
| context, it kinda is.
| matrixhelix wrote:
| This is why we can't have nice things
| hinkley wrote:
| I would like to clarify that I _wish_ I weren 't right but I
| probably am.
| unsungNovelty wrote:
| _" Insanity Is Doing the Same Thing Over and Over Again and
| Expecting Different Results"_
| hinkley wrote:
| Unfortunately that is also the definition of "practice".
| unsungNovelty wrote:
| Practice expects same results. Not different results?
| hinkley wrote:
| ... pardon?
|
| Are you confusing practice with rehearsal?
| christophilus wrote:
| I hate this quote. I often get different results when I do
| the same thing over and over again. Turns out there's a lot
| of on-determinism out there.
| fnands wrote:
| On your first point: It doesn't read like that to me. It seems
| like they built one of their key products (Claude Code) on top
| of Bun, and want to have a say in it's development.
| CuriouslyC wrote:
| I'm sure the Bun team will get Claude Code straightened out.
| Weird acquisition, but TBH Anthropic needed to fill this hole.
| Jarred wrote:
| I work on Bun.
|
| Happy to answer any questions
| linkage wrote:
| You said elsewhere that there were many suitors. What is the
| single most important thing about Anthropic that leads you to
| believe they will be dominant in the coming years?
| convenwis wrote:
| No idea about his feelings but believing that they will be
| dominant wouldn't have to be the reason he chose them. I
| could easily imagine that someone would decide based on (1)
| they offered enough money and (2) values alignment.
| elktown wrote:
| Is this acquihiring?
| simonw wrote:
| No. Anthropic need Bun to be healthy because they use it for
| Claude Code.
| elktown wrote:
| But it seems like that could happen faster internally than
| publicly?
| PetrBrzyBrzek wrote:
| I think it's an acquihire, and they also like Bun.
| gaws wrote:
| It's not an acqui-hire. Anthropic is keeping Bun.
| tshaddox wrote:
| Isn't that still "acqui-hiring" according to common usage
| of the term?
|
| Sometimes people use the term to mean that the buyer only
| wants some/all of the employees and will abandon or shut
| down the acquired company's product, which presumably isn't
| the case here.
|
| But more often I see "acqui-hire" used to refer to any
| acquisition where the expertise of the acquired company are
| the main reason to the acquisition (rather than, say, an
| existing revenue stream), and the buyer intends to keep the
| existing team dynamics.
| simonw wrote:
| Acquihiring usually means that the product the team are
| working on will be ended and the team members will be set
| to work on other aspects of the existing company.
| tshaddox wrote:
| That is part of the definition given in the first
| paragraph of the Wikipedia article, but I think it's a
| blurry line when the acquired company is essentially
| synonymous with a single open source project and the
| buyer wants the team of experts to continue developing
| that open source project.
| dcre wrote:
| No it isn't. That's not an acquihire. They're keeping the
| product.
| tshaddox wrote:
| The team is continuing to develop the open source project
| that was synonymous with the company, but they're
| explicitly no longer going to try to monetize it. I think
| that squarely counts as an acquihire according to common
| usage.
| alexandre_m wrote:
| I consider this more of a strategic acquisition.
| Skywalker13 wrote:
| Hi Jarred,
|
| I contributed to Bun one time for SQLite. I've a question about
| the licensing. Will each contributor continue to retain their
| copyright, or will a CLA be introduced?
|
| Thanks
| jasnell wrote:
| With Bun's existing OSS license and contribution model, all
| contributors retain their copyright and Bun retains the
| license to use those contributions. An acquisition of this
| kind cannot change the terms under which prior contributions
| were made without explicit agreement from all contributors.
| If Bun did switch to a CLA in the future, just like with any
| OSS project, that would only impact future contributions made
| after that CLA went into effect and it depends entirely on
| the terms established in that hypothetical CLA.
| Skywalker13 wrote:
| Hello, thank you, but that doesn't answer my question. I'm
| not asking for a definition, but for information about
| licensing decisions for the future of Bun.
| jannes wrote:
| Congrats on the payday :)
|
| Do you think Anthropic might request you implement private
| APIs?
| kyyol wrote:
| This is an interesting question; not to be too naive, but are
| there examples in the wild about this scenario? First I've
| heard of private APIs for something open source like this and
| my interest is piqued!
| aiiizzz wrote:
| Vscode had private apis for copilot.
| linkage wrote:
| How much of your day-to-day is spent contributing code to the
| Bun codebase and do you expect it to decrease as Anthropic
| assigns more people to work on Bun?
| msuniverse2026 wrote:
| Any thoughts on the claude "soul document" that was leaked this
| week?
| genshii wrote:
| Hi Jarred, thanks for all your work on Bun.
|
| I know that one thing you guys are working on or are at least
| aware of is the size of single-file executables. From a
| technical perspective, is there a path forward on this?
|
| I'm not familiar with Bun's internals, but in order to get the
| size down, it seems like you'd have to somehow split
| up/modularize Bun itself and potentially JavaScriptCore as well
| (not sure how big the latter is). That way only the things that
| are actually being used by the bundled code are included in the
| executable.
|
| Is this even possible? Is the difficulty on the Bun/Zig side of
| things, or JSC, or something else? Seems like a very
| interesting (and very difficult) technical problem.
| fishmicrowaver wrote:
| Yeah why are you not out on a boat somewhere enjoying this
| moment? Go have fun please.
| almosthere wrote:
| Acq's typically have additional stips you have to follow -
| they probably have new deadlines and some temporary stress
| for the next few months.
| tylergetsay wrote:
| yes, acquisitions rarely result in an immediate cash
| payout.
| brrrrrm wrote:
| on Bun's website, the runtime section features HTTP,
| networking, storage -- all are very web-focused. any plans to
| start expanding into native ML support? (e.g. GPUs, RDMA-type
| networking, cluster management, NFS)
| Jarred wrote:
| Probably not. When we add new APIs in Bun, we generally base
| the interface off of popular existing packages. The bar is
| very high for a runtime to include libraries because the
| expectation is to support those APIs ~forever. And I can't
| think of popular existing JS libraries for these things.
| atonse wrote:
| One more thing I hope doesn't change, is the fun Release videos
| :-) I really enjoy them. They're very apple-y, and for just a
| programming tool.
| losvedir wrote:
| I'm sort of surprised to see that you used Claude Code so much.
| I had a vague idea that "Zig people" were generally "Software
| You Can Love" or "Handmade Software Movement" types, about
| small programs, exquisitely hand-written, etc, etc. And I know
| Bun started with an extreme attention to detail around
| performance.
|
| I would have thought LLM-generated code would run a bit counter
| to both of those. I had sort of carved the world into "vibe
| coders" who care about the eventual product but don't care so
| much about the "craft" of code, and people who get joy out of
| the actual process of coding and designing beautiful
| abstractions and data structures and all that, which I didn't
| really think worked with LLM code.
|
| But I guess not, and this definitely causes me to update my
| understanding of what LLM-generated code can look like (in my
| day to day, I mostly see what I would consider as not very good
| code when it comes from an LLM).
|
| Would you say your usage of Claude Code was more "around the
| edges", doing things like writing tests and documentation and
| such? Or did it actually help in real, crunchy problems in the
| depths of low level Zig code?
| vector_spaces wrote:
| I am not your target with this question (I don't write Zig)
| but there is a spectrum of LLM usage for coding. It is
| possible to use LLMs extensively but almost never ship LLM
| generated code, except for tiny trivial functions. One can
| use them for ideation, quick research, or prototypes/starting
| places, and then build on that. That is how I use them,
| anyway
|
| Culturally I see pure vibe coders as intersecting more with
| entrepreneurfluencer types who are non-technical but trying
| to extend their capabilities. Most technical folks I know are
| fairly disillusioned with pure vibe coding, but that's my
| corner of the world, YMMV
| dijit wrote:
| fwiw, copilots licence only explicitly permits using its
| suggestions the way you say.
|
| putting everyone using the generated outputs into a sort of
| unofficial grey market: even when using first-party tools.
| Which is weird.
| lupire wrote:
| Can you link to more info about this?
| theshrike79 wrote:
| Might be related to the fact that AI generated content
| has no copyright by law.
|
| Nobody knows WHO has the copyright but it's been decided
| in courts that AI definitely doesn't own it.
| adventured wrote:
| I'll give you a basic example where it saved me a ton of
| time to vibe code instead of doing it myself, and I believe
| it would hold true for anyone.
|
| Creating ~50 different types of calculators in JavaScript.
| Gemini can bang out in seconds what would take me far
| longer (and it's reasonable at basic tailwind style front-
| end design to boot). A large amount of work smashed down to
| a couple of days of cumulative instruction + testing in my
| spare time. It takes far long to think of how I want
| something to function in this example than it does for
| Gemini to successfully produce it. This is a use case
| scenario where something like Gemini 3 is exceptionally
| capable, and far exceeds the capability requirements needed
| to produce a decent outcome.
|
| Do I want my next operating system vibe coded by Gemini 3?
| Of course not. Can it knock out front-end JavaScript tasks
| trivially? Yes, and far faster than any human could ever do
| it. Classic situation of using a tool for things it's
| particularly well suited.
|
| Here's another one. An SM-24 Geophone + Raspberry PI 5 +
| ADC board. Hey Gemini / GPT, I need to build bin files from
| the raw voltage figures + timestamps, then using flask I
| need a web viewer + conversion on the geophone velocity
| figures for displacement and acceleration. Properly
| instructed, they'll create a highly functional version of
| that with some adjustments/iteration in 15-30 minutes. I
| basically had them recreate REW RTA mode for my geophone
| velocity data, and there's no way a person could do it
| nearly as fast. It requires some checking and iteration,
| and that's assumed in the comparison.
| ohyoutravel wrote:
| Yeah I had OpenAI crank out 100 different fizzbuzz
| implementations in a dozen seconds---and many of them
| worked! No chance a developer would have done it that
| fast, and for anyone who needs to crank out fizzbuzz
| implementations at scale this is the tool to beat. The
| haters don't know what they're talking about.
| Aurornis wrote:
| > Culturally I see pure vibe coders as intersecting more
| with entrepreneurfluencer types who are non-technical but
| trying to extend their capabilities. Most technical folks I
| know are fairly disillusioned with pure vibe coding, but
| that's my corner of the world, YMMV
|
| Anyone who has spent time working with LLMs knows that the
| LinkedIn-style vibecoding where someone writes prompts and
| hits enter until they ship an app doesn't work.
|
| I've had some fun trying to coax different LLMs into
| writing usable small throwaway apps. It's hilarious in a
| way to the contrast between what an experienced developer
| sees coming out of LLMs and what the LinkedIn and Twitter
| influencers are saying. If you know what you're doing and
| you have enough patience you really can get an LLM to do a
| lot of the things you want, but it can require a lot of
| handholding, rejecting bad ideas, and reviewing.
|
| In my experience, the people pushing "vibecoding" content
| are influencers trying to ride the trend. They use the
| trend to gain more followers, sell courses, get the
| attention of a class of investors desperate to deploy cash,
| and other groups who want to believe vibecoding is magic.
|
| I also consider them a vocal minority, because I don't
| think they represent the majority of LLM users.
| theshrike79 wrote:
| Working with Agentic LLMs is exactly the same skillset as
| directing junior programmers or offshore consultants.
|
| You get a feel for how much direction they need after
| working for a while and tooling and accessible
| documentation is really important for quality.
|
| Then you give them a task and review the results. In
| (backend/systems) programming it's pretty binary whether
| a solution works or not, it's not a matter of taste but
| something you can just validate with hard data.
|
| I've done so many tiny/small/medium sized utilities for
| myself in the last year it's crazy[0]. A good bunch of
| them are 95-100% vibecoded, meaning I was just the
| "project manager" instructing what features I want and
| letting the agent(s) make it work.
|
| I think I have a pretty good feel for the main agentic
| systems and what they can do in the context of what I do
| so I know what to tell them and how - each has its own
| distinct way of working and using the wrong one for the
| wrong job is either stupid, frustrating or just a waste
| of time.
|
| [0] https://indieweb.org/make_what_you_need
| abnercoimbre wrote:
| Handmade Cities founder here.
|
| We never associated with Bun other than extending an
| invitation to rent a job booth at a conference: this was
| years ago when I had a Twitter account, so it's fair if
| Jarred doesn't remember.
|
| If Handmade Cities had the opportunity to collaborate with
| Bun today, we would not take it, even prior to this
| acquisition. HMC wants to _level up_ systems while remaining
| performant, snappy and buttery smooth. Notable examples
| include File Pilot [0] or my own Terminal Click (still early
| days) [1], both coming from bootstrapped indie devs.
|
| I'll finish with a quote from a blog post [2]:
|
| _> Serious Handmade projects, like my own Terminal Click,
| don't gain from AI. It does help at the margins: I've
| delegated website work since last year, and I enjoy seamless
| CI /CD for my builds. This is meaningful. However, it fails
| at novel problems and isn't practical for my systems
| programming work._
|
| All that said, I congratulate Bun even as we disagree on
| philosophy. I imagine it's no small feat getting acquired!
|
| [0] https://filepilot.tech
|
| [1] https://terminal.click
|
| [2] https://handmadecities.com/news/summer-update-2025/
| nimchimpsky wrote:
| back in my day we used to write code on punch cards.
| kopochameleon wrote:
| Finding this comment interesting, parent comment didn't
| suggest any past association but it seemingly uses project
| reference as pivot point to do various outgroup counter
| signaling / neg bun?
| abnercoimbre wrote:
| I understand the concern, but really? I found this quote
| enough to offer proper comments:
|
| _> had a vague idea that "Zig people" were generally
| "Software You Can Love" or "Handmade Software Movement"
| types_
|
| Folks at Bun are "Zig people" for obvious reasons, and a
| link was made with Handmade software. This happened
| multiple times before with Bun specifically, so my
| response is not a "pivot" of any kind. I've highlighted
| and constrasted our differences to prevent further
| associations inside a viral HN thread. That's not
| unreasonable.
|
| I also explicitly congratulated them for the acquisition.
| losvedir wrote:
| Indeed, you cleared up exactly the misconception I had.
| Thanks for chiming in to clarify
| tomnipotent wrote:
| > and a link was made with Handmade software
|
| I'm willing to wager that 99.99% of readers do not
| associate "Handmade" with the org you're associated with,
| and that most didn't know it existed until this comment.
| So yes "really", without OP replying, it's understandable
| that the poster you're replying inferred it had nothing
| to do with you.
| throw10920 wrote:
| Yeah, I don't think of Handmade Cities when I hear the
| word "handmade". I think of Handmade Network and Casey
| Muratori, who actually coined the term and started the
| movement. I didn't even _know_ about Handmade Cities
| before this comment, either. This is just shameless
| marketing /insertion on their part.
| vultour wrote:
| Nobody associates the word handmade with whatever you're
| talking about here. You hijacked a super common word and
| are now pretending it's related.
| kristianp wrote:
| I like that the filepilot download is 2.1MB. That really
| illustrates the difference between handmade style stuff and
| well, most other stuff.
| biofunsf wrote:
| I might missing some context. Just to check my
| understanding: HMC and Bun aren't a good match anymore
| because Bun devs use LLM/AI tooling more than HMC?
| Basically to really level up a system is incompatible these
| tools? (IYHO)
|
| Thank you! I appreciated how you wrote up this clarifying.
| jatins wrote:
| I think you may have confused parent commenter's "Handmade
| software movement" types comment to Handmade cities which
| doesn't seem related to me other than the common word
| handmade
| eps wrote:
| I'm pretty sure the GP was referring to
| https://handmade.network as their manifesto made multiple
| rounds here, was discussed at length and far more obviously
| related to "handmade movement" remark than your org.
| losvedir wrote:
| Yes, I was referring to Handmade Network, but check out
| who you're responding to[0]. Honestly, I wasn't too sure
| about the Handmade Cities thing, but I recognized his
| name as someone thick in the middle of my question, so I
| assumed it was a rebranding or something since I don't
| follow so closely.
|
| [0] https://handmade.network/m/abnercoimbre
| eps wrote:
| Yeah, I looked the GP up too, because I never heard of
| this Cities thing.
|
| I took your comment as referring to people who like to
| manually unroll their loops rather than members of some
| particular community, so GP's nitpicking on specifics of
| that interpretation looked out of place.
| Aurornis wrote:
| > I had a vague idea that "Zig people" were generally
| "Software You Can Love" or "Handmade Software Movement"
| types, about small programs, exquisitely hand-written, etc,
| etc.
|
| In my experience, the extreme anti-LLM people and extreme
| pro-vibecoding people are a vocal online minority.
|
| If you get away from the internet yelling match, the typical
| use case for LLMs is in the middle. Experienced developers
| use them for some small tasks and also write their own code.
| They know when to switch between modes and how to make the
| most of LLMs without deferring completely to their output.
|
| Most of all: They don't go around yelling about their LLM use
| (or anti-use) because they're not interesting in the online
| LLM wars. They just want to build things with the tools
| available.
| hiduck wrote:
| more people should have such a healthy approach not only to
| llms but to life in general. Same reason I partake less and
| less in online discourse: its so tribal and filled with
| anger that its just not worth it to contribute anymore.
| Learning how to be in the middle did wonders to me as a
| programmer and I think as a person as well.
| throwaway-0001 wrote:
| Personally I hate this "in the middle" as it's so
| relative you can shape to fit your narrative.
|
| For example: what's in the middle for programming?
|
| For me 0 is writing 0 and 1. For others 0 is making the
| nand ports.
|
| And 100 is ai llm vibe.
|
| So 50/middle would be what exactly? It all depends.
|
| Same for anything really. Some people I know keep saying
| not 8 not 80 to mean the middle.
|
| Like what's in the middle for amount of coding per day?
| 12 h? 8h? 2h?
|
| What's middle for making money? 50k, 500k, 500m?
|
| What's the middle for taking cyanide ? 1g? 1kg?
|
| What about water? What about food? What about anything?
|
| As you can see, it's all relative and whomever says it,
| is trying to push his narrative as "middle" aka correct,
| while who does more or less is "wrong".
| hiduck wrote:
| I think both me, and person before me, were commenting
| more about the fact that taking reserved approach is just
| healthier and prevents "shitstorms" in discussions that
| are non existent in current internet landscape. Without
| offending you, but creating a straw man scenario about
| how much cyanide one can take and getting angry at it is
| exactly what I had in mind; I just code, I want to code,
| sometimes use llm or stack overflow or ask another person
| for advice about code. The approach in the middle is not
| taking to the extremes, and making use of any available
| tools to do our work/hobby and just live life and not be
| a target of hate (I received hateful messages and even
| one death threat over a comment where I said that I asked
| Claude to explain some concept in Zig). I could go and
| say that "in the middle" is more of a metaphor to just
| being reserved about stuff but I would be probably called
| out for "moving goal posts" and "backtracking on own
| comment". Sorry if something is written weirdly, English
| is not my first language, I'm open to talk more tho.
| throwaway-0001 wrote:
| Maybe your "sometimes" is too much for me or others. How
| can you ensure it's in the "middle"? Maybe I consider
| extreme. Maybe others consider not enough. Like driving
| every day: is it extreme driving, or moderate?
|
| You see how makes no sense this in the "middle" concept?
| hiduck wrote:
| Then how should I call my approach? I definitely wouldn't
| portray myself as either pro or anti-llm: moderate?
| Moderate in the colloquial speech would also be not much
| more than trying to stay in the as you pointed out
| "relative" point of view. Unless you want to say that
| everyone is a bit of an extremist.
| throwaway-0001 wrote:
| Good question. I don't know either. Just I know "middle"
| is not the right thing. It's so easy to draw the
| narrative you wish - self fulfilling
| hiduck wrote:
| Well, then how would you describe your approach? If the
| the vague middle is not right thing for you?
| throwaway-0001 wrote:
| Better maybe fact based? I use ai X amount of hours per
| day. I use Ai for % of needs? My personal feeling of AI
| improvement in my life is +X%
|
| Something like that. What you think?
| hiduck wrote:
| Sounds good, but I'm scared that for some other people
| it's not an improvement since there will always be
| someone saying that X amount is too much or not enough.
| But yeah, I could say that 1/4 or 1/5 of coding (or
| rather, googling of stuff I simply don't know) I do is
| now delegated to an llm, question is if another person
| would look at this statement and say something along the
| lines of "cool, I use it more/less but I'm happy that it
| helped you/I'm sad that it caused you trouble", I slowly
| think that we might be discussing kind off the wrong
| thing. But yeah, numerical/fact based approach doesn't
| sound half bad even though I have some feeling at the
| back of my head that it can also be kind off self
| fulfilling but nonetheless it helps in conveying the
| message better than what I used before (the I use it a
| lot/not much/I try to stay in the middle).
| throwaway-0001 wrote:
| "I use the computer a lot" :
|
| For an average person: maybe means 8 hours.
|
| For a dev maybe means: 16 hours
|
| For a farmer: 2 hours.
|
| Who's right?
| epolanski wrote:
| You can hate it all you want but the world ain't black or
| white but a scale of greys. You're over focusing on which
| exact shade of grey one's talking, but it's indeed
| relative.
|
| > So 50/middle would be what exactly? It all depends.
|
| Using LLMs to explore code bases, doing deep research,
| asking it to do code reviews or find bugs, but not
| pushing code that LLMs have authored might be one example
| in the middle.
| varenc wrote:
| > What's the middle for taking cyanide ? 1g? 1kg?
|
| Cyanide has an LD50 (50% chance of death) in the 1-2
| mg/kg range when taken orally. So middle for taking
| cyanide is probably 1.5mg/kg. 90mg for someone 60kg.
|
| Sadly the middle ground in other topics is less easy to
| define!
| throwaway-0001 wrote:
| Yeah but what's the bottom and the top?
|
| Bottom is 0? Or is 1mg? Or what?
|
| Top is killing a human by dose? Killing an elephant dose?
| Make you feel dizzy?
|
| What's too much? What's being in the middle?
|
| You see, it's a stupid logic "in the middle". The point
| is being in the middle or moderate is not always "good".
|
| Also it's hard to define. Tbh only non logical people
| throw words like "in the middle" etc
| matwood wrote:
| Yep. And there's a lot of people making use of LLMs in both
| coding and learning/searching doing exactly that.
|
| One of my favorite things is describing a bug to an LLM and
| asking it to find possible causes. It's helped track
| something down many times, even if I ultimately coded the
| fix.
| LexiMax wrote:
| > I had a vague idea that "Zig people" were generally
| "Software You Can Love" or "Handmade Software Movement"
| types, about small programs, exquisitely hand-written, etc,
| etc.
|
| I feel like an important step for a language is when people
| outside of the mainline language culture start using it in
| anger. In that respect, Zig has very much "made it."
|
| That said, if I were to put on my cynical hat, I do wonder
| how much of that Anthropic money will be donated to the Zig
| Software Foundation itself. After all, throwing money at
| maintaining and promoting the language that powers a critical
| part of their infrastructure seems like a mutually beneficial
| arrangement.
| weird-eye-issue wrote:
| "exquisitely hand-written"
|
| This sounds so cringe. We are talking about computer code
| here lol
| mock-possum wrote:
| Bespoke handcrafted ethically sourced all natural cruelty
| free source code
| dgroshev wrote:
| I'm not sure about exquisite and small.
|
| Bun genuinely made me doubt my understanding of what good
| software engineering is. Just take a look at their code, here
| are a few examples:
|
| - this hand-rolled JS parser of 24k dense, memory-unsafe
| lines: https://github.com/oven-
| sh/bun/blob/c42539b0bf5c067e3d085646... (this is a version
| from quite a while ago to exclude LLM impact)
|
| - hand-rolled re-implementation of S3 directory listing that
| includes "parsing" XML via hard-coded substrings
| https://github.com/oven-
| sh/bun/blob/main/src/s3/list_objects...
|
| - MIME parsing https://github.com/oven-
| sh/bun/blob/main/src/http/MimeType.z...
|
| It goes completely contrary to a lot of what I think is good
| software engineering. There is very little reuse, everything
| is ad-hoc, NIH-heavy, verbose, seemingly fragile (there's a
| lot of memory manipulation interwoven with business logic!),
| with relatively few tests or assurances.
|
| And yet it works on many levels: as a piece of software, as a
| project, as a business. Therefore, how can it be anything but
| good engineering? It fulfils its purpose.
|
| I can also see why it's a very good fit for LLM-heavy
| workflows.
| smj-edison wrote:
| I can't speak as much about the last two examples, but
| writing a giant parser file is pretty common in Zig from
| what I've seen. Here's Zig's own parser, for example[1].
| I'm also not sure what you mean by memory unsafe, since all
| slices have bounds checks. It also looks like this uses an
| arena allocator, so lifetime tracking is pretty simple
| (dump everything onto the allocator, and copy over the
| result at the end). Granted, I could be misunderstanding
| the code, but that's the read I get of it.
|
| [1] https://codeberg.org/ziglang/zig/src/commit/be9649f4ea5
| a32fd...
| AndyKelley wrote:
| It used to be arena-allocated but now it's using a
| different technique which I outlined in this talk:
| https://vimeo.com/649009599
| dgroshev wrote:
| As it happens, the commit I linked fixes a segfault,
| which shouldn't normally happen in memory-safe code.
| dgellow wrote:
| I love zig, in my experience claude code is extremely good
| with the language if you invest lots of time on design
| sessions, to the point where I spend >90% of my time only
| discussing design with claude. The fact it has easy access to
| sources of the whole stdlib by just downloading the zig
| tarball makes it really simple to have a feedback loop where
| it implement most of the boilerplate on its own. The quality
| of AI code is really something that can be well controlled
| with clear guidelines, strict reviews, comprehensive design
| sessions, and a great test infrastructure
| thatSteveFan wrote:
| I interviewed for the Bun guys and totally flopped because I
| was not prepared for the interview format. It was "here's a
| task, do whatever you need to including AI to get it done".
| From that, I'd infer that the usage is pretty substantial.
| sktrdie wrote:
| I've never personally used Bun. I use node.js I guess. What
| makes Bun fundamentally better at AI than, say, bundling a
| node.js app that can run anywhere?
|
| If the answer is performance, how does Bun achieve things
| quicker than Node?
| postepowanieadm wrote:
| Easier deployment, you may generate a single binary.
| 420official wrote:
| Does this acquisition preclude implementing an s3 style
| integration for AWS bedrock? Also is IMDSv2 auth on the
| roadmap?
| rikafurude21 wrote:
| Any chance there will be some kind of updating mechanism for
| 'compiled' bun executables?
| Jarred wrote:
| I have a PR that's been sitting for awhile that exposes the
| extra options from the renameat2 and renameatx_np syscalls
| which is a good way to implement self-updaters that work even
| when multiple processes are updating the same path on disk at
| the same time. These syscalls are supported on Linux & macOS
| but I don't think there's an equivalent on Windows. We use
| these syscalls internally for `bun install` to make adding
| packages into the global install cache work when multiple
| `bun install` processes are running simultaneously
|
| No high-level self updater api is planned right now, but yes
| for at least the low level parts needed to make a good one
| asdfwaafsfw wrote:
| "work on Bun." LOL.
|
| Congratulations.
| stack_framer wrote:
| Are you at liberty to divulge how much Anthropic paid for Bun?
| urbandw311er wrote:
| Hi Jarred. Congratulations on the acquisition! Did (or will)
| your investors make any profit on what they put into Bun?
| tovazm wrote:
| Thanks, Jarred. Seeing what you built with Bun has been a real
| inspiration, the way one focused engineer can shift an entire
| ecosystem. It pushed me back into caring about the lower-level
| side of things again, and I'm grateful for that spark. Congrats
| on the acquisition, and excited to see what's next
| franciscop wrote:
| Amazing news, congrats! Been using Bun for a long while now and
| I love it.
|
| Is there anything I could do to improve this PR/get a review? I
| understand you are def very busy right now with the
| acquisition, but wanted to give my PR the best shot:
|
| https://github.com/oven-sh/bun/pull/24514
| djdjsjejb wrote:
| how the helldid you got that og name here in hn
|
| asking the real questions
| jrflowers wrote:
| What happens to Bun in a scenario where Anthropic goes under?
| hungryhobbit wrote:
| Why can't you make CLI autocompletions work? It's so basic, but
| the ticket has languished for almost as long as bun has
| existed!
| Aeolun wrote:
| Because nobody (including you, apparently) cares enough to
| implement it?
| Sincere6066 wrote:
| how can you sleep at night?
| gaws wrote:
| The money was too good to pass up.
| cdelsolar wrote:
| my wife and i call each other bun all the time, and it's really
| weird to see an article full of Buns
| baxuz wrote:
| What are your thoughts on using AI generated cartoons as your
| primary marketing material on social media? For instance
| https://xcancel.com/bunjavascript/status/1955893818529866055...
| PurpleRamen wrote:
| What happened to the voxel game that kickstarted the idea of
| bun? Was it ever finished? How much did it benefit from bun?
| gaws wrote:
| Are contributors getting cash or Anthropic equity as part of
| the acquisition?
| baby wrote:
| I love Bun and use it daily, but I'm still very frustrated by
| all the configuration that one needs ATM when working in the js
| ecosystem. Do you guys see yourself integrating more and more,
| and moving more and more towards a "convention over
| configuration", to bring a more streamlined dev experience
| (that languages like Golang and Rust have, for example)
| kristianp wrote:
| I'm confused. I installed claude code with: npm
| install -g @anthropic-ai/claude-code
|
| I thought claude code just used Nodejs? I didn't realise the
| recommended install used a different runtime.
| simonw wrote:
| They switched to recommending this as the installation method
| back in July: curl -fsSL
| https://claude.ai/install.sh | bash
|
| That install script gives you a single binary which is created
| using Bun.
| kristianp wrote:
| Maybe that's why I didn't have some bugs people were
| reporting on HN, or because I was using linux.
| elktown wrote:
| I've seen a few of these seemingly random acquisitions lately,
| and I congratulate the companies and individuals that are
| acquired during this gold rush, but it definitely feels awkwardly
| artificial.
| ChrisGreenHeur wrote:
| A single bun? Is that really newsworthy?
| saint_yossarian wrote:
| Oh you silly goose.
| stack_framer wrote:
| Anyone know how much Anthropic paid for Bun? I assume it was at
| least $26M, so Bun could break even and pay back its own
| investors, but I didn't see a number in the announcements from
| Anthropic or Bun.
| mudkipdev wrote:
| Claude said $187M
| intrepidsoldier wrote:
| In other news - Amp Code is a separate company now -
| https://ampcode.com/news/amp-inc
| bovermyer wrote:
| When I saw the headline I was ready to be mad, but after reading
| the post, I'm cautiously on board with this.
| bblaylock wrote:
| This reads more like Anthropic wanted to hire Jarred and Jarred
| wants to work with AI rather than build a Saas product around
| bun. I doubt it has anything to do with what is best for bun the
| project. Considering bun always seemed to value performance more
| than all else, the only real way for them to continue pursuing
| that value would be to move into the actual js engine design.
| This seems like a good pivot for Jarred personally and likely a
| loss for bun.
| thatoneengineer wrote:
| Nah, it reads like the normal logic behind the consulting model
| for open source monetization, except that Bun was able to make
| it work with just one customer. Good for them, though it comes
| with some risks, especially when structured as an acquisition.
| simonw wrote:
| It doesn't read like that to me at all. This reads to me like
| Anthropic realizing that they have $1bn in annual revenue from
| Claude Code that's dependent on Bun, and acquiring Bun is a
| great and comparatively cheap way to remove any risk from that
| dependency.
| Karrot_Kream wrote:
| I'm also curious if Anthropic was worried about the funding
| situation for Bun. The easiest way to allay any concerns
| about longevity is to just acquire them outright.
| _jab wrote:
| This argument doesn't make much sense to me. Claude Code,
| like any product, presumably has dozens of external
| dependencies. What's so special about Bun specifically that
| motivated an acquisition?
| almosthere wrote:
| If they found themselves pushing PRs to bun that got
| ignored and they wanted to speed up priority on things they
| needed, if the acq was cheap enough, this is the way to do
| it.
| cobolcomesback wrote:
| A dependency that forms the foundation of your build
| process, distribution mechanisms, and management of other
| dependencies is a materially different risk than a
| dependency that, say, colorizes terminal output.
|
| I'm doubtful that alone motivated an acquisition, it was
| surely a confluence of factors, but Bun is definitely a
| significant dependency for Claude Code.
| rvnx wrote:
| MIT code, let Bun continue develop it, once project is
| abandoned hire the developers.
|
| If they don't want to maintain; GitHub fork with more
| motivated people.
| cobolcomesback wrote:
| > MIT code, let Bun continue develop it, once project is
| abandoned hire the developers.
|
| Why go through the pain of letting it be abandoned and
| then hiring the developers anyway, when instead you can
| hire the developers now and prevent it from being
| abandoned in the first place (and get some influence in
| project priorities as well)?
| bblaylock wrote:
| I haven't had any issue moving projects between node, bun,
| and deno for years. I don't agree that the risk of bun
| failing as a company affects anthropic at all. Bun has a
| permissible license that anthropic could fork from, anthropic
| likely knew that oven had a long runway and isn't in
| immediate danger, and switching to a new js cli tool is not
| the huge lift most people think it is in 2025. Why pay for
| something you are already getting for free and can expect to
| keep getting for free for at least four years, and buy for
| less if it fails later?
| manojlds wrote:
| Really? What risk is even there?
| rco8786 wrote:
| Except bun is OSS, so they could have just forked if
| something happened
| square_usual wrote:
| It's not easy to "just" fork a huge project like Bun.
| You'll need to commit several devs to it, and they'll have
| to have Zig and JSC experience, a hard combo to hire for.
| In many ways, this is an acquihire.
| dts wrote:
| A lot of people seem confused about this acquisition because they
| think of Bun as a node.js compatible bundler / runtime and just
| compare it to Deno / npm. But I think its a really smart move if
| you think of where Bun has been pushing into lately which is a
| kind of cloud-native self contained runtime (S3 API, SQL,
| streaming, etc). For an agent like Claude Code this trajectory is
| really interesting as you are creating a runtime where your agent
| can work inside of cloud services as fluently as it currently
| does with a local filesystem. Claude will be able to leverage
| these capabilities to extend its reach across the cloud and add
| more value in enterprise use cases
| robertjpayne wrote:
| This is an insanely good take I never thought of.
| hoppp wrote:
| It's fine but why is Js a good language for agents? I mean sure
| its faster than python but wouldn't something that compiles to
| native be much better?
| chatmasta wrote:
| JS has the fastest, most robust and widely deployed
| sandboxing engines (V8, followed closely by JavaScriptCore
| which is what Bun uses). It also has TypeScript which pairs
| well with agentic coding loops, and compiles to the
| aforementioned JavaScript which can run pretty much anywhere.
| otterley wrote:
| Note that "sandboxing" in this case is strictly runtime
| sandboxing - it's basically like having a separate process
| per event loop (as if you ran separate Node processes). It
| does not sandbox the machine context in which it runs (i.e.
| it's not VM-level containment).
| Brass_Hopper wrote:
| When you say runtime sandboxing, are you referring to
| JavaScript agents? I haven't worked all that much with
| JavaScript execution environments outside of the browser
| so I'm not sure about what sandboxing mechanics are
| available.
| otterley wrote:
| https://nodejs.org/api/vm.html
|
| Bun claims this feature is for running untrusted code
| (https://bun.com/reference/node/vm), while Node says "The
| node:vm module is not a security mechanism. Do not use it
| to run untrusted code." I'm not sure whom to believe.
| Jarred wrote:
| The reference docs are auto generated from node's
| TypeScript types. node:vm is better than using the same
| global object to run untrusted code, but it's not really
| a sandbox
| Brass_Hopper wrote:
| It's interesting to see the difference in how both treat
| the module. It feels similar to a realm which makes me
| lean by default to not trusting it for untrusted code
| execution.
|
| It looks like Bun also supports Shadow Realms which from
| my understanding was more intended for sandboxing
| (although I have no idea how resources are shared between
| a host environment and Shadow Realms, and how that might
| potentially differ from the node VM module).
| sheepscreek wrote:
| Doesn't Bun use JavaScriptCore though? Perhaps their
| emulation, rather implementation, leans more towards
| security.
| Muromec wrote:
| Running it in a chroot or a scoped down namespace is all
| your need most of the time anyways.
| mrcsharp wrote:
| > It also has TypeScript which pairs well with agentic
| coding loops
|
| The language syntax has nothing to do with it pairing well
| with agentic coding loops.
|
| Considering how close Typescript and C# are syntactically,
| and C#'s speed advantage over JS among many other things
| would make C# the main language for building Agents. It is
| not and that's because the early SDKs were JS and Python.
| chamomeal wrote:
| Typescript is probably generally a good LLM language
| because - static types - tons and tons of training data
|
| Kind of tangent but I used to think static types were a
| must-have for LLM generated code. But the most magical
| and impressively awesome thing I've seen for LLM code
| generation is "calva backseat driver", a vscode extension
| that lets copilot evaluate clojure expressions and
| generally do REPL stuff.
|
| It can write MUCH cleaner and more capable code, using
| all sorts of libraries that it's unfamiliar with, because
| it can mess around and try stuff just like a human would.
| It's mind blowingly cool!!
| miguelspizza wrote:
| Clojure is such an underrated language for vibe coding
| for this very reason.
|
| Makes me wonder what a theoretical "best possible
| language for vibe coding" would look like
| justatdotin wrote:
| whoa, instant upgrade. thanks!
| wiseowise wrote:
| > C#'s speed advantage over JS among many other things
| would make C# the main language
|
| Nobody cares about this, JS is plenty fast for LLM needs.
| If maximum performance was necessary, you're better off
| using Go because of fast compiler and better performance.
| mrcsharp wrote:
| > Nobody cares about this
|
| And that was my point. The choice of using JS/TS for LLM
| stuff was made for us based on initial wave of SDK
| availabilities. Nothing to do with language merits.
| wrathofmonads wrote:
| This has always been the case. The Java and C# ecosystems
| prioritise stability and scale. They wait for ideas to
| prove themselves in other languages like Erlang, Python,
| Go, Scala, and so on, and then adopt the successful ones.
| Last-mover advantage. That said, there are some caveats.
| Java is still missing value types, while C# has moved
| quickly with async/await rather than adopting models like
| goroutines or virtual threads, which can sometimes limit
| concurrency ergonomics for the developer.
| mrsmrtss wrote:
| >If maximum performance was necessary, you're better off
| using Go because of fast compiler and better performance.
|
| That's not true, if anything, C# is faster and also
| compiles fast enough.
|
| https://benchmarksgame-
| team.pages.debian.net/benchmarksgame/...
| igouy wrote:
| C# AOT "compiles fast enough" compared to Go or are you
| looking at C# JIT ?
|
| https://benchmarksgame-
| team.pages.debian.net/benchmarksgame/...
| parentheses wrote:
| Not to mention the saturation of training data
| locknitpicker wrote:
| > It also has TypeScript which pairs well with agentic
| coding loops, (...)
|
| I've heard that TypeScript is pretty rough on agentic
| coding loops because the idiomatic static type assertion
| code ends up requiring huge amounts of context to handle in
| a meaningful way. Is there any truth to it?
| miguelspizza wrote:
| Not sure where you heard this but general sentiment is
| the opposite.
|
| There was recently a conference which was themed around
| the idea that typescript monorepos are the best way to
| build with AI
| locknitpicker wrote:
| > Not sure where you heard this but general sentiment is
| the opposite.
|
| My personal experience and anecdotal evidence is in line
| with this hypothesis. Using the likes of Microsoft's own
| Copilot with small simple greenfield TypeScript 5
| projects results in surprisingly poor results the minute
| you start leaning heavily on type safety and idiomatic
| techniques such as branded types.
|
| > There was recently a conference which was themed around
| the idea that typescript monorepos are the best way to
| build with AI
|
| There are also flat earth conferences.
| conartist6 wrote:
| It's especially tricky since monorepos are an obvious
| antipattern to begin with. They're a de-separation of
| concerns: an encouragement to blur the unit boundaries,
| not write docs, create unstable APIs (updating all usages
| at once when they change), and generally to let
| complexity spread unchecked.
| aizk wrote:
| I think this is contingent on the skill of the human
| reviewing the AI's code.
| AstroBen wrote:
| It's widespread and good enough. The language just doesn't
| matter that much in most cases
| moron4hire wrote:
| This is one of those, "in theory, there's no difference
| between theory and practice. In practice, there is" issues.
|
| In their, quality software can be written in any
| programming language.
|
| In practice, folks who use Python or JavaScript as their
| application programming language start from a position of
| just not carrying very much about correctness or
| performance. Folks who use languages like Java or C#, do.
| And you can see the downstream effects of this in the
| difference in the production-grade developer experience and
| the quality of packages on offer in PIP and NPM versus
| Maven and NuGet.
| AstroBen wrote:
| That's not a fair comparison. In your example, you're
| talking about the average of developers in a language. In
| this situation, it's specific developers choosing between
| languages. Having the developers you already have choose
| language A or B makes no difference to their code quality
| (assuming they're proficient with both)
| moron4hire wrote:
| These are statements these developers will make
| themselves. They will say they don't like more strictly
| typed languages because they feel constrained and slowed
| down in development. They will argue that the performance
| hit is worth the trade offs.
| drzaiusx11 wrote:
| As a developer that switches between java, python and
| typescript every day I think this is fairly myopic
| opinion. Being siloed to one lang for long enough tends
| to brings out our tribalistic tendencies, tread
| carefully.
|
| I've seen codebases of varying quality in nearly every
| language, "enterprise" and otherwise. I've worked at a C#
| shop and it was no better or worse than the
| java/kotlin/typescript ones I've worked at.
|
| You can blame the "average" developer in a language for
| "not caring ", but more likely than not you're just
| observing the friction imposed by older packaging
| systems. Modern languages are usually coupled with
| package managers that make it trivial to publish language
| artifacts to package hubs, whereas gradle for example is
| it's own brand of hell just to get your code to build.
| justatdotin wrote:
| perhaps many of those 'Folks who use languages like Java
| or C#'
|
| do so because a boss told them 'thats the way we deal
| with correctness and performance around here'
|
| the fact that their boss made that one decision for them
| does not somehow transmit the values behind the one
| decision.
| aizk wrote:
| TS is enormous, has endless training data, and can interact
| with virtually anything on the Internet these days. Also,
| strong typing is very very useful for AI coding context.
| justatdotin wrote:
| > strong typing is very very useful for AI coding context
|
| what makes you think so?
|
| I believe strong typing is very very useful for human
| coding,
|
| I'm not convinced its so 'very very' for agents.
| matwood wrote:
| When I've use agents with TS, failing tests due to typing
| seems to help the agent get to the correct solution.
| Maybe it's not required though.
| tubthumper8 wrote:
| What do you mean by "failing tests", are you talking
| about runtime code? TypeScript erases all types at
| compile so these wouldn't affect tests. Unless you meant
| "compile errors" instead.
|
| I've noticed LLMs just slap on "as any" to solve compile
| errors in TypeScript code, maybe this is common in the
| training data. I frequently have to call this out in code
| review, in many cases it wasn't even a necessary
| assertion, but it's now turned a variable into "any"
| which can cause downstream problems or future problems
| matwood wrote:
| My code has tests and the LLM wrote more tests.
|
| I tell the LLM to include typing on any new code.
|
| The agent is running the test harness and checking
| results.
| ramoz wrote:
| The answer is typescript is a much simpler and more pleasant
| developer experience than any other language. These are
| products they need to, and often originate from, fast churn
| of code/features.
|
| Otherwise they'd be building these types of things in Rust.
| airstrike wrote:
| Surely you jest
| ramoz wrote:
| I wrote the comment while waiting on a 50min rust build
| pipeline
| ants_everywhere wrote:
| The writeup makes it sound like an acquihire, especially the
| "what changes" part.
|
| ChatGPT is feeling the pressure of Gemini [0]. So it's a bit
| strange for Anthropic to be focusing hard on its javascript
| game. Perhaps they see that as part of their advantage right
| now.
|
| [0] https://timesofindia.indiatimes.com/technology/tech-
| news/goo...
| jorblumesea wrote:
| That's a really cool use case and seems super helpful. working
| cloud native is a chore sometimes. having to fiddle with
| internal apis, acl/permissions issues.
| davnicwil wrote:
| Isn't what you're describing just a set of APIs with native
| bindings that the LLM can call?
|
| I'm not sure I understand why it's necessary to even couple
| this to a runtime, let alone own the runtime?
|
| Can't you just do it as a library and train/instruct the LLM to
| prefer using that library?
| ignoramous wrote:
| Mostly, just Jarred Sumner makes it worth it for Anthropic.
| ActionHank wrote:
| Why?
|
| The whole point every CEO with a toe in the AI pool can't
| stop bleating on about is that software engineering is dead
| and replaced by AI.
|
| bun is MIT licensed, they could take bun free of charge and
| use their Phd level software engineer god machine to
| iterate on it.
| btown wrote:
| Yea - if you want a paranoidly-sandboxed, instant-start, high-
| concurrency environment, not just on beefy servers but on
| resource-constrained/client devices as well, you need experts
| in V8 integration shenanigans.
|
| Cloudflare Workers had Kenton Varda, who had been looking at
| lightweight serverless architecture at Sandstorm years ago.
| Anthropic needs this too, for all the reasons above. Makes all
| the sense in the world.
| gorjusborg wrote:
| Bun isn't based on V8, it's JavaScriptCore, but your point
| still stands.
| hbbio wrote:
| Who would have predicted KDE could become the foundation of
| both AI and gaming
| sheepscreek wrote:
| Gaming = talking about the Steam Deck?
| jeeeb wrote:
| Also the worlds most popular web browsers
| orliesaurus wrote:
| you left out the best part...what happened to Kenton? He
| looked at lightweight serverless architecture..and then what?
| kentonv wrote:
| I built Cloudflare Workers?
| martythemaniak wrote:
| This is going to be a HN Classic.
| BoorishBears wrote:
| This is how I found out about HN Classic!
| https://news.ycombinator.com/classic
| Barbing wrote:
| "It's the same algorithm as the regular front page, with
| the difference that the votes are those by users before
| Feb 13, 2008."
|
| Clever!
|
| - https://news.ycombinator.com/item?id=24401292
| fitzn wrote:
| Boom
| sibellavia wrote:
| mic drop
| kitd wrote:
| Comment of the year
| nwellinghoff wrote:
| You single handedly built all of Cloudfare workers?
| Impressive, most of us would have required a team or a
| "we".
| littlestymaar wrote:
| > Yea - if you want a paranoidly-sandboxed, instant-start,
| high-concurrency environment, not just on beefy servers but
| on resource-constrained/client devices as well, you need
| experts in V8 integration shenanigans.
|
| To be honest, that sounds more like a pitch for deno than for
| bun, especially the "paranoidly sandboxed" part.
| milowata wrote:
| Could also be a way to expand the customer for Claude Code from
| coding assistant to vibe coding, a la Replit creating a hosted
| app. CC working more closely with Bun could make all that
| happen much faster:
|
| > Our default answer was always some version of "we'll
| eventually build a cloud hosting product.", vertically
| integrated with Bun's runtime & bundler.
| ok_dad wrote:
| Yea, they just posted this a few days ago:
|
| https://www.anthropic.com/engineering/advanced-tool-use
|
| They discussed how running generated code is better for context
| management in many cases. The AI can generate code to retrieve,
| process, and filter the data it needs rather than doing it in-
| context, thus reducing context needs. Furthermore, if you can
| run the code right next to the server where the data is, it's
| all that much faster.
|
| I see Bun like a Skynet: if it can run anywhere, the AI can run
| anywhere.
| yellow_lead wrote:
| Java can run anywhere too
| throwawaymaths wrote:
| run code anywhere hamstrung by 90s syntax and hidden code
| indirections
| groundzeros2015 wrote:
| Haven't checked in on Java in a while?
| ozim wrote:
| From what I gather everyone is still stuck on Java 8 so
| no need to check?
| foo4u wrote:
| This is absolutely untrue. Code from JDK 8 runs fine on
| JDK 25 (just released LTS). It is true that if you did
| something silly that locks you into certain dependency
| versions, you may be stuck, but this is not the majority
| of applications.
| vips7L wrote:
| No, everyone isn't. You really should check.
| throwaway7783 wrote:
| Where do you gather this from? We are a startup, on Java
| and on 25.
| pylotlight wrote:
| Why didn't you choose something more modern/sensible.
| go/kotlin/anything else on the planet?
| gf000 wrote:
| Go is more verbose than Java though, in what way would it
| be more sensible?
|
| Also, Java's ecosystem is unparalleled (top 3 in size,
| depending on domain it usually has the best packages
| (e.g. typical backend-related functionality)), has
| stellar performance, a huge developer base, best-in-class
| IDE support, even LLMs understand it exceptionally well
| (given how widely represented it is in the training
| corpus, plus has a decent type system) if that's your
| thing.
|
| For a typical backend system, you really have to have a
| good reason to choose something else at this point.
| codr7 wrote:
| Except for Kotlin, which is a much nicer language to deal
| with.
| throwaway7783 wrote:
| Little nicer for sure
| lenkite wrote:
| A nicer language which is much slower to compile compared
| to Java.
| throwaway7783 wrote:
| While kotlin is somewhat nicer, it is not making a huge
| difference compared to java25. Like the sibling said, go
| is as verbose , the JVM is unparalleled still.
|
| Why wouldn't I choose java
| BobbyJo wrote:
| Golang has a way smaller memory footprint on average.
|
| I left a place using Java to run edge apps and the
| footprint was a major issue.
| krzyk wrote:
| Kotlin sensible? It plays catchup game with newest JDKs.
| gf000 wrote:
| Even stuck on Java 8 it's less verbose than Go, which
| everyone seems to love.
|
| But the majority of projects are on a newer JDK than 8
| for quite some years now.
| the_gipsy wrote:
| Not even latest Java is less verbose than Go.
| gf000 wrote:
| Are we talking about the language that has a couple extra
| lines after every statement, disguising as error
| handling?
| the_gipsy wrote:
| go's error handling is very poor and too verbose, but go
| is still way less verbose than Java overall. Like any
| other language.
|
| Java is the running joke of verbosity, and you are too if
| you seriously argue that it's not.
| gf000 wrote:
| Feel free to provide some evidence. Like really, I would
| be interested in examples e.g. from the Java stdlib that
| are significantly more verbose than another generic
| purpose language.
|
| But I do know that you are meaning stuff like
| AbstractFactoryFactory, but you do realize that there is
| zero need to write anything like that and you can (and
| people do) write bad code in any language?
| groundzeros2015 wrote:
| Why is the quality of discourse in this thread so low?
| the_gipsy wrote:
| You started it, where's _your_ evidence?
| lenkite wrote:
| Coding repetitive for-loops for everything and mind-
| numbing error handling put everywhere makes line count
| bloat up like crazy. Go is one of the most verbose
| languages I have seen and I say this as a guy coding in
| Go in my daily work.
|
| Evidence is easy - think of a problem and ask LLM to
| generate _idiomatic_ examples (leverage Java streams,
| with functional decomposition, etc) in Go and Java and
| with error handling. You will find that more often than
| not, the Java line count is far smaller.
| the_gipsy wrote:
| I also code go daily for work, and while what you say is
| true, it's still far less than what I remember from
| working with Java, which was constantly wrapping mundane
| crap in classes and other stuff.
| BobbyJo wrote:
| Go only looks like that in toy examples where you have
| one method calling a bunch of libraries and services. If
| you are writing actual logic, the error handling is
| preferable to exceptions IMO, because no project even
| uses them correctly.
|
| Now if you complain about slice handling, I'm with you.
| throwawaymaths wrote:
| i haven't. do people still use the "class" keyword?
| buzzerbetrayed wrote:
| Is that the issue people have with Java?
| auxiliarymoose wrote:
| I tried to check in on Java recently but got a
| NullPointerException when using the
| AbstractSingletonProxyFactoryBean !
| OrangeMusic wrote:
| I'll never understand people making fun of verbosity. So
| you really prefer short, ambiguous, opaque and
| unpronounceable abbreviations? Really?!
| auxiliarymoose wrote:
| For me at least, I find it easier to see the shape of
| algorithms, control flow, and expressions when the
| variable names are concise. But this also might be
| because I have found Go to fit my use-cases and thinking
| style well, and Go programs tend to follow this naming
| convention.
|
| For example, if I have a struct `PageEntity` with a field
| `Id`, and I am iterating over a slice of such IDs, I
| would prefer using `pid` instead of `pageEntityId` as the
| variable name. But Java APIs and conventions tend to use
| these longer names, so I find it takes more thinking to
| remember the different names instead of quickly seeing
| the behavior of code at a glance.
|
| Java also tends to have a lot of inheritance which
| results in these long glued-together names and makes it
| harder to follow program flow because behaviors get
| introduced in multiple different places (i.e., it has the
| opposite of locality of behavior).
|
| But those are just my opinions and experiences! I know
| many people love Java, and it is a versatile and powerful
| language.
| gf000 wrote:
| That's really funny that you complain about complexity
| and then use Go which is a significantly more verbose
| language...
| gf000 wrote:
| R/ProgrammerHumor quality comment here.
| wiseowise wrote:
| Not in the browser, and no - webassembly doesn't count,
| otherwise you can say the same about Go and others.
| amingilani wrote:
| Why doesn't wasm count?
| programmarchy wrote:
| Compile step makes things more complicated.
| kevin_thibedeau wrote:
| As opposed to minimized JS.
| Sammi wrote:
| Same problem, different orders of magnitude.
| mcpeepants wrote:
| why would the tool minify the script it generated?
| wiseowise wrote:
| You don't need to minimize JS to be able to run it.
| creata wrote:
| Wasm does count, and you _can_ say the same about Go and
| others.
| Sammi wrote:
| Js just runs as is. Atwood's Law and all that.
| jazzypants wrote:
| Sure, they run, but they can't touch the DOM or do much
| that's very interesting without JavaScript.
| fishmicrowaver wrote:
| May I ask, what is this obsession with targeting the
| browser? I've also noticed a hatred of k8s here, and
| while I truly understand it, I'd take the complication of
| managing infrastructure over frontend fads any day.
| MasterScrat wrote:
| HN has a hatred of K8s? That's new to me
| fishmicrowaver wrote:
| This is a site for startups. They have no business
| running k8s, in fact, many of the lessons learned get
| passed on from graybeards to the younger generation along
| those lines. Perhaps I'm wrong! I'd love to talk shop
| somewhere.
| smt88 wrote:
| K8s is used in many situations it shouldn't be, and a lot
| of HNers (including me) are bitter about having to deal
| with the resulting messes
| techscruggs wrote:
| I remember a time ...
| kreijstal wrote:
| java did run in the browser once.... it was embedded
| directly on the browser there was also nsapi
|
| you could also run java with js if you are brave enough
| https://kreijstal.github.io/java-tools/
| TeaVMFan wrote:
| Java runs in the browser currently, after a transpilation
| step (same as .ts):
|
| https://teavm.org/
| gf000 wrote:
| Also CheerpJ (with support for Swing UIs even), Closure
| compiler, and now GraalVM also has an experimental WasmGC
| target.
| 827a wrote:
| Java is not for sale.
| Zambyte wrote:
| Java can be depended on without buying anything.
| bossyTeacher wrote:
| Java's price is your time which you will need tons of as
| Java is highly verbose. The ultimate enterprise language
| spruce_tips wrote:
| try java 25, and update your priors :)
| temp2441139 wrote:
| No amount of updates will wash away the stink of Oracle
| from Java.
| throwaway7783 wrote:
| Again, Temurin/OpenJDK disagree
| belfthrow wrote:
| This is hn, where unless something is written in rust or
| zig usually, people will hate on it. They would rather
| pump a cli tool than any software of sizable scale.
| ahoka wrote:
| Lipstick on a pig.
| bossyTeacher wrote:
| Can't exactly write Java 25 without updating your legacy
| application, can you? And it tends to be the oldest
| applications that are the hardest to update for some
| painful reason. Would be nice if we all could live on the
| bleeding edge all the time
| krzyk wrote:
| Developers that don't care are to blame.
| sfn42 wrote:
| This is such a crappy point. People say it's better now
| but even in java 8 it's just BS. Oh boo hoo I have to
| write a few extra words here and there. Woe is me. The
| IDE will autogenerate the boilerplate for you, you don't
| even have to write it yourself. And once it's there it's
| actually useful, there's a reason it exists.
| nwellinghoff wrote:
| Seriously. I don't get all the over concern over the
| verbosity. At least in java you can tell what the hell is
| going on. And the tools...so good. Right now I am in
| python typescript world. And let me tell you, the
| productivity and ease of java and c# are sorely missed!
| SergeAx wrote:
| Oracle lawyers want you to think so.
| throwaway7783 wrote:
| Ahem, Temurin/OpenJDK disagree
| gf000 wrote:
| You mean the company that 100% open-sourced Java and made
| the open-source (same license as Linux) OpenJDK the
| reference implementation?
| wrboyce wrote:
| It's relevant enough that I feel I can roll out this
| bash.org classic...
|
| <Alanna> Saying that Java is nice because it works on all
| OS's is like saying that anal sex is nice because it works
| on all genders
|
| EDIT: someone has (much to my joy) made an archive of
| bash.org so here is a link[1], but I must say I'm quite
| jealous of today's potential 1/10,000[2] who will discover
| bash.org from my comment!
|
| [1] https://bash-org-archive.com/?338364
|
| [2] https://xkcd.com/1053
| yellow_lead wrote:
| That's hilarious. My comment is mostly a joke, but also
| trying to say that "runs everywhere" isn't that
| impressive anymore.
| throwup238 wrote:
| Yeah everyone proclaims to IANAL nowadays.
| orliesaurus wrote:
| wait - how do you search the quotes??
| wrboyce wrote:
| I don't think there is a search function, I got the exact
| wording from a web search (I think "bash Java anal",
| arguably a dangerous search!) and then after submitting I
| wondered if there is an archive of the quotes.
| mh- wrote:
| https://www.google.com/search?q=site%3Abash-org-
| archive.com+...
|
| seems to work. relies on that individual quote being
| indexed, and google SERPs feeling like returning full
| results at the moment, of course. when the latter fails,
| I've found success with site: queries on Bing (of all
| places.)
| centur wrote:
| Not discovered from scratch, but was a big fan when it
| was alive and kicking. Went there from time to time to
| get some mood boosters. So was very sad when found that
| it's gone (original one). Thanks a lot for sharing that
| bash-org-archive.com exists, what a great fun going down
| this memory lane.
| wrboyce wrote:
| I've been browsing the archive since I left that comment,
| they really were the good old days weren't they. IRC was
| my introduction to geekdom, and I don't think it would be
| unreasonable to say it shaped my life. Here I am 30-ish
| years later, an old man yelling at clouds -- and I
| wouldn't change much!
|
| If anyone ever requested/used an eggdrop(?) bot from
| #farmbots or #wildbots on quakenet then thanks to you
| too; that was certainly one of the next steps down the
| path I took. A (probably very injectable) PHP blog and a
| bunch of TCL scripts powering bots, man I wish I could
| review that code now.
| the__alchemist wrote:
| I found another appropriate XKCD: https://xkcd.com/1682/
| anamexis wrote:
| Perhaps my biggest claim to fame is being #11 on the
| bash.org top 100.
| komali2 wrote:
| Hah, found it: https://bash-org-archive.com/?207373
|
| So how did it work back in the day, people would just
| submit text and it would get upvoted? I always assumed
| like half of them were just made up.
| anamexis wrote:
| Yep, exactly that. I recall that the voting was
| interesting because it was just ranked on absolute number
| of votes, no time decay or anything, so it would take
| quite some time for a new contender to accumulate votes
| to "compete" on the leaderboard. I don't remember if
| there were even accounts or if anyone could just vote
| repeatedly, modulo some IP or cookie-based limits.
|
| As far provenance, I assume a lot of them were made up
| too, but this one was real.
| post_below wrote:
| As one of the lucky 1/10000, holy shit that was amazing.
| Thank you.
|
| To everyone else: I acknowlege that this post is not
| adding value but if you were one of the lucky 1/10000 you
| would understand that I have no choice.
| mythz wrote:
| AI tools value simplicity, fast bootstrapping and
| iterations, this rules out the JVM which has the worst
| build system and package repositories I've ever had the
| displeasure of needing to use. Check in gradle binaries in
| 2025? Having to wait days for packages to sync?
| Windows/Linux gradle wrappers for every project? Broken
| builds and churn after every major upgrade. It's broken
| beyond repair.
|
| By contrast `bun install` is about as good as it gets.
| speed_spread wrote:
| By using Gradle you certainly didn't make yourself a
| favor.
| JavierFlores09 wrote:
| I am unsure why people feel the need to say this about
| Gradle. If you aren't doing anything fancy, the most you
| will touch is the repositories and dependencies block of
| your build script, perhaps add publishing or shadow
| plugins and configure them accordingly but that has never
| been simpler than it is now. Gradle breaks when you feel
| the need to unnecessarily update things like the wrapper
| version or plugins without considering the implications
| that has. Wrapper is bundled in so you don't have to try
| and make a build script work with whatever version you
| might have installed on your system if you have any,
| toolchain resolution makes it so you don't even need to
| install an appropriate JDK version as it does that for
| you.
|
| If the build script being a DSL is the issue, they're
| even experimenting around declarative gradle scripts [0],
| which is going to be nice for people used to something
| like maven.
|
| 0: https://declarative.gradle.org/
| DarkNova6 wrote:
| And yet. None of these issues exist in Maven to begin
| with.
| gf000 wrote:
| At the same time, only Maven requires doing a clean
| install from time to time as it fails to properly track
| what needs updating.
|
| Gradle is better from this perspective, and hopefully
| with its "kotlinization" we will see some stability,
| which was the biggest issue it had before.
| DarkNova6 wrote:
| I personally never had to do a clean install, and thought
| this is being perpetuted due to a mixture of habit and
| paranoia.
|
| In any case, what are the proposed benefits of the
| "kotilization"? I tried it about a year ago but realized
| that it's just a syntax level-wrapper around the same old
| DSL underneath. In the end, I still viewed it as an ill-
| described DSL with a massive learning curve outside of
| happy-paths.
| speed_spread wrote:
| So now there will be Kotlin DSL, Groovy DSL and
| declarative DSL, spread out over up to five files in the
| project root. Gradle is like C++, trying to climb out of
| it's complexity hole by digging deeper every new version.
|
| The problem with Gradle is that it never had a clear
| philosophy to begin with. It's trying to be everything to
| everybody, changes best practices every year and has
| enough features that the project at hand could entirely
| be built out of Gradle scripts itself.
|
| And oh, it still requires an update to run everytime a
| new JDK is released even though the SDK is the most
| backward compatible thing ever written.
| pjmlp wrote:
| Gradle is something that only Android devs should be
| using, and because of Google imposes its use. Had not
| been for Google and Android Gradle plugin, almost no one
| would care.
|
| Please give me Java tools over C, C++, JavaScript or
| Python ones, any day of the week.
|
| Only .NET and Rust compare equally in quality of DX.
|
| AI tools value simplicity?!?
|
| Check in the Python dependency management chaos, what it
| is the proposal this month, from what AI startup doing
| Python tools in Rust?
| sfn42 wrote:
| It's just too bad bun is based on literally the worst
| programming language that's in actual use.
| mythz wrote:
| TypeScript's one of the best, and bun runs it natively.
| sfn42 wrote:
| Typescript is a band aid on the gaping gushing wound that
| is JavaScript. It attempts to fix one problem JS has and
| it doesn't really succeed.
| mythz wrote:
| Sounds like cope. Great Type System, Language Server, IDE
| Integration, compiler feedback, tooling ecosystem, DX Hot
| Reload - all things that made it the most used
| programming language on GitHub.
| sfn42 wrote:
| Overcomplicated type system. Language server seems
| redundant to mention, everything has a language server.
| Everything has ide integration. Everything has decent
| compiler feedback. Everything has hot reloading.
| mythz wrote:
| yes some languages have them, no they're not as good.
| BobbyJo wrote:
| Pretty much all major languages have all of those
| features save hot-reloading, but that only even makes
| sense for UI written in an interpreted language.
| DarkNova6 wrote:
| Apples and oranges. Maven is leagues beyond npm. Screw
| Gradle.
|
| How many mass security incidents have there been with npm
| just the last few weeks?
| wrathofmonads wrote:
| Maven is excellent! Once you understand it, you can work
| with almost any Maven project without needing to learn
| the specifics. I'd take Maven or Cargo any day over
| anything in the JavaScript or Python ecosystem.
| ok_dad wrote:
| I ain't hot a horse in this race I just put 2 and 2
| together to get 4. I'm sure Java is fine but they didn't
| buy Java.
| Schnitz wrote:
| Anywhere where the correct Java version is installed
| correctly, important caveat
| jimbob45 wrote:
| Java's cardinal sin was not owning the OS like
| Microsoft's C# to force end-users to update the
| framework. Oracle really didn't understand what they were
| sitting on with their Ubuntu competitor Solaris.
| sander1095 wrote:
| This has no longer been the case for C# for 10 years
| since the release of .NET Core and (now) .NET. The
| runtime is no longer bundled with the OS.
|
| This is only true for older .NET Framework applications.
| Topfi wrote:
| Isn't it post installation still updated via Windows
| Update as they said (force end-users to update the
| framework)?
| nly wrote:
| Only patches, it doesn't automatically install new major
| versions
| gf000 wrote:
| You can just supply a minimized runtime for your program,
| which is the primary way to ship Java programs for quite
| some time now.
| wiz21c wrote:
| Java is owned by Oracle. And you sure don't want to do
| business with that company. There's a reason why postgresql
| is slowly eating their cake.
| OrangeMusic wrote:
| This is FUD. Java has many open source implementations
| and nobody needs to deal with Oracle.
| jve wrote:
| Well except Google that got sued for US$8.8 Billion
| because they decided to use specific API signatures but
| provide their own implementation...?!
| Hedepig wrote:
| ... and Oracle lost
| cwillu wrote:
| And the lesson is not to trust Oracle.
| OrangeMusic wrote:
| Come on, that's a completely different story, Google made
| their own independent SDK using but incompatible with
| Java. Nobody's arguing you should do that.
|
| Plus last time I checked Oracle lost that lawsuit.
| krzyk wrote:
| What Google did was similar what Microsoft did back in
| the days. Marketing something as Java, but wasn't Java.
| vidarh wrote:
| Even if we postulate that he fear is unwarranted and
| irrational, the fear is still real, based on Oracles
| history of lawsuits, and so the explanation still holds.
| gf000 wrote:
| It explains nothing.
|
| Java is possibly the safest bet on the future, it's open
| source both in spec and in the most common implementation
| (OpenJDK), and is so widely used that there are multiple
| FAANG companies critically dependent on Java working that
| alone could continue the development of the platform were
| anything happen.
|
| Besides, Oracle has been a surprisingly good steward of
| the language.
| cwillu wrote:
| https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_Americ
| a,_.... is not what I would call "good stewardship"
| gf000 wrote:
| What relevance does it have at the topic at hand? Can you
| give an example of what could happen that would make
| sense to worry about?
| TimTheTinker wrote:
| It's a lawsuit by Oracle against a FAANG company that
| relates in some (even tangential) way to the FAANG
| company's use of Java.
|
| That's all that's needed to create a sense of caution for
| would-be adopters.
| gf000 wrote:
| Running Java is not remotely the same as copying the API
| interface of the whole standard library and providing an
| alternative implementation, just to avoid paying Sun, who
| specifically intended on getting money from mobile usage.
|
| Oracle lost the lawsuit and I do agree with the decision
| in that APIs should be freely replicated, but let's not
| pretend that Google was some saint good guy here fighting
| the good fight, they were just cheap and aggressively
| capitalistic.
| sroussey wrote:
| Doesn't every open source implementation just "copying
| the API interface of the whole standard library and
| providing an alternative implementation"?
| lenkite wrote:
| But Google did NOT copy the open source implementation.
| Google copied parts of the closed-source proprietary Java
| SE API specifications in order to have compatibility and
| without taking a license. Kindly remember that Android
| started using OpenJDK very late - around 2015-2016.
|
| Legally the case was about copying declaring code from a
| proprietary product, not an open source one.
| cwillu wrote:
| And they lost, because it was fair use, which was obvious
| to most people in the field. The fact that the lawsuit
| happened in the first place is why I will never trust
| Oracle.
| krzyk wrote:
| FAANGs are not something people care or like, those are
| new axis of evil. So any lawsuit they loose is a good
| thing.
| thesurlydev wrote:
| Immediately read this as "prostate" and proceeded to spit
| out my coffee. Carry on
| krzyk wrote:
| We could also postulate based on left-pad that npm and
| javascript in general shouldn't be used.
|
| It has similar bases on facts.
| veidr wrote:
| "npm and javascript in general shouldn't be used" --
| stipulated
| VMG wrote:
| and JavaScript even anywherer!
| cyanydeez wrote:
| Jesus wept, for the nerds joyfully want skyney
| VerifiedReports wrote:
| What do you mean by "context" here?
| manbash wrote:
| Under "Programmatic Tool Calling"
|
| > The challenge
|
| > Traditional tool calling creates two fundamental problems
| as workflows become more complex:
|
| > Context pollution from intermediate results: When Claude
| analyzes a 10MB log file for error patterns, the entire
| file enters its context window, even though Claude only
| needs a summary of error frequencies. When fetching
| customer data across multiple tables, every record
| accumulates in context regardless of relevance. These
| intermediate results consume massive token budgets and can
| push important information out of the context window
| entirely.
|
| > Inference overhead and manual synthesis: Each tool call
| requires a full model inference pass. After receiving
| results, Claude must "eyeball" the data to extract relevant
| information, reason about how pieces fit together, and
| decide what to do next--all through natural language
| processing. A five tool workflow means five inference
| passes plus Claude parsing each result, comparing values,
| and synthesizing conclusions. This is both slow and error-
| prone.
|
| Basically, instead of Claude trying to, e.g., process data
| by using inference from its own context, it would offload
| to some program it specifically writes. Up until today
| we've seen Claude running user-written programs. This new
| paradigm allows it the freedom to create a program it finds
| suitable in order to perform the task, and then run it
| (within confines of a sandbox) and retrieve the result it
| needs.
| VerifiedReports wrote:
| Thanks for the reply.
| ramoz wrote:
| Claude Code moved to partial file reads over the summer.
|
| Super premature optimization. It'll hallucinate what
| lines it needs to read, it'll continuously miss critical
| context in favor of trimming tokens.
|
| Luckily we can now hook and force the agent to read full
| files at least once.
| gz5 wrote:
| >Claude will be able to leverage these capabilities to extend
| its reach across the cloud and add more value in enterprise use
| cases
|
| 100%. even more robust if paired with an overlay network which
| provides identity based s3 access (rather than ip
| address/network based). else server may not have access to
| s3/cloud resource, at least for many enterprises with s3 behind
| vpn/direct connect.
|
| ditto for cases when want agent/client side to hit s3 directly,
| bypassing the server, and agent/client may not have permitted
| IP in FW ACL, or be on vpn/wan.
| 1vuio0pswjnm7 wrote:
| As a commandline end user who prefers to retreive data from the
| www as text-only, I see deno and bun as potential replacements
| (for me, not necessarily for anyone else) for the so-called
| "modern" browser in those rare cases where I need to interpret
| Javascript^1
|
| At present the browser monstrosity is used to (automatically,
| indiscriminantly) download into memory and run Javascripts from
| around the web. At least with a commandline web-capable JS
| runtime monstrosity the user could in theory exercise more
| control over what scripts are downloaded and if and when to run
| them. Perhaps more user control over permissions to access
| system resources as well (cf. corporate control)
|
| 1. One can already see an approach something like this being
| used in the case of
|
| https://github.com/yt-dlp/yt-dlp/wiki/EJS
|
| where a commandline JS runtime is used without the need for any
| graphics layer (advertising display layer)
| tclancy wrote:
| Is this something I'd have to own a tv to understand?
| 1vuio0pswjnm7 wrote:
| Why do Apple, Microsoft, Google, Meta, OpenAI, AWS and other
| so-called "tech" companies advertise on TV
|
| What about people who do not own a TV
| jillesvangurp wrote:
| I'm not confused about the acquisition but about the
| investment. What were the investors thinking? This is an open
| source development tool with (to date), 0$ of revenue and not
| even the beginnings of a plan for getting such a thing.
|
| The acquisition makes more sense. A few observations:
|
| - no acquisition amount was announced. That indicates some kind
| of share swap where the investors change shares for one company
| into another. Presumably the founder now has some shares in
| Anthropic and a nice salary and vesting structure that will
| keep him on board for a while.
|
| - The main investor was Kleiner Perkins. They are also an
| investor in Anthropic. 100M in the last round, apparently.
|
| Everything else is a loosely buzzword compatible thingy for
| Anthropic's AI coding thingy and some fresh talent for their
| team. All good. But it's beside the point. This was an investor
| bailout. They put in quite a bit of money in Bun with exactly 0
| remaining chance of that turning into the next unicorn.
| Whatever flaky plan there once might have been for revenue that
| caused them to invest, clearly wasn't happening. So, they
| liquidated their investment through an acquihire via one of
| their other investments.
|
| Kind of shocking how easy it was to raise that kind of money
| with essentially no plan whatsoever for revenue. Where I live
| (Berlin), you get laughed away by investors (in a quite smug
| way typically) unless you have a solid plan for making them
| money. This wouldn't survive initial contact with due
| diligence. Apparently money still grows on trees in Silicon
| Valley.
|
| I like Bun and have used it but from where I'm sitting there
| was no unicorn lurking there, ever.
| djfdat wrote:
| They don't need Bun to make revenue, but they need Bun to
| continue existing and growing for their products to make
| revenue. Now they can ensure its survival, push for growth,
| and provide resources so that Bun can build the best product
| rather than focus on making money.
| danenania wrote:
| Investors are really bad at predicting up front what can
| become a unicorn and what can't.
| wrathofmonads wrote:
| Java was doing "cloud-native, stripped down (jlink) image,
| self-contained runtime with batteries included" long before Bun
| existed. There's also GraalVM for one executable binary if
| one's ambitious.
| kopirgan wrote:
| I'm also confused.. Why does a generic AI company that helps
| coding as one of main offering get deeply in bed with one tech
| stack
|
| I mean would it have made sense to acquire golang if it were on
| sale?
| qwm wrote:
| They want to make sure the runtime they depend on continues
| to be maintained. It's still niche and new, so its continued
| existence isn't as sure as something like Go.
| catigula wrote:
| I don't get the whole 'cloud' thing for AI agents. It feels
| forced. Who is actually using these services?
| danenania wrote:
| Non-developers usually prefer them to IDE or terminal based
| tools.
| catigula wrote:
| Non-developers shouldn't be trying to maintain code.
| Developing products as if they can is very disingenuous.
| baby wrote:
| if I would guess Anthropic is (rightly) frustrated with the
| state of the js ecosystem and is taking the best attempt so far
| to make the js experience much more streamlined for their
| developers. Convention over configuration might finally be
| coming to the js ecosystem?
| Sirikon wrote:
| Hahahahahhaahhahahahahahhahahahahahhahahaha.
|
| Regards.
| patrick4urcloud wrote:
| wow !
| Anonyneko wrote:
| I'm only surprised that it wasn't Vercel who bought them.
| pier25 wrote:
| I wonder what this means for Deno.
|
| Will this make it more or less likely for people to use Bun vs
| Deno?
|
| And now that Bun doesn't need to run a profitable cloud company
| will they move faster and get ahead of Deno?
| GianFabien wrote:
| I think Deno's management have been somewhat distracted by
| their ongoing lawsuits with Oracle over the release of the
| Javascript trademark.
|
| I started out with Deno and when I discovered Bun, I pivoted.
| Personally I don't need the NodeJS/NPM compatability. Wish
| there was a Bun-lite which was freed of the backward
| compatability.
| pier25 wrote:
| I'm in a similar position.
|
| I use Hono, Zod, and Drizzle which AFAIK don't need Node
| compat.
|
| IIRC I've only used Node compat once to delete a folder
| recursively with rm.
| Zambyte wrote:
| What do you dislike about having node compatibility?
| GianFabien wrote:
| The bloat. I prefer lean designs with plug-in modules for
| additional functionality. Not only do unused sub-systems
| take up memory, but they also increase the potential attack
| surface.
| carefulfungi wrote:
| Ironically, this was early Deno - but then adoption required
| backwards compatibility.
| pjmlp wrote:
| In regards to Deno, to me that means their business is not
| really flying and they need this kind of distractions
| instead.
|
| Amount of people at big corps that care about their lawsuit,
| and would switch their IT guidelines from node to Deno due to
| such heroic efforts?
|
| Zero.
| spartanatreyu wrote:
| > Will this make it more or less likely for people to use Bun
| vs Deno?
|
| I'm not sure it will make much of a difference in the short
| term.
|
| For those who were drawn to Bun by hype and/or some concerns
| around speed, they will continue to use Bun.
|
| For me personally, I will continue to use Node for legacy
| projects and will continue using Deno for current projects.
|
| I'm not interested in Bun for it's hype (since hype is
| fleeting). I have a reserved interested in Bun's approach to
| speed but I don't see it being a significant factor since most
| JS speed concerns come from downloading dependencies (which is
| a once-off operation) and terrible JS framework practices
| (which aren't resolved by changing engines anyway).
|
| ----------------------------
|
| The two largest problems I see in JS are:
|
| 1. Terrible security practices
|
| 2. A lack of a standard library which pushes people into
| dependency hell
|
| Deno fixes both of those problems with a proper permission
| model and a standard library.
|
| ----------------------------
|
| > And now that Bun doesn't need to run a profitable cloud
| company will they move faster and get ahead of Deno?
|
| I think any predictions between 1-10 years are going to be a
| little too chaotic. It all depends on how the AI bubble goes
| away.
|
| But after 10 years, I can see runtimes switching from their
| current engines to one based on Boa, Kiesel or something
| similar.
| pier25 wrote:
| > _Deno fixes both of those problems with a proper permission
| model and a standard library_
|
| Bun has a better standard library than Deno. You get a DB
| driver, S3 client, etc which on Deno are all third party
| deps. It was the main reason I got interested in Bun. The
| speed is nice though during dev. Everything feels instant.
| sergiotapia wrote:
| Prediction Bun is absorbed in house and used by Anthropic to
| have faster/cheaper places for Claude to run code.
|
| It fades away as a direct to developer tool.
|
| This is a good thing for Deno.
| notnullorvoid wrote:
| Bun and Deno's goals seem quite different, I don't expect that
| to change. Bun is a one stop shop with an ever increasing
| number of built-in high-level APIs. Deno is focused on low
| level APIs, security, and building out a standard lib/ecosystem
| that (mostly) supports all JS environments.
|
| People who like Bun for what it is are probably still going to,
| and same goes for Deno.
|
| That being said I don't see how Anthropic is really adding long
| term stability to Bun.
| joshcsimmons wrote:
| Deno is dead. Seems like there haven't been very relevant or
| user-informed changes on their roadmap for year(s) now.
| ignoramous wrote:
| > _Deno is dead._
|
| Not yet; similar concerns were addressed by Dahl 6mo ago:
| https://deno.com/blog/greatly-exaggerated /
| https://archive.vn/L6His
| huqedato wrote:
| Aham, tx. Good to know - I'll switch my projects to Deno.
| killingtime74 wrote:
| you know Deno is VC backed right
| ngrilly wrote:
| Considering that 1) Bun is written in Zig, 2) Zig has a strict
| no-AI policy [1], and 3) Bun has joined Claude, it seems that Bun
| and Zig are increasingly culturally apart.
|
| [1] https://ziglang.org/code-of-conduct/#strict-no-llm-no-ai-
| pol...
| M4v3R wrote:
| Nothing I found says anything about Zig folks being inherently
| against AI. It just looks like they don't want to deal with "AI
| Slop" in contributions to their project, which is very
| understandable.
| ignoramous wrote:
| > _Bun and Zig are increasingly culturally apart_
|
| That's like saying GCC and NodeJS are culturally apart, as if
| that has significant bearing on either?
| dan-robertson wrote:
| You're reading a code of conduct for contributing to the zig
| project. I don't think everything there is guidance for
| everything written in zig, eg 'English is encouraged' is
| something one might not want for a project written in zig by
| native French-speakers, and I don't think that's something zig
| would want to suggest to them. I read the AI part is much more
| motivated by the asymmetries of open source project
| contribution than any statement about the language itself. Fly-
| by AI contributions are bad because they make particularly poor
| use of maintainer time. Similar to the rule on proposing
| language changes, which can suck up lots of
| reading/thinking/discussion time. When you have people
| regularly working together (eg those people in anthropic
| working on bun) the incentives are different because there is a
| higher cost to wasting your colleague's time.
| bibimsz wrote:
| bullish for js, bearish for python?
| indigodaddy wrote:
| Has CC always used Bun? When it tries it out many months ago it
| was an npm install not bun install in their instructions
| (although I did use bun install myself). Just odd that if they
| were using bun, why the installation wasn't specifically a "bun
| install" (I suppose they were trying to keep it vanilla for the
| npm masses?)
| djfobbz wrote:
| I finally hope Bun will start to support and work on WSL1
| bilekas wrote:
| Genuine question, why acquisition when anthropic could simply
| sponsor, contribute and influence instead?
|
| Acquisition seems like a large overhead and maybe a slight pivot
| to me.
| piskov wrote:
| Genuine question: why js?
|
| Why not something like c#: native, fast, crossplatform, strongly-
| typed, great tooling, supports both scripting (ie single file-
| based) and compiled to a binary with no dependency whatsoever
| (nativeAOT), great errors and error stacks, list goes on.
|
| All great for AI to recover during its iterations of generating
| something useful.
|
| Genuinely perplexed.
| hoppp wrote:
| Because js became an everything language that everyone can
| write and its the only language you ever need.
|
| I dislike it also..
| awesome_dude wrote:
| You could make a better argument for Go (compiles to native for
| multiple targets, zero actual dependencies (no need for a
| platform or virtual machine on the target)
| piskov wrote:
| C# no longer requires .net installed or bundled inside exe.
|
| Like I've said: NativeAOT
|
| https://learn.microsoft.com/en-
| us/dotnet/core/deploying/nati...
| mrcsharp wrote:
| C# has AOT compilation producing native, single file
| assemblies. A bit behind on this compared to Go, but it's
| there.
| morshu9001 wrote:
| Go is the most portable compiled language out there and makes
| a lot of compromises with the interpreted lang world. But
| it's got its own issues.
| metaltyphoon wrote:
| >zero actual dependencies
|
| on Linux only with CGO_ENABLED=0 and good luck using some non
| web related 3rd party module which can be used with CGO
| disabled.
| mrcsharp wrote:
| Sadly, this will be the trend with things moving forward. JS is
| perceived as a good language and LLMs are meant to make them
| even easier to write. It is not about the mertis of a language.
| It's about which languages LLMs are "good" at.
| hexasquid wrote:
| If I was to pick a language, I'd pick the one all developers
| agree is the best.
| nixosbestos wrote:
| Ahahahahhahahahahhahahahaahaha. Please tell me this is
| tongue-in-cheek and just more subtle than I give HN credit
| for. Please.
| morshu9001 wrote:
| Not all devs, not even most, but I certainly think this
| dolmen wrote:
| AI are good at JS because basically there is a ton of JS code
| available publicly without usage restriction: the JS code
| published to be executed in your browser. Most of JS code
| attached to web pages has no explicit license, but the implicit
| license is that anyone can download it and run it. Same for
| HTML and CSS. So using that public code to train models is a no
| brainer.
| morshu9001 wrote:
| Same reason AIs also use Python and DBMSes offer JS or Py UDFs
| easily, interpreted languages take no build time and are more
| portable. JS is also very popular.
|
| Might also be a context window thing. Idk how much boilerplate
| C# has, but others like Java spam it.
| mokarma wrote:
| Atwood's Law
| kuekacang wrote:
| One other angle yet mentioned: JS is browser native. No matter
| how slow it is, browser is now the LCD. Similar server-client
| codebase, while ugly, is another plus.
| jitl wrote:
| There's like 100x more JS developers than C# developers. JS can
| also run code very quickly, where with an AOT language, you
| need to AOT compile it. For tool calls, eval-as-a-service,
| running in browser JS is far ahead of C#.
| mrsmrtss wrote:
| So, everyone who can hack some JS is now a developer? The
| '100x' claim is obviously exaggerated. C# is certainly one of
| the most used programming languages there is.
|
| You can run also C# code very quickly, but have the option
| (but not the need) to AOT compile it. I would say the only
| real edge JS has is the ability to run natively in the
| browser. It was built for that purpose, and in my opinion,
| that is where it should have stayed.
| aizk wrote:
| I thought c# was a dead language at this point?
| mrsmrtss wrote:
| You must have been living under a rock. C# is one of the most
| popular languages out there and it's better than ever.
| greatNespresso wrote:
| Looks like a good time to try learning Zig again
| rcarmo wrote:
| Neat. I just started using bun as my default "batteries included"
| JavaScript engine, so it's nice they're getting this boost.
| shrubble wrote:
| There's no reason to run agents on expensive AI platforms or on
| GPUs - when you can have the AI create an agent in JS and thus
| runs with very high performance and perfect repeatability on far
| less expensive CPUs.
|
| At the very least there must be _some_ part of the agent tasks
| that can be run in JS, such as REST APIs, fetching web results,
| parsing CSV into a table, etc.
| awesome_dude wrote:
| Am I missing something - I thought that GPUs are for training
| the weights
|
| Being able to create an agent in any language to run on any
| hardware has always been possible hasn't it?
| int_19h wrote:
| Agents already do this exact thing, except that the go-to
| language for Claude to write one-off scripts in is usually
| Python.
| s-mon wrote:
| Congratulations to the team. Knowing some of the folks on the Bun
| team I can not say I am surprised. They are the top 0,001% of
| engineers, writing code out of love. I'm hugely bullish on
| Anthropic, this is a great first acquisition.
| qjack wrote:
| Anthropic has been trying to win the developer marketshare, and
| has been quite successful with Claude Code. While I understand
| the argument that this acquisition is to protect their usage in
| CC or even just to acquire the team, I do hope that part of their
| goal is to use this to strengthen their brand. Being good
| stewards of open source projects is a huge part of how positively
| I view a company.
| Wowfunhappy wrote:
| > Being good stewards of open source projects is a huge part of
| how positively I view a company.
|
| Maybe an easier first step would be to open source Claude
| Code...?
| Aeolun wrote:
| I think because their models are open (e.g. CC can send any
| instruction and it'll use your max plan), they need to keep
| the code obfuscated to prevent people from sending everybody
| and their mother through that API.
|
| Codex has the opposite issue. It has an open client, which is
| relatively pointless, because it will accept only one system
| prompt and one prompt only.
| grim_io wrote:
| Maybe they just like to work together *shrug*.
| devops000 wrote:
| Shopify should buy Ruby on Rails because they depends on it
| hu3 wrote:
| didn't they try a hostile takeover of the ruby gems thing
| (forgot the name)?
| noodletheworld wrote:
| If claude code starts having ads for bun in the code it
| generates, I am never using it again.
|
| To some degree have "opinionated views on tech stacks" is
| unavoidable in LLMs, but this seems like it moves us towards a
| horrible future.
|
| Imagine if claude (or gemini) let you as a business pay to
| "prefer" certain tech in generated code?
|
| Its google ads all over again.
|
| The thing is, if they own bun, and they want people to use bun,
| how can they justify _not_ preferencing it on the server side?
|
| ...and once one team does it... game on!
|
| It just seems like a sucky future, that is now going to be
| unavoidable.
| javierhonduco wrote:
| Wondering to what degree this was done to support Anthropic's web
| crawler. Would assume that having a whole JS runtime rather than
| just a HTTP client could be rather useful. Just hypothesising
| here, no clue what they use for their crawler.
| blixt wrote:
| Extrapolating and wildly guessing, we could end up with using all
| that mostly idle CPU/RAM (the non-VRAM) on the beefy GPUs doing
| inference on agentic loops where the AI runs small JS scripts in
| a sandbox (which Bun is the best at, with its faster startup
| times and lower RAM use, not to mention its extensive native
| bindings that Node.js/V8 do not have) essentially allowing
| multiple turns to happen before yielding to the API caller. It
| would also go well with Anthropic's advanced tool use that they
| recently announced. This would be a big competitive advantage in
| the age of agents.
| intrasight wrote:
| I almost read this as anthropic will be using our idle CPU/GPU
| resources for their own training tasks ;)
| mcdow wrote:
| From the comments here it sounds like most people think the
| amount Anthropic paid for the company was probably not much more
| than the VC funding which Bun raised.
|
| How would the payout split work? It wouldn't seem fair to the
| investors if the founder profited X million while the investors
| get their original money returned. I understand VC has the
| expectation that 99 out of 100 of investments will net them no
| money. But what happens in the cases where money is made, it just
| isn't profitable for the VC firm.
|
| What's to stop everyone from doing this? Besides integrity, why
| shouldn't every founder just cash out when the payout is life-
| changing?
|
| Is there usually some clause in the agreements like "if you do
| not return X% profit, the founder forfeits his or her equity back
| to the shareholders"?
| kevmo314 wrote:
| Probably not much more than their _valuation_ , which is the
| key difference since the investor will still get a net return.
| deepdarkforest wrote:
| All VC's have preferred shares, meaning in case of liquation
| like now, they get their investment back, and then the
| remainder gets shared.
|
| Additionally, depending on round, they also have multiples,
| like 2x meaning they get at least 2x their investment before
| anyone else gets anything
| taf2 wrote:
| okay so does that mean openai buys deno?
| _andrei_ wrote:
| All vendors will have to implement test time code execution,
| solution exploration, etc. as it's a low hanging fruit with huge
| gains, so I see it as a great hire. Love Bun, happy for you guys!
| rashkov wrote:
| Do you mean train time?
| Computer0 wrote:
| So, what if Claude Code starts using Bun in all applicable
| situations? If model providers train their models to use a tech
| stack beneficial to their business interests?
| terryds wrote:
| Wow.
| hungryhobbit wrote:
| But will they fix command line autocompletions?
| fud101 wrote:
| So this is a rug pull we were afraid of? Bun got me into
| javascript ecosystem after years of hating on it. This sucks.
| wavemode wrote:
| To be honest, I never thought of Bun as something that someone
| would buy or invest in. What product do they sell?
| notnullorvoid wrote:
| I am more shocked about the origin story compared to the
| acquisition.
|
| > Almost five years ago, I was building a Minecraft-y voxel game
| in the browser. The codebase got kind of large, and the iteration
| cycle time took 45 seconds to test if changes worked. Most of
| that time was spent waiting for the Next.js dev server to hot
| reload.
|
| Why in the hell would anyone be using Next.js to make a 3D
| game... Jarred has always seemed pretty smart, but this makes no
| sense. He could've saved so much time and avoided building a
| whole new runtime by simply not using the completely wrong tool
| for the job.
| mayo369 wrote:
| Maybe same for anthropic, they can simply write agent using
| Rust/Go. Instead they decide to buy and develop a JavaScript
| runtime.
| nly wrote:
| If anything this seems to be a huge victory for Zig, since
| Bun is mostly written in Zig.
| throwup238 wrote:
| That's just what the Javascript ecosystem has been missing!
| A runtime built on an unstable pre-1.0 language to go with
| the npm dependency churn. It's been way too long since I've
| had to waste a week debugging what turns out to be a
| compiler/interpreter bug.
|
| (I'm half joking, that's awesome for Zig!)
| someguyiguess wrote:
| Rushing things to completion using unfinished code is the
| JavaScript way!
|
| - a javascript developer
| qeternity wrote:
| These are completely different. Agents (aside from the model
| inference) are not CPU bound. You gain much more by having a
| wider user base than whatever marginal CPU cycles you would
| gain in Rust/Go.
|
| Video games are of course a different story.
| someguyiguess wrote:
| My thinking is that they're trying to capture that market for
| JavaScript before another AI company does. To put it bluntly
| they want to capture the revenue generated by writing
| JavaScript code, which is currently being captured by
| independent JavaScript developers. The reason for a
| JavaScript is that is the most ubiquitous language, and id
| guess there are more jobs available for JS/node than any
| other language. Of course, as a JavaScript developer, this
| may just be my paranoia. <sweats profusely>
| Aeolun wrote:
| > He could've saved so much time and avoided building a whole
| new runtime by simply not using the completely wrong tool for
| the job.
|
| True, but where is the fun in that?
| mock-possum wrote:
| Most people use what they know. You start out that way, and if
| it turns out to be good, you can always do a v2
| notnullorvoid wrote:
| Yes, but there are obvious limits to that. This is like
| someone who knows how to bake wanting to build a car, so they
| start making it out of dough.
| someguyiguess wrote:
| That is not a good analogy. Games are built using
| programming languages. JavaScript is a programming
| language. Cars are built using metals (usually steel). A
| better analogy would be like trying to build a car out of
| iron, a really heavy metal. Since js/node is very resource
| heavy requiring transpilation/etc...
| johncolanduoni wrote:
| He may have been serving a game in a canvas hosted in a Next.js
| app, but have done all the actual game (rendering, simulation,
| etc.) in something else. That's a decent approach - Next can
| handle the header of the webpage and the marketing blog or
| whatever just fine.
| komali2 wrote:
| But like... so can an index.html with a script tag? Am I
| missing something, where did you read that there was a lot of
| work involving the header or an attached marketing blog?
| shortrounddev2 wrote:
| index.html with script files would still benefit from a
| bundler. You can have a very minimal react footprint and
| still want to use react build tools just for bundling.
| komali2 wrote:
| Sure, but I'm more confused about the next.js usage than
| I am about the bundler. The bundler makes sense.
| johncolanduoni wrote:
| What effect do you imagine Next.js has on a bunch of code
| manipulating an HTML canvas? For vanilla code directly
| using browser APIs it's basically just a bundler
| configuration, and while it's not optimally configured
| for that use case (and annoying for other reasons) it's
| probably better than what someone who has never
| configured webpack before would get doing it themselves.
| komali2 wrote:
| Well for one, it ships next.js and react.js bundled in
| with the code manipulating an HTML canvas.
| johncolanduoni wrote:
| Okay, but it's a web game. Those will make up less than
| 0.1% of the downloaded bytes required to render the first
| frame of the game. One image asset will dwarf the entire
| gzip/brotli Next.js/React framework.
| timcambrant wrote:
| What is the use case for bundling next.js with the web
| game? Just the layout of the page surrounding the game
| canvas? It just seems unnecessary, that's all.
| Traditionally, software development in general and game
| development in particular has tried to avoid unnecessary
| overhead if it doesn't provide enough value to the
| finished product.
|
| It's obvious why he didn't write the game in x86
| assembly. It's also obvious why he didn't burn the game
| to CD-ROM and ship it to toy stores in big box format.
| Instead he developed it for the web, saving money and
| shortening the iteration time. The same question could be
| asked about next.js and especially about taking the time
| to develop Bun rather than just scrapping next.js for his
| game and going about his day. It's excellent for him that
| he did go this route of course, but in my opinion it was
| a strange path towards building this product.
| johncolanduoni wrote:
| Why would he stress about a theoretical inefficiency that
| has very little effect on the finished product or
| development process? Especially one that could be
| rectified in a weekend if needed? The game industry is
| usually pretty practical about what it focuses on from a
| performance perspective with good reason. They don't
| build games like they're demosceners min-maxing numbers
| for fun, and there's a reason for that.
|
| I also wonder how many people who sing the praises of an
| HTML file with a script tag hosted by Nginx or whatever
| have ever built a significant website that way. There's a
| lot of frustrating things about the modern JS landscape,
| but I promise you the end results were not better nor was
| it easier back before bundlers and React.
| johncolanduoni wrote:
| My point isn't that you absolutely need that, just that the
| negative effect on your game development are pretty minimal
| if you're not leaning on the SPA framework for anything
| related to the game. If your game is going to be embedded
| into an otherwise normal-ish website, this isn't a terrible
| way to go (I've done it personally with a game mostly
| written in Rust and compiled to WASM). You can get gains by
| splitting your game and web site bundles and loading the
| former from the latter explicitly, but they're not massive
| if your bundler was already reasonably incremental (or was
| already esbuild).
|
| Thanks for assuming I "read" about bundlers somewhere,
| though. I've been using (and configuring) them since they
| existed.
| komali2 wrote:
| I meant specifically was there something I was missing
| about the Bun developer's game that required a
| complicated header and thus next.js.
| Tadpole9181 wrote:
| Because he wanted to? Do you also berate the choices of people
| in the 4K demo scene for using too little memory?
| someguyiguess wrote:
| That's kind of the opposite though. I guess if you're saying
| that there's an art to building things using the least
| efficient means possible just as there's an art to being
| maximally efficient (like the 4k demo scene) then your point
| stands.
| Tadpole9181 wrote:
| Yeah, my point was that people do things for fun or as a
| challenge or to push the limits of a technology.
|
| Nobody made DOOM in Excel because they thought it made a
| good engine.
| cyco130 wrote:
| First time I see it being a net positive that someone didn't
| know about Vite: Bun wouldn't exist otherwise.
| moritonal wrote:
| This take is interesting given we're all here congratulating
| Jarred for seeing that there was no tool to solve x so made it,
| and is now enjoying a likely nice payday. Be the change you
| want to see in the world?
| PurpleRamen wrote:
| It kinda reads like a case of survivorship bias. He is the
| one in a million to reach the good ending, despite starting
| with the wrong choice; though in this case, the wrong choice
| brought him on the road to the good ending.
|
| Now the real question is, does the game loads significant
| better now, or does the performance still suck? In which case
| it might be more an excessive case of yak-shaving. And if
| yes, when can we except the release?
| someguyiguess wrote:
| If the output generated by his attempts at making a better
| game is a much faster node runtime, then even if the game
| is still not usable does that matter? The end result is
| still an improvement over something that existed before.
| The game was just a catalyst.
|
| Isn't every success story really an example of survivorship
| bias?
| PurpleRamen wrote:
| > Isn't every success story really an example of
| survivorship bias?
|
| No, survivorship bias (in this context) means to wrongly
| see a minor subgroup as the majority. But the successful
| subgroup is not always a minority, or falsely labelled.
| richardlblair wrote:
| Using your comment to address overall sentiment in this
| comment thread.
|
| Builders build. Sometimes it's not about picking the right
| tools for the job or starting with the right choices.
| Sometimes it's just about building.
|
| To use your road analogy - sometimes people just go for a
| drive. Sometimes those people end up right where they are
| supposed to be.
| ramon156 wrote:
| I don't think his goal was to get the fastest voxel engine.
| Most projects just start with "That's stupid... but what if I
| did it anyway?"
| someguyiguess wrote:
| I'm guessing he was probably a JavaScript developer that wanted
| to make a game. He began building it using what he knew and
| then he hit the limitations of it. Rather than switching to
| something else, he tried to figure out why fast compile times
| weren't possible and determined that they were possible and
| started to build a solution for it.
| torginus wrote:
| That's super strange since React by its nature assumes that
| controls are stateless - which games definitely are not. If you
| render your game inside a canvas then React decides it wants to
| recreate your control, then your whole game restarts.
| kgc wrote:
| Should we be porting our Python projects over to Javascript?
| VerifiedReports wrote:
| "Node.js compatibility & replacing Node.js as the default server-
| side runtime for JavaScript"
|
| Except Node's author already wrote its replacement: Deno.
| socketcluster wrote:
| Bun is pretty cool. I maintain a Node.js library and updated my
| Node.js engine version and my library just didn't work on the
| latest version... In frustration, I decided to try Bun for the
| first time... I had never used it before but my library worked
| straight away, no warnings, no errors. I have never seen that
| level of compatibility before when a library works better with an
| alternative engine than the one it was designed for.
|
| I did end up fixing Node.js compatibility later but it was extra
| work. Felt like they just created busy-work. Node.js maintainers
| should stop deprecating perfectly good features and complicating
| their modules.
| mdtrooper wrote:
| It is remembers to me to Arduino buy for Qualcomm. And it was not
| good news.
| m00dy wrote:
| who's going to buy deno ?
| pech0rin wrote:
| Look Bun is a great product but something hilarious about the
| company that is "going to replace all software developers with
| AI" BUYING software. You are building a product that is supposed
| to make software cost 0 right? Why wouldn't you just "vibe" code
| yourself Bun?
| fragmede wrote:
| Those aren't your customers. The people that want to build
| things _with_ bun are. The problem with people who already know
| how to code is that they have opinions if they actually read
| the generated code. If you sell to people who don 't (for
| whatever reason), you face less criticism.
| solumunus wrote:
| I think you're confused.
|
| > going to replace all software developers with AI
|
| No?
|
| > building a product that is supposed to make software cost 0
| right
|
| No?
| hit8run wrote:
| I love bun but for a cli tool: why they don't write Claude Code
| in Go and call it a day?
| tossandthrow wrote:
| Maybe now Claude will not assume that I use npm, and actually
| start using bun?
| mkornaukhov wrote:
| That's good news. I hope this will encourage the industry to use
| the Zig language (and its creators to release version 1.0).
| bababuu wrote:
| I find it a little sad, that there is almost no pushback on what
| a few people with deep pockets are trying to sell here. Normaly
| on HN an article on balcon gardening would be met with more
| critical thinking than this piece. Maybe instead of staring to
| the screen all day long take a break, think about what people
| with lots of money care about. And I don't judge, making money is
| nothing illegal. But Anthropic would be absolutely NOTHING
| without OSS. And then to see the kind of this effusive,
| submissive admiration and gratitude for their js wrapper thing
| makes me sick to my stomach.
| tonyhart7 wrote:
| why not Antrophic just fork or make a clone Bun themselves????
|
| /s
| bluelightning2k wrote:
| Since when is a CLI tool like this a sufficiently demanding
| technical project that it needs to buy the runtime just to get
| sufficient support?
|
| This just isn't the hard part of the product.
|
| Like if I was building a Claude Code competitor and I acquired
| bun, I wouldn't feel like I had an advantage because I could get
| more support with like fs.read?
| bluelightning2k wrote:
| I think this acquisition in reality has more to do with developer
| goodwill? And a little to do with the shell game of making these
| AI companies hard to value because they collect assets like this.
| aperture147 wrote:
| Why don't they use their self-acclaimed SE-replacing AI coding
| bot to fork Bun and called it AnthroBun instead of hiring actual
| engineers behind Bun?
| elAhmo wrote:
| > Anthropic has direct incentive to keep Bun excellent.
|
| Huh, this feels very odd to read and buying a company outright is
| definitely not the only way to push Bun to be excellent.
| Contributing to Bun from their developers, becoming a sponsor,
| donating through other means, buying 'consulting services' or
| similar, or even forking it and keeping it up to date would all
| be also steps towards keeping the Bun excellent.
|
| This is vendoring a dependency on steroids, and first moment
| interests of community are not aligned with what Antropic needs,
| it will be interesting to see how this unfolds. History has
| thought us that this will end up with claims in the blog post not
| holding much weight.
| smotched wrote:
| since Anthropic is one of the only companies using the Bun
| Runtime, not just the bundler like most do, they want to make
| sure the runtime stays the focus. This is good for both
| companies and us tbh since they wont switch focus to whats
| popular at the moment
| kunley wrote:
| So will Bun devs now be obliged to stop coding and only manage
| ai-driven code, like Anthropic devs say they are?
|
| Or perhaps they have in their agreement that Anthropic's own
| rules don't apply to them?
|
| Serious question, in all this madness
| baxuz wrote:
| AI slop lovers both of them.
| odyssey7 wrote:
| Proper tail calls for the win! Hopefully Google, now in its AI
| race, decides to give V8 its due.
| dgellow wrote:
| Congrats to the Bun team, what a wild ride! Is that the first
| major zig acquisition?
| lionkor wrote:
| > Bun will ship faster.
|
| What? Oh, lots of slop code?
| soapdog wrote:
| oh, I really dislike that. I don't want AI companies encroaching
| more in my development workflow. Used to really enjoy Bun, but
| don't want support Anthropic at all. Will switch back to another
| runtime.
| esjeon wrote:
| Yeah, I really get that. I've been a fan of zig and bun since
| their inception, but, AI corp deep in the dev chain? I feel
| uncomfortable, because no one knows when they'll start steering
| things into weird directions.
| ignoramous wrote:
| > _AI corp deep in the dev chain? I feel uncomfortable ..._
|
| tbf, Google has long been an AI corp. The _Big Labs_ are
| trying to get in to other products /businesses just like
| Google did.
| phplovesong wrote:
| RIP Bun. I guess a bet on deno was the right bet.
| hu3 wrote:
| deno is VC funded which means enshitification is expected.
|
| It would be ironic if deno ended up having more builtin AI
| bloat despite Bun being the one owned by an AI company. But I
| wouldn't be surprised.
| simgt wrote:
| We're meant to all be 100x more productive with Claude Code but
|
| - Anthropic can't write its TUI app in anything else more
| suitable than Javascript
|
| - They feel the need to buy a portion of their software supply
| chain
| someguyiguess wrote:
| This explains why Claude started transpiling & running JavaScript
| code! Yesterday, when I asked it to generate a document for me in
| JavaScript, it generated the JavaScript and then ran it to
| generate a document. I had never actually seen it compile and run
| any code before. It only would ever output code and either use
| the shell (Claude code) to run it on my local computer or allow
| me to copy and paste it.
| informal007 wrote:
| Maybe they want to catch up the steps of Antigravity.
|
| Running code is absolutely going to happen for coding
| assistant.
| danirogerc wrote:
| Hopefully it doesn't push other LLM companies to go the same
| route.
| gaws wrote:
| It absolutely will.
| imjacobclark wrote:
| Owning your runtime is not about developer experience at the
| scale of Claude Code, it's about your execution-surface area and
| the control you have over it.
|
| Agentic systems are no longer just model-driven -- they are
| increasingly runtime-driven through tools, sandboxes, and
| orchestration layers. When agents are writing code, executing
| tests, calling external tools, and validating outcomes, the
| reliability of the entire system becomes a function of the
| runtime and environment, not just the model.
|
| Controlling the runtime gives Anthropic vertical control across:
|
| - Packaging and distribution - Execution semantics - Performance
| characteristics - Security surface area - Operational stability
|
| Of course, owning a JavaScript runtime does not magically make
| runtime deterministic. The dominant sources of variability still
| sit lower in the stack: OS behaviour, native dependencies,
| filesystem semantics, scheduling, hardware differences, and
| network effects. Runtime ownership is necessary, but not
| sufficient, for true runtime determinism.
|
| What this does signal is a strategic shift in where value is
| being captured.
|
| Model capability is no longer the only critical layer.
|
| The execution plane is becoming just as strategic too, can see
| this in ChatGPT 5's dynamic model routing capability as well as
| ecosystem wide Tool Calling and MCP adoption, which are all aimed
| at increasing LLM determinism through traditional software
| stacks.
|
| Vertical integration here looks far less like a tooling move and
| far more like a control-plane strategy: consolidate the stack,
| reduce dependency entropy, and shrink the surface area where
| behaviour can diverge.
|
| Intelligence may live in the model, but reliability, scalability,
| and trust are increasingly properties of the system that executes
| it.
| torginus wrote:
| So you're saying Anthropic is making it's own AI-based AWS,
| like OpenAI is trying to do AI social media?
| imjacobclark wrote:
| not quite, just the runtime above the os layer
| theodric wrote:
| That's nothing. I just bought four buns yesterday!
___________________________________________________________________
(page generated 2025-12-03 23:01 UTC)