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...
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?
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.
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.
> Our default answer was always some version of "we'll eventually build a cloud hosting product.", vertically integrated with Bun’s runtime & bundler.
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.
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!!
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.
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.
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.
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)
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.
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.
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).
<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!
you could also run java with js if you are brave enough https://kreijstal.github.io/java-tools/
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.
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.
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?
By contrast `bun install` is about as good as it gets.
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.
There was recently a conference which was themed around the idea that typescript monorepos are the best way to build with AI
Makes me wonder what a theoretical “best possible language for vibe coding” would look like
As far provenance, I assume a lot of them were made up too, but this one was real.
> 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.
This is only true for older .NET Framework applications.
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.
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?
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.
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.
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.
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.
Plus last time I checked Oracle lost that lawsuit.
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.
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.
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
To be honest, that sounds more like a pitch for deno than for bun, especially the “paranoidly sandboxed” part.
How many mass security incidents have there been with npm just the last few weeks?
I tell the LLM to include typing on any new code.
The agent is running the test harness and checking results.
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.
But the majority of projects are on a newer JDK than 8 for quite some years now.
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.
I mean would it have made sense to acquire golang if it were on sale?
Gradle is better from this perspective, and hopefully with its "kotlinization" we will see some stability, which was the biggest issue it had before.
That's not true, if anything, C# is faster and also compiles fast enough.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
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.
Otherwise they’d be building these types of things in Rust.
Java is the running joke of verbosity, and you are too if you seriously argue that it's not.
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.
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?
That's all that's needed to create a sense of caution for would-be adopters.
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.
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.
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.
Why wouldn't I choose java
It has similar bases on facts.
Clever!
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
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.)
What about people who do not own a TV
Legally the case was about copying declaring code from a proprietary product, not an open source one.
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.
Now if you complain about slice handling, I'm with you.
I left a place using Java to run edge apps and the footprint was a major issue.
The implications of a judgment in favor of Oracle were staggering. Any codebase that is extensively dependent on a proprietary API is legally locked in to using that company's proprietary implementation as long as that company asserts copyright on its API. Anyone who implements the same API to offer a drop-in alternative to the proprietary product is infringing -- even if a someone privately reimplements the API without distributing the reimplementation.
Which immediately implicates WINE (Windows), Mono (.NET), ReactOS (Windows), Darling (macOS/Darwin), GNUStep (Cocoa/OpenStep), Anbox (Android), Ruffle (flash), GNU Octave (MATLAB), Mesa 3D (Direct3D), ZLUDA (CUDA), and DXVK (Direct3D 9/10/11), to name a few of the most popular...
You declare your schema with a good TS ORM then use something like TRPC to get type inference from your schemas in your route handlers and your front end.
You get an enforced single source of truth that keeps the AI on track with a very small amount of code compared to something like Java.
This really only applies to full stack SAAS apps though.
These famous cases set the legal tone for the entire world actually.
Idiomatic, Modern Java is written quite differently. Today, Go has a lot of arcane, noisy, complex code too. Ex: many, many k8s Go projects.
To this day Android Java is not fully compatible with Java proper, and Kotlin became Google's version of C#.
Reimplementing an interface != stealing code.
People end up choosing something that has batteries included so they can focus on solving business problems. A programmer who will superficially understand SpringBoot without understanding how it works. Really, there is no magic there - its a few core concepts - annotations, bytecode enhancement and dynamic proxies. Maybe Im missing one or two. Everything else is built on top of this.
This is regardless of language/ecosystem. If I do not understand the fundamental concepts, I will never be successful in that ecosystem.
But that's like saying that a bicycle is better than a car, because the first is simpler to understand. (At the same time, nothing prevents you from assembling a bicycle in Java if that's indeed what you need. But for general long distance travel you are better off starting with a car frame, aren't you?)
It's nice to be able to see what your changes do without rebuild and restart.