zlacker

>>ryanvo+(OP)
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

>>dts+0D
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.

>>ok_dad+XU
Java can run anywhere too

>>yellow+mX
run code anywhere hamstrung by 90s syntax and hidden code indirections

>>throwa+RX
Haven’t checked in on Java in a while?

>>ground+m01
From what I gather everyone is still stuck on Java 8 so no need to check?

>>ozim+C71
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.

>>gf000+zc2
Not even latest Java is less verbose than Go.

>>the_gi+pe2
Are we talking about the language that has a couple extra lines after every statement, disguising as error handling?

>>gf000+kf2
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.

>>the_gi+3v2
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.

>>lenkit+Qw3
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.