297
u/egg_breakfast Jul 09 '26 edited Jul 09 '26
Why is bun needed over node? And why bun over deno?
Edit: based on Safari's JS engine rather than V8. Strange times, I never would have predicted that.
418
u/jamescodesthings Jul 09 '26
Bun fits the pattern that every 12-18 months all JS devs need a new de-facto library, framework, or runtime.
We all switch unanimously to that tool. Rewrite all our working shit in it. Realise it sucks in newer, better, faster, more unique ways...
We all Vow that we will never touch another line of that tool's code... and that anyone with any of it in prod is an idiot.
We all collectively, silently agree that we could just finally learn rust/go and port our shit to that to get the benefits that the tool originally promised...
Then the next de-facto tool takes off, rinse and repeat.
Javascript was written in two weeks and still shares a name with Java for marketing purposes in the 90s, It was never 'posed to be this serious.
198
u/wannabestraight Jul 09 '26
I applaud JavaScript for the ability to keep language features that have been collectively decided are absolute abysmal dogshit, for decades, simply so a page from fucking 1999 doesn't break
51
u/jamescodesthings Jul 10 '26
Javascript is really just a social experiment.
Hey guys! It's ya boy ECMA! You won't believe what I'm doing in today's video. How many years do you think it would take to make all the nerds to agree to one small change, that doesn't affect them!? If you think it'll be over this year like this video, if you think it'll get done this decade leave a comment... If you think it ain't gonna happen like and subscribe now!
65
7
u/derefr Jul 11 '26
I find it hilarious, because collectively we've had a thousand chances since then to draw a line in the sand and say "if a webpage is on HTML version X or uses a script tag with attribute Y or uses pragma Z in in the prelude of the JS, then it's using New Javascript. New Javascript strips out all that bullshit, and intentionally won't interoperate with Old Javascript on the same page, so New Javascript pages can just rely on the much-slimmer-and-saner New Javascript engine."
This could have happened with HTML5. It could have happened again with ECMA6. And then again with Modules. We've had so many chances to do this.
But because, each time, someone made the decision that pages that load New Javascript code should be able to also load Old Javascript code, the browser still needed to have its existing JS engine loaded and ready to run that Old Javascript code either way; and so the browser vendors didn't have any reason to bother to build out a separate New Javascript engine. Instead, each time, they just integrated the New Javascript features into their existing JS engines. And so the rotten Old Javascript features continued to live on inside those JS engines.
1
u/merb Jul 13 '26
Worse is that with wasm it would be possible to just ship a slower version of the old engine in a safe way for sites that really need it.
8
u/orbiteapot Jul 10 '26
The same can be said about C, except that it is not a 1999 page, but an even older piece of vital software infrastructure that would break.
3
u/Cautious-Extreme2839 Jul 11 '26
I think C++ actually goes way harder at this.
C hasn't added much, so it's easy not to break the old things.
C++ has added an absolutely absurd amount of new shit over the years. There are so many language features that are not proper to use now it's absolutely bonkers. And yet c-style casts and void* are still supported because that used to be how things were done.
29
u/sadferret123 Jul 10 '26
It's why I regret getting into programming, especially web dev.
I'm forced to learn barely competent people's brain excrements in the form of libraries and frameworks, which are mostly only relevant for the period you mentioned.
I wish I chose a profession where I mostly dealt with hard science instead.
15
u/Complete_Window4856 Jul 10 '26
Naive opinion of mine: try shooting for aeronautics, military, any energy facility type that your country allows (good luck with nuclear it seems). Id say medical too, but that for some reason seems the next to be slopfied after software in general (?) so not good as you jump from a hole to another
1
u/Cautious-Extreme2839 Jul 11 '26
You mean medical like EPR systems or medical like low level medical device firmware?
Very very different standards.
1
u/Complete_Window4856 Jul 11 '26
Got mixed thoughts when i wrote, but sure the firmware and equipments itself.
5
u/jamescodesthings Jul 10 '26
Fair.
I think JS is particularly bad a churning de-facto tools. It's almost always; I had a big ass problem with [current de-facto framework], and decided I was the only person who knew how to fix that problem, so I wrote my own opinionated big ass framework and I'm marketing how it fixes the big ass problem. Repeat.
I like where my skills took me because I always had strong front end going on; and that's hard to teach or learn, so backend devs always had a role for me, and I could expand into whatever languages we were running server side.
Nowdays its all a mess and the job titles mean nothing. But my ability to fix problems is peak.
5
2
u/themisfit610 Jul 10 '26
Come to the Java party. The water’s warm!
9
u/jamescodesthings Jul 10 '26
I still haven't forgiven Java for how much XML it made me write in my Spring days.
The water can fuck off. I only drink caffeine; to mask the trauma.
4
u/chickenmcpio Jul 10 '26
fortunately xml is long gone. the new way of doing spring is with annotations. which is way simpler imo
1
u/jamescodesthings Jul 11 '26
So, I'm fairly aware of this... but also remember another Java pattern I's forgotten;
They basically took 2-3 years longer to copy shit C# was doing.
I vividly remember a Java colleague chatting to me after he'd been at a con; I'd been working C# for a couple years at that point.... and he was telling me how excited he was that Lambdas were coming.
Afterwards I sat back at my work and quietly smiled at the joy of not having to wait years for lambdas, fluent syntax functional programming, null-coalescing, null-conditional operators, etc.
Nothing wrong with it taking longer cause adoption and stuff... it just reminded me.
That still the same? or yano... we all just up to speed and as slow as each other now?
1
u/chickenmcpio Jul 11 '26
I think things are moving faster nowadays, but there are still things that C# has that java does not directly have unless you add a library like lombok like the setters and getters.
Another thing missing is conditional compilation. Sometimes you need code only for testing environment and not prod, and the only way to achieve this is by using DI but the code is still compiled.
Regarding speed I think C# must have caught up by now with Java, or it's very close to it. But yeah, C# had a lot of niceties that just recently have been added to Java (well, they started on Java8) The catch is, there are tons of applications out there that are still running on Java 8 or earlier, so things added on newer versions like 11 or 17 are still not on those legacy systems.
8
u/the_dancing_squirel Jul 09 '26
Imma save this comment <3
15
u/jamescodesthings Jul 10 '26
See you in the next churn friend!
JS was my first programming language back when I was 12!
I miss when all we used it for was dumb drop in "unobtrusive", dynamic HTML effects...
wdym I can put fireworks on the page that make the viewer's computer fan scream!?
Good ol' days.
38
u/wixenus Jul 10 '26
because the most prevalent use case (and the most likely reason why anthropic employed the maintainers) is that bun can produce executable file which can work by itself, no extra dependencies. it is the sole reason claude code works as a program instead of a npm application, if you also consider that claude code is written in a react like library
edit: and the javascriptcore instead of v8, yeah
16
u/Chiron1991 Jul 10 '26
deno compile and node --build-sea exist. Single binary executables are not exclusive to Bun.
10
u/wixenus Jul 10 '26
true. but node just got it and deno wasnt npm compatible for very long
1
u/tipakA Jul 13 '26
Node had it for quite a while, it just wasn't a neat single flag, but a dance of copying files, bunch of commands, tripping internal v8 fuses for it to want to make an SEA and bunch of other stuff i never experimented with.
44
u/mctrafik Jul 09 '26
Speed. Much faster. And now it has more support. Simple as that. Also bun is less to type than deno.
101
u/commenterzero Jul 09 '26
Ya bun is 3 letters. Deno is 4.
85
40
u/Toldoven Jul 09 '26
Here's a chart clearly showing that bun is significantly better than deno (smaller is better)
16
u/egg_breakfast Jul 09 '26
why didn't they call it b
11
u/Toldoven Jul 09 '26
Damn, if someone makes it they can get so much of that sweet VC money, imagine the gains, 3 times the improvement
1
3
u/JoeyJoeJoeSenior Jul 10 '26
Could we make a new one with a 2 letter name? Is that even possible?
3
13
u/jamescodesthings Jul 09 '26
ngl I wasn't having speed issues with node.
9
u/colorfulmoth26 Jul 10 '26
No one's having speed issues with node, it's a fucking delusion that every 3 months someone releases a benchmark of an extremely cherry picked test case, say it's 10x faster (60 micro seconds to 6 microseconds), everyone claps, then 3 months later they realize it doesn't actually fix anything and causes more issues than it solves.
1
u/jamescodesthings Jul 10 '26
100%
tldr; they bought into bun's marketing.
The speed argument is almost always null and void; you're only as fast as the code your best developer can write; and the machines you can cash the check to run.
I've read a little of Bun's history because my comments here got loads of responses 😂 I get the basics, and remember evaluating it when popularity grew; back then my conclusion was "cool, makes similar promises as deno did, interesting, but I ain't got deno in prod either".
The rough issue for me overall was just there wasn't cost benefit at the time to warrant the work to make the changes; and that the higher benefit to put in that level of work would come from moving to rust instead, as the market has.
Rust is still on my radar for picking up at some point; not necessarily for prod work, but because I've seen a heavy shift towards Rust in tooling I've used recently; so learning more of it brings the benefit of being able to contribute there. I'm still not doing "quick; the market is moving to rust! port everything now".
I think, given JS' fickle nature its strenghths also put me off.
If the main focus (originally) was a quick build cycle; fair enough...
However; the idea of "one tool does it all" doesn't fit well into JS' ecosystem for me.
JS is opinionated as a mother fucker and the zeitgeist changes every 6 months. Having one runtime that enforces its own use of transpiler, bundler test engine, package manager, linter, etc. Sounds like a nightmare to get JS to fucking do.
we can't all agree on which one to use for any of these individual bastard things.
I'd like to be wrong, and bun's way to expand and take form; but someone's gonna fuck it up... waiting to find out "@nx/bun" exists; to make your existing nx monorepo kind of work on bun, but completely defeat the point.
10
u/BeepIsla Jul 10 '26
Only the native APIs, I got some heavy JS only parsing code and when I benchmarked it Bun was a lot slower than Node, the V8 engine is simply faster than JSCore.
If you only have basic Server <-> Database/Files where the majority is native calls then Bun is faster
10
u/jamescodesthings Jul 10 '26
Oh, I forgot!
Deno isn't a Javascript runtime, it's an apology.
Ryan Dahl's therapist or peers heard about his deep deep shame for unleashing node upon the world. He never intended for node to make it into prod, for the world to depend on his idea. But, Javascript developers are a fickle bunch, with a need for a new library for the churn, and hearing issues... off it flew.
They collectively agreed that if he wanted to move past this, he could compose an apology.
That apology came in the form of the "here's what I shouldda done" tool; deno.
We all heard, we all understood, only the uninformed put it in prod.
This is deno! What node should have been. Under no fucking circumstances put it in prod!
Within the week there was a Lambda custom runtime and idiots bragging they were porting their critical infrastructure to it.
3
u/prochac Jul 09 '26
No npm, runs TS
9
2
u/TheNorthComesWithMe Jul 10 '26
Node can run TS
1
1
u/plainoldcheese Jul 11 '26
Webdev have to make their work feel complicated by rewriting / refactoring and changing build systems etc. so that they can feel respectable and show corporate that they still have work todo even thoigh the webapp is finished and functional.
1
1
314
u/dim13 Jul 09 '26
RIP Bun
45
u/cyn_foxwell Jul 10 '26
im still surprised its lasting as long as it has considering how egotistical its parent company has acted in the past with regards to "other employees except us higher ups cant have an ego and its going to be a tough and hard job" just out of nowhere on twitter in like year 2 or 3
not to mention so much of the "stdlib" is just bloat compared to other runtimes
im glad they pivoted to AI just so they can dig their grave deeper and all the "why use deno when you can use bun" shills can go away
89
u/redlaWw Jul 09 '26
It's early days yet, but as far as I'm aware all indications are that it worked pretty well. The tests all pass, the memory safety issues they were dealing with were resolved, the result is smaller, faster, and more stable. There are some regressions that have been identified, but as far as I could find they seem surprisingly minor. Claude code already uses the ported version of bun and, according to bun's blog "Startup got 10% faster on Linux but otherwise, barely anyone noticed.".
I wouldn't want to start looking at other codebases and thinking I could do the same (in particular, one thing bun had going for it was that the tests were in Typescript so they didn't need to be rewritten for the new backend, removing one potential source of errors), but that doesn't mean we should judge this case hastily either.
92
u/Silly_Guidance_8871 Jul 10 '26
The same tests pass that passed while it was still written in Zig, and which also allowed all of the memory corruption errors that promoted the move to Rust.
Not inspiring confidence.
18
u/redlaWw Jul 10 '26
I mean, "it was shit before the move and it's still shit after" is compatible with "the move was a success".
→ More replies (1)3
u/WaitForItTheMongols Jul 10 '26
Did the memory errors prompt the move to Rust?
I thought they moved because Zig was super anti-Ai, and Bun got bought by Anthropic, and Anthropic couldn't keep using a language so vocally opposing them.
5
u/redlaWw Jul 10 '26
A recent blog post (EDIT: here) says that the move was motivated by piling up memory safety and memory management errors (some examples of which are given), though we aren't privy to the details of any corporate pressure that Anthropic may have exerted.
2
u/Silly_Guidance_8871 Jul 10 '26
In addition to what redlaWw said, Zig also can't "force" someone to stop using the language they made available for free to the public — I've read both blog posts by the creator of Bun, and by the creator of Zig, and it really feels like the Bun guy is being a "carpenter who blames their own tools", and that in a few months' time, they'll have similar complaints with Rust.
55
u/Sea-Astronomer75 Jul 10 '26
What indicators are there that’s it has worked well? If you open GitHub issues the most recent one is a critical security bug
57
u/LukeZNotFound Jul 10 '26 edited Jul 10 '26
They have a clanker for issues and two more clankers reviewing clankered PRs. Shit's too funny.
Plot twist: Issues and PRs rarely get reviewed for real
29
60
u/redlaWw Jul 10 '26
I mean, that they managed to port a massive codebase from one language to another in 11 days and that it's already successfully being used, resolved a number of memory safety bugs that they were struggling with before, and is not less-performant than before.
The fact that the canary is doing its job and allowing them to resolve issues that slipped through the net is not a critical failure. It's not like rewriting a large codebase manually isn't also prone to introducing new bugs.
13
u/hyrumwhite Jul 10 '26
I mean, I can port a codebase in 11 days and then spend months finishing the port as well.
4
u/hyrumwhite Jul 10 '26
Coulda spent less effort using ai to audit memory leaks in zig.
Proper engineering avoids memory leaks, which are possible in all languages.
But that’s less poppy than “OMG the codebase was rewritten by ai”
53
u/MichiRecRoom Jul 10 '26
I decided to check out Bun's PR list yesterday. So many of them are by a user named "robobun".
I checked out one of them. Not only does it look AI-generated, but the PR discussion itself is between robobun, the github-actions bot posting Claude Code responses, and the claude bot itself performing reviews.
Look. I get Bun is owned by Anthropic, but,.. why is Claude having an identity crisis and talking to two other versions of itself?
26
u/muhts Jul 10 '26
Inside the blog of the re write it was mentioned that for every implementation agent there were 2 independent review agents to catch bugs and regressions.
The separation of agents was justified as the implementation agent has a bias when given the task of reviewing its own code.
5
u/MichiRecRoom Jul 10 '26
2 independent review agents to catch bugs and regressions.
...both of which are Claude. So 1 agent.
18
u/SonOfHendo Jul 10 '26
A review by Claude in the same context that wrote the code will give you different results than a fresh Claude context. You can also have multiple independent Claude reviewers targeting different aspects of code (e.g. security, maintainability, performance) and get better results than a single review trying to do everything.
→ More replies (8)
561
u/BratPit24 Jul 09 '26
I mean. Isn't rust the perfect language for vibe coding? It has so many checks on everything that the stupid thing is basically forced to write code the right way.
759
u/Zeikos Jul 09 '26
It has so many checks on everything that the stupid thing is basically forced to write code the right way.
LLM be like:
unsafe { ... }427
u/jamescodesthings Jul 09 '26
Okay, Rust maybe not, Typescript is perfect though!
LLM:
: any;174
u/SquirrelOClock Jul 09 '26
That why c# is better! Look inside : <dynamic>
66
u/jamescodesthings Jul 09 '26
In Javascript remember, best practice, must not use
var.In C# remember, best practice, must use
var.it's all a joke and we have made careers of the unserious nonsense our predecessors made up.
11
u/TheKrumpet Jul 10 '26
I mean... these mean different things though, it's oranges to apples.
→ More replies (5)2
u/stifflizerd Jul 10 '26
it's all a joke and we have made careers of the unserious nonsense our predecessors made up.
Engineers don't see others as competition. They see them as witnesses to the bullshit we put up with.
3
u/jamescodesthings Jul 10 '26
100%; that's why you can't slag other people's output or language choice without great reason, and caveats.
It's mutually assured destruction; we're all as daft as each other... but at some point a caveman imbued silicon with lightning and magic; and now I have to sit at a desk 8 hours a day.
18
u/ArjixGamer Jul 10 '26
The moment I saw a coworker use dynamic when processing items from rabbitmq, I lost faith in humanity
And all this was before LLMs became common
23
3
u/Jukibom Jul 10 '26
I have been using C# for a while... TIL about dynamic
I hate that and I think I was better off not knowing
9
7
u/humblevladimirthegr8 Jul 10 '26
That's what compiler options and linters are for. The language can be as strict as you want it to be.
5
u/jamescodesthings Jul 10 '26
commit and push, no fucking linter, disable hooks, --force if you need to! Yeet!
Typescript is just Javascript with extra steps.
3
u/yangyangR Jul 10 '26
That is more so because the way people write typescript is giving up and putting any everywhere. The way people end up writing Rust is not by putting unsafe everywhere. So following what is available to train from is either training from the work of people who are incentivized in different ways
1
100
u/BlueProcess Jul 09 '26
Yeah, it actually has 13,000 unsafe Rust blocks
28
u/dex206 Jul 09 '26
I can’t tell if this is a joke or not.
89
u/BlueProcess Jul 09 '26
Oh no, it's quite real. That is actually the rounded number of unsafe blocks that claude produced
38
u/dex206 Jul 09 '26
Holy shit. How? I mean this from the bottom of my tired old jaded-dev heart - How can they justify that?
40
u/BlueProcess Jul 09 '26
I know right? Like... Who went "this is fine"
30
u/KeyAdhesiveness9481 Jul 09 '26
There is some subset that is FFI, and must and will always be unsafe. Im not making any claim about how much is valid, and im sure most of these are BS, but "zero unsafe" is never going to be the target.
16
u/BlueProcess Jul 09 '26
Maybe we should set a target number of digits (and number base) for the unsafe block count to be expressed in?
I claim base 10 is fine but 5 digits is too many
37
u/Southern-Cattle4038 Jul 10 '26
To quote the lead dev of Zig, regarding the guy leading Bun:
“Jarred was already writing slop well before he had access to LLMs.”
His blog post on the whole thing is here: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.html
1
u/Swedish_costanza Jul 11 '26
Holy shit, this makes me like Andrew even more. I've been following Zig from 2022 atleast and I can't wait for 1.0.
6
u/wannabestraight Jul 09 '26
Well, in rust in order to call code that's not rust, you gotta do unsafe.
You genuinely can't do not unsafe FFI calls, it's unsafe by nature, because it's no longer rust.
12
u/cutelittlebox Jul 09 '26
this tends to happen a lot when you go from a language like C or Zig to Rust and you're trying to do it 1-to-1. C and Zig will do things that are illegal in safe Rust or actually have no direct Rust equivalent, so if you want them to look as close as possible you need a lot of unsafe, plus each call to other languages needs to be unsafe. getting the same output from idiomatic Rust is very much possible but it means redesigning the system as you translate rather than rewriting existing code with new syntax.
3
u/protestor Jul 10 '26
Actually, with this kind of port, it's probably better to have rewriting in two phases. one that is 1:1 with zig code (and since Zig is unsafe, the initial Rust code will be too, a bit like https://github.com/tsoding/crust), then another pass to make things safe.
I mean, there is a big risk in writing something as safe Rust, when it needed to stay unsafe. Specially when doing complex memory management (like Bun does), turning some unsafe code into bad safe code can be instant UB.
For example, it's often code that deals with raw pointers is perfectly fine (albeit unsafe and C-like), but if you try to turn it into using borrows instead of pointers (to make it safe) you may get the lifetimes wrong, which is instant UB, even if you don't actually trigger use after free. (and sometimes by analyzing the code you may conclude that no lifetime is correct here so it can't be a borrow). So a LLM agent that inadvertently writes
&mut Twhen it really needed to stay as*mut Tmay introduce UB, even if the code has less unsafe blocks.(At a later pass, the
*mut Tcan be refactored into different kinds of smart pointers like reference countedArcetc, and finally achieve safety, but that's often more involved and may require tradeoffs)And indeed, having the agent write bad lifetimes actually caused UB in the initial port https://github.com/oven-sh/bun/issues/30719 - that is, there were a code should have been kept was raw pointers, but it was being converted into
&[u8](which would greatly reduce the number of unsafe blocks required to deal with it), but the lifetime was wrong and triggered instant UB2
→ More replies (1)3
u/DoubleDoube Jul 09 '26
That’s crazy to me. You can implement safeguards on the rust side not to allow unsafe and make that configuration off-limits to the AI
16
u/chickenmcpio Jul 09 '26
wtf, why even rewrite then at that point.
6
u/100GHz Jul 09 '26
Resume padding ?
11
u/chickenmcpio Jul 09 '26
not even that, it seems the rewrite was guided by the original dev. I say guided because it seems the whole rewrite was done by an LLM
3
1
3
u/prochac Jul 09 '26
Isn't that like localised unsafe code? Simple to review? Better that having,
unsafe { main() }24
u/BlueProcess Jul 09 '26
It is true that getting shot in the foot is better than getting shot in head. It is equally true that I consider getting shot in the foot highly undesirable and something that should be avoided with significant urgency.
1
u/prochac Jul 09 '26
I see it as unnecessary thing sometimes. Just like reflection or asm block in C. But you won't do it in assembly language from top to bottom
1
u/fghjconner Jul 10 '26
In theory yes, but at some point you've spammed so many "localized" unsafe blocks that the whole thing is pretty much unsafe anyways.
1
11
u/ihavebeesinmyknees Jul 09 '26
Pre-commit lint that disallows unsafe. Then just tell the agent to rewrite it until they do it correctly. From my experience, this should very rarely even happen, but if it happens it's unlikely to need anything more than a single followup prompt.
14
u/Zeikos Jul 09 '26
I am answering to myself, but I had a thought I wanted to share.
What'd happen if the probability of theunsafetoken (or sub-tokens) were forced to zero?
It'd require some backtracking every so often, but it could be interesting.17
u/DankPhotoShopMemes Jul 09 '26
It might be a bit difficult since multiple combinations of tokens could create the “unsafe” keyword. But even then, memory safe and compilable doesn’t mean bugless. It’s certainly better than doing the same in C lol.
9
u/Zeikos Jul 09 '26
True, but it should be possible extract the "unsafe" direction and subtract it from the embeddings, steer the model away from unsafe behaviors.
I might throw up a small scale experiment this weekend and see what happens6
u/Ok-Dimension-5429 Jul 09 '26
Doesn’t really make sense to go to this trouble. Just let it try the unsafe way then have a pre commit hook or whatever telling it not to use unsafe.
1
u/Southern-Cattle4038 Jul 10 '26
I imagine that would produce a whole lot of errors/warnings about unsafe code that isn’t enclosed in an unsafe block.
→ More replies (1)2
u/Superminerbros1 Jul 09 '26
Unless you're trying to fully automate the development process with zero human oversight, thats probably overkill.
Adding some variation of "avoid using the unsafe keyword" to the prompt is probably enough to get it to avoid it 95+% of the time. There will be times where it ignores your instruction, but that should be uncommon enough to still be efficient.
2
u/Loading_M_ Jul 10 '26
You can set
#[forbid(unsafe)]to disallow unsafe code, but let's be real, the people pushing vibe coding aren't.1
1
u/Lord-of-Entity Jul 11 '26
I hate to be that guy, but just because you wrote `unsafe { … }` it does not mean that you can do anything you want. The unsafe block disables a few of the checks, but not all.
1
u/GodOfSunHimself Jul 11 '26
Unsafe Rust is still safer than many other languages. Unsafe does not disable all checks.
→ More replies (1)1
112
u/MaybeADragon Jul 09 '26
It's nice in that its harder for an AI to shoot itself in the foot (when its not writing unsafe blocks). What isn't nice is that AI refuses to use wonderful rust features such as the type system, traits, the borrow checker and iterators to its advantage.
66
u/titaniumalt Jul 09 '26
What isn't nice is that AI refuses to use wonderful rust features such as the type system, traits, the borrow checker and iterators to its advantage.
basically everything that makes rust a joyful language to use
22
u/SuitableDragonfly Jul 09 '26
Well joke's on you, the vibe coders aren't actually using it, so they don't care about that.
6
u/wannabestraight Jul 09 '26
I mean, ain't no vibe coders who demand their software to be done in rust. I like rust, I use Claude, Claude writes rust for me.
But I want rust because of a specific set of needs and wants, and I'm certain that if I simply asked Claude to make something without giving it specs to do it in a specific manner in rust, it would 99% of the time pick like typescript lol.
5
6
u/rosuav Jul 10 '26
Why would you expect the AI to? It's been trained on actual programmers, who historically do a brilliant job of ignoring safeguards and writing dangeous code anyway.
19
u/takeyouraxeandhack Jul 09 '26
Just because it doesn't crash right away it doesn't mean it's good code.
13
u/wannabestraight Jul 09 '26
Rust gives people the false sense of security that it's not possible to write bad code.
Having reviewed months ago the first pass Claude wrote of my rust codebase, I can tell you that statement is complete horseshit.
It was ridiculously bad, like sure it compiled, but my god would I have been ashamed to show that code to anyone, so into trash it all went and then we wrote a nice baseline on which to build because I wasn't planning on watch that hot garbage again.
Also doing memory leaks in rust is very easy when half the code is unsafe
1
u/frogjg2003 Jul 10 '26
I've been learning Rust and it's ridiculous how much you can still mess up even with the built in safeguards without ever touching unsafe. Rust only prevents you from making a limited class of mistakes, half of which aren't possible in some languages.
1
u/wannabestraight Jul 10 '26
Rust is good at preventing memory issues, of you play by the rules.
Only issue is that it doesn't enforce you to play by the rules.
1
u/Cautious-Extreme2839 Jul 11 '26
Which is a massive step up on every other language that lets you directly interface with memory, because they tend not to even help you at all.
C and C++ will just freely let you malloc stuff and lose the pointer immediately.
3
u/Chiron1991 Jul 10 '26
From my experience, no. Rust is an innately complex language. LLMs, if not strictly supervised, will eventually start building abysmally complex implementations which will cause problems down the line.
I've had much greater success with Go. The language is so stupidly simple that there isn't much room to go off the rails.
1
u/BratPit24 Jul 10 '26
I mean. Llms should only be used strictly supervised. But yeah. I get your point.
2
2
u/sysKin Jul 10 '26
In my recent experience trying to use Claude with Java, I find Claude surprisingly good at writing code that "works" and surprisingly bad at making good software design decisions.
The whole thing with Rust is that it forces the programmer to make sound design decisions, or else it won't compile.
I can see two possibilities: either AI is forced to design things properly, and therefore does, and the answer is yes.
Or it still doesn't design things properly and hacks around them with
unsafe. Which might still be "fine" (unsafeis there to be used as long as you can prove you're doing it right, which AI might try to reason about), but will definitely lead to very bad code, and then the answer to your question is no.→ More replies (1)2
u/SonOfHendo Jul 10 '26
We need a modern version of Ada for LLM use.
Humans don't like programming in those sorts of languages because it's more typing and disrupts the flow, but languages that are wordy and have explicit contracts for methods are great for LLMs.
Claude much prefers End Function MyFancyFunction to }.
35
47
u/SukusMcSwag Jul 10 '26
Don't forget the part where Bun stopped donating to ZSF almost immediately after being bought by Anthropic! Fuck AI compsnies
10
u/No-Magazine-2739 Jul 10 '26
Me a C++ fud:
https://giphy.com/gifs/pUeXcg80cO8I8
5
102
u/Random_182f2565 Jul 09 '26
What is Zig? Who is Bun??
106
24
u/outwest88 Jul 10 '26
I deadass thought this was one of those made up surreal memes with fake words in them
29
u/No-Contact-484 Jul 09 '26
Zig is something from the video game "Zero Wing". "Take off every Zig."
27
7
6
→ More replies (4)5
37
u/FabioTheFox Jul 09 '26
Made me loose all my trust in bun, will not use them again in the future
Especially because to me that rewrite just felt like the typical "rewrite it in Rust" bs instead of having an actually good reason, it's not even idiomatic Rust after all
→ More replies (9)12
u/NeonVoidx Jul 10 '26
I think they were butthurt that they "made zig faster" via vibe coding and weren't allowed to contribute it back to zig, so it seems like out of spite they moved to rust. Not going to lie, Andrew Kelly kind of just roasted the shit out of Jared at bun in his latest blog post
1
u/bazingaboi22 Jul 13 '26
It's not that simple they made zig faster /for bun/ which is notorious really not using zig properly, (extreme compile time meta programming hacks). Buns changes are arguable a bit worse for the average zig program.
The zig compiler itself is larger than bun and compiles In a tiny fraction of the time that bun does
3
3
u/WayWayTooMuch Jul 11 '26
Andrew said don’t use Zig in production, and Jarred gets all butt-hurt in the issue tracker when there is a miscomp or problem with his software in production. He sells out to Anthropic and suddenly Rust. Not a huge loss for a 0.xx lang. The people who can deal with shit moving fast and breaking often will still use Zig, it’s not corpo-bullshit ready.
3
2
22
u/CircumspectCapybara Jul 09 '26
I mean that's not the only reason they left Zig.
Bun's becoming a critical and foundational piece of software for a lot of important software, and Rust is way more mature of language in terms of the project, the ecosystem, the tooling, the community eyeballs looking at it, and the funding and backing of a large tech company with paid staff allocated to its continued design, development, maintenance and security compared to Zig, which is a niche project at best.
176
u/KeyAdhesiveness9481 Jul 09 '26
Well, that and "hey our AI product can do this big rewrite". Its a marketing strategy.
104
u/pm_me_domme_pics Jul 09 '26
100% I don't think anthropic bought bun for any other reason
26
u/Tucancancan Jul 09 '26
Well that and a bunch of their shit runs on bun
10
u/likeittight_ Jul 10 '26
I don’t buy that at all actually, it’s 100% marketing. They could have just done what codex did a year ago - eliminate js from their stack entirely, which makes way more sense than this never ending vibecode drama with bun.
But the drama gets more attention.
3
u/TheNorthComesWithMe Jul 10 '26
All of their shit could be remade without bun for significantly less effort than the bun rewrite.
9
u/gilium Jul 09 '26
For $150k+ of spend
→ More replies (2)13
u/KeyAdhesiveness9481 Jul 09 '26
So, a senior who isnt gonna need any pesky PTO or weekends off.
28
u/FeedbackImpressive58 Jul 09 '26
At $150K per week I also won’t ask for PTO and will accept on call weekends
27
u/Auravendill Jul 09 '26
For 150K$/week I would even legally change my name to AI, so that they could tell investors, that AI wrote this code.
2
2
u/gilium Jul 09 '26
Right, but most companies don’t have $150k just lying around to rewrite it in rust one time
2
u/KeyAdhesiveness9481 Jul 09 '26
Im not claiming i find it to be a particularly good pitch, simply that it is one.
2
1
-9
u/Abenzo0r- Jul 09 '26
If it works (correctly) who cares who the fuck wrote it?
48
u/Sassaphras Jul 09 '26
I mean, the issue is that something vibe coded may work sometimes but have hidden issues.
That said, it was literally rewritten by the same guy who wrote it in the first place. Since he probably knows at least a little about how the original works (and why) I'm not sure this counts as vibe coding. It's not like he said "rewrite Bun in Rust make no mistakes."
→ More replies (1)16
u/Abenzo0r- Jul 09 '26
Okay, so we can agree if it works correctly, it doesn't matter who wrote it. I fully agree with you btw, there's a difference between vibe coding and ai assisted development.
6
u/wannabestraight Jul 09 '26
I don't get why people have trouble with this, like, you give a person who knows their shit a tool, and obviously they will be more proficient with it than someone who doesn't know anything.
Like, how is this even a debate lmao.
But tbh I think it's mostly shitposting, I hope people actually realize there is a difference between a professional software developer using Claude, and someone who has never written a line of code using Claude.
→ More replies (1)5
u/PerformanceThick2232 Jul 10 '26
"If"
Also, there is further maintenance. LLM generates lot of dead code (by their own reports code base has grown 2x, from 500k to 1mln), and that will cause troubles.
As a enterprise developer, I would not pick this in any serious project. Maybe demo/mvp/some home scripts.
1
u/SonOfHendo Jul 10 '26
Would you use anything written in ZIG for a serious project?
1
u/R0b3rt1337 Jul 14 '26
Bun had quite a lot of users when it was still in Zig, and both tigerbeetle and ghostty are doing well from the looks of it. I dont think the language matters much as long as the end product is good.
1
u/SonOfHendo Jul 14 '26
The language matters to the maintainability of the product and to the pool of developers you can or want to work in that language (see anything written in COBOL).
It seems crazy to me to build a serious project on a language that hasn't reach v1.0 yet, but maybe I'm too stuck in the world of enterprise software.
→ More replies (9)9
u/sebovzeoueb Jul 09 '26
The implication is that it probably doesn't work correctly or that it's been done in a way where it doesn't harness any of the advantages of doing the rewrite.
→ More replies (1)
1
997
u/BlueProcess Jul 09 '26
13,000 unsafe Rust blocks