The whole "AI is enough" marketing that the author mentions in the conclusion is total poison. A buddy of mine works at one of the companies involved in this circlejerk and they have the same mandate. Cost is not an issue. Use it for everything.
He said he has to roll the dice all day to get good output from the AI. Its more important they USE THE AI than it is that they PRODUCE GOOD CODE. In fact "good code" is not a thing, in the traditional sense. "Good code" means AI created. His actual title ostensibly has nothing to do with AI, they are producing a totally different thing. But since he works at a company that is benefiting massively from AI investment, his bosses are mandating a worse form of developing because they are now in the business of selling AI rather than what presumably is the product.
It's like if you were a plumber and your plumbing company merged with a huge factory that makes 90 degree pipe elbows. So they mandated that all plumbing now had to be done by joining together nothing but 90 degree pipe elbows rather than any other fitting. And since its all going to be sealed up inside a wall, who cares? How dare you question this? Are you saying there AREN'T legitimate uses for 90 degree pipe elbows?
We are at an infection point with software. Similar to AWS was about fifteen-twenty years ago, or git. If you ignore it, you're behind the curve. Now's the time to experiment, figure out the good and bad. Not all orgs are going face first. Some of us are learning along with it.
Where it shines for me? Really small changes in a complex system. I can't store all the context all the time. Business requirements, security ones, aesthetic ones. Where it shines is if you suss out small changes thoroughly, it's a great text generating engine.
All of that said, the side effects of data centers and pump and dump stocks, are absolutely horrid. Hopefully on the other side of it we come to something more sane.
You can learn how to use AI coding tools in a week at most, and there's no telling if next week they'll be a new harness or loop or whatever that becomes the new trend, making everything you've learned so far obsolete. Nobody's being left behind. AWS also isn't hard to learn if you've done the similar infrastructure stuff yourself. And git isn't hard to learn if you've used other version control systems.
And that's the point. You don't have to consume everything all the time w/ AI/LLMs. But if you don't pay attn, 1) You'll likely make mistakes on things which didn't work out, like zero-shot prompting, or which models do better on which languages and 2) you'll have to play catch up.
On git? Did you know git would have won over HG, or Fossil? What about using git submodules, or bisect? You can do the research now that I wrote it out, but would you have known about them before hand? What about all the hook features?
And git can be hard, esp if people around you don't know it as well as you do, or people above you know it better than you do. Which again is a problem of people getting in way too late.
From my experience, AI-assisted development is not good at complex systems. If a feature or fix requires a lot of changes in different places, or if the business logic is complex and difficult to understand, then the AI usually, in my experience at least, doesn't do a good job with it. And because the system is large/complex, you have to have a correct understanding yourself of how the system works if you want to know if the AI changes will actually work as expected, and what edge cases it addresses and omits.
Absolutely. The great thing is you can ask ton of questions quickly to build your own knowledge quickly. It makes you faster not by doing the understanding for you. It can write tests to prove things pretty quickly. It can help find connections. Not fool proof ever, but it speeds up searches in your code base.
for anyone like me who could not understand that stupid title
"Call a spade a spade" is a figurative expression. It refers to calling something "as it is"[1]—that is, by its right or proper name, without "beating about the bush", but rather speaking truthfully, frankly, and directly about a topic;
"Blow smoke" - to speak idly, misleadingly, or boastfully
Bun’s founder experimented with a massive agentic rewrite from Zig to unsafe Rust.
That experiment was merged days later and is now the official version.
Wait, they ai yolo from a memory safe language to an unsafe version of a different memory save language?
yes, but when you make a port from one language to another, usually you want to rewrite it as a translation first, then refactor later with the features that language provides. A port that refactors everything in the first release is too risky.
The fact the translation has unsafe blocks only demonstrates the Zig version is not really safe as per Rust standards.
It depends on where exactly that 5% lies. If it's in the core API that's used by the rest of the architecture, it essentially makes the whole codebase unsafe when used irresponsibly.
I don't know if that's the case here, just pointing out that the 5% doesn't mean much.
Not exactly. It means that any of the code could lead to memory unsafety, but it's still better than Zig or C because you still only have to read 5% of the code to debug/fix those issues, instead of 100%.
5% is clearly better than 100%. Whatever else you think about this port you can't argue against that. In fact I can prove that it's better.
Does Rust's memory safety design improve memory safety? Yes, this is proven by experience (e.g. see Google's blog posts).
Does "normal" (not slop) Rust code rely on someunsafe? Yes. All Rust code must use some unsafe because it's used in the standard library, and even if you ignore that (there is an effort led by Amazon to formally verify it), it's usual for Rust projects to use at least some unsafe. Let's say 0.1% of lines.
So 0.1% unsafe is clearly better than 100%. Is it possible for 0.1% unsafe to be better than 100%, but somehow 5% isn't? That would require things to be non-monotonic which is completely implausible.
I'm sorry, but since we're being pedantic, this is not a proof. It's full of assumptions, some of which are wrong.
5% is clearly better than 100%
Never denied it. 0% is even better. What matters is where it's used. If it's used for FFI, that's understandable. Any other use should be scrutinized more. And that's the issue. The claim of Zig's creator is that the devs of Bun are not reliable. And to me at least, his arguments make sense.
it’s usual for Rust projects to use at least some unsafe
Doesn't seem like it. This article claims that only about 20% of Rust crates use unsafe at all. Even among those, the vast majority use it for FFI, which is kinda unavoidable.
but somehow 5% isn’t
Again, no one claimed that. But we need more than "better than 100%" when it's a JS runtime. And the "better"ness isn't necessarily linear. So, even though it might be technically "better", it might not be by much. At that point, what even is the point of the rewrite?
Again, I'm not claiming that it's actually badly written. I'm only claiming that your arguments are not adequate, and that Bun is not a reliable company, so take whatever they claim with a grain of salt.
So it is a reaction to Andrew Kelley’s reaction to bun / anthropic blog post that in their case was reaction to dev community reaction to sloppy rewrite from zig to rust with ai?
This is soap opera level drama. "It was a toxic relationship and we're happy they are gone".
I get it, they made you look bad when they were using Zig and they made you look even worse when they switched. It's just sad that software projects have to deal with issues like that instead of just focusing on engineering.
It's more that most people would only associate them with that one project. It's not as bad as it could be, but for instance in the Ruby world everyone just thinks of Rails and, if they're aware of it, the main guy behind it flirting with white supremacy
I think Rust was lucky no to get assassinated with just one app. It was created around the same time as Zig and 15 years after Ruby but it feels like its development is more mature. A lot of haters but few dramas.
Bun is a TypeScript runtime, like a faster NodeJS.
I guess the target audience is non-coding AI skeptics looking for pseudo-intellectual takes, which appears to be a growing market. Because getting the very first technical detail, and a very basic one at that, this wrong is not a good look.
First of all. Strictly speaking, there is no such a thing as a TS runtime. TS compiles to JS.
Second of all, bun binds against JavaScriptCore, which is the JS engine used in Safari. Node binds against V8, which is the engine used by Blink (Chromium et al). Both are implemented in C++. And the latter is considered the fastest engine.
Ironically, both engines are mentioned by name in the very bun blog post being discussed, which points to a problem that is almost bigger than mere tech literacy from the pseudo-intellectual OP.
Saying there's no typescript runtime is (imo) a bit pedantic - if you JIT transpile TS down to JS at run time with hot-reloading you're effectively a TS runtime. For a non-technical one-liner on Bun, I feel that is a very reasonable simplification to make.
Perhaps bun would be even faster if they bound against another JS API, but that doesn't mean that Bun isn't faster than Node.js. They claim it's 3x faster than Node in aggregate, and that can potentially be true even if they use slower machinery under the hood. Python is a slow language but a fast framework can outperform a poorly written C++ implementation.
I'm not going to defend the article, I have no horse in that race, but until I see benchmarks that say Bun isn't faster than Node in aggregate, I don't think the claim can be called "wrong" on its face.
E: that's exactly what Bun does: "Bun supports TypeScript and JSX with no configuration. Bun transpiles every file on the fly with its native transpiler before running it."
33 Comments
MoonMelon@lemmy.ml · 71 pts · 42d
The whole "AI is enough" marketing that the author mentions in the conclusion is total poison. A buddy of mine works at one of the companies involved in this circlejerk and they have the same mandate. Cost is not an issue. Use it for everything.
He said he has to roll the dice all day to get good output from the AI. Its more important they USE THE AI than it is that they PRODUCE GOOD CODE. In fact "good code" is not a thing, in the traditional sense. "Good code" means AI created. His actual title ostensibly has nothing to do with AI, they are producing a totally different thing. But since he works at a company that is benefiting massively from AI investment, his bosses are mandating a worse form of developing because they are now in the business of selling AI rather than what presumably is the product.
It's like if you were a plumber and your plumbing company merged with a huge factory that makes 90 degree pipe elbows. So they mandated that all plumbing now had to be done by joining together nothing but 90 degree pipe elbows rather than any other fitting. And since its all going to be sealed up inside a wall, who cares? How dare you question this? Are you saying there AREN'T legitimate uses for 90 degree pipe elbows?
exussum@lemmy.world · -12 pts · 42d
We are at an infection point with software. Similar to AWS was about fifteen-twenty years ago, or git. If you ignore it, you're behind the curve. Now's the time to experiment, figure out the good and bad. Not all orgs are going face first. Some of us are learning along with it.
Where it shines for me? Really small changes in a complex system. I can't store all the context all the time. Business requirements, security ones, aesthetic ones. Where it shines is if you suss out small changes thoroughly, it's a great text generating engine.
All of that said, the side effects of data centers and pump and dump stocks, are absolutely horrid. Hopefully on the other side of it we come to something more sane.
sobchak@programming.dev · 14 pts · 42d
You can learn how to use AI coding tools in a week at most, and there's no telling if next week they'll be a new harness or loop or whatever that becomes the new trend, making everything you've learned so far obsolete. Nobody's being left behind. AWS also isn't hard to learn if you've done the similar infrastructure stuff yourself. And git isn't hard to learn if you've used other version control systems.
exussum@lemmy.world · -1 pts · 42d
And that's the point. You don't have to consume everything all the time w/ AI/LLMs. But if you don't pay attn, 1) You'll likely make mistakes on things which didn't work out, like zero-shot prompting, or which models do better on which languages and 2) you'll have to play catch up.
On git? Did you know git would have won over HG, or Fossil? What about using git submodules, or bisect? You can do the research now that I wrote it out, but would you have known about them before hand? What about all the hook features?
And git can be hard, esp if people around you don't know it as well as you do, or people above you know it better than you do. Which again is a problem of people getting in way too late.
draco_aeneus@mander.xyz · 1 pts · 37d
From my experience, AI-assisted development is not good at complex systems. If a feature or fix requires a lot of changes in different places, or if the business logic is complex and difficult to understand, then the AI usually, in my experience at least, doesn't do a good job with it. And because the system is large/complex, you have to have a correct understanding yourself of how the system works if you want to know if the AI changes will actually work as expected, and what edge cases it addresses and omits.
exussum@lemmy.world · 1 pts · 37d
Absolutely. The great thing is you can ask ton of questions quickly to build your own knowledge quickly. It makes you faster not by doing the understanding for you. It can write tests to prove things pretty quickly. It can help find connections. Not fool proof ever, but it speeds up searches in your code base.
eager_eagle@lemmy.world · 33 pts · 42d
for anyone like me who could not understand that stupid title
Vulwsztyn@programming.dev · 1 pts · 36d
the title is not stupid, you are just not a native speaker
slazer2au@lemmy.world · 18 pts · 42d
Wait, they ai yolo from a memory safe language to an unsafe version of a different memory save language?
eager_eagle@lemmy.world · 20 pts · 42d
Zig is not as strict as Rust for memory management
tracyspcy@lemmy.ml · 10 pts · 42d
Unsafe rust too
eager_eagle@lemmy.world · 7 pts · 42d
yes, but when you make a port from one language to another, usually you want to rewrite it as a translation first, then refactor later with the features that language provides. A port that refactors everything in the first release is too risky.
The fact the translation has unsafe blocks only demonstrates the Zig version is not really safe as per Rust standards.
tracyspcy@lemmy.ml · 5 pts · 42d
my comment was just pointing out to unsafe rust blocks used in sloppy rewrite.
BB_C@programming.dev · -4 pts · 42d
You clearly don't even know what
unsafein rust means. And it's not something you can avoid when FFI is involved, slopping involved or otherwise.tracyspcy@lemmy.ml · 3 pts · 42d
Claude is it you?
BB_C@programming.dev · -5 pts · 42d
😇
I do love me some internet gantry commentary. Especially when it's super confident and acting knowledgable, with multiple layers of genius on display.
vanillama@programming.dev · 3 pts · 42d
I see what you're saying, but there's no need to be rude.
FizzyOrange@programming.dev · -2 pts · 42d
Sure, but only 5% of the Rust code is unsafe, which is clearly an improvement. And their plan is to reduce that amount over time.
I'm no fan of AI slop but that point isn't an issue.
SinTan1729@programming.dev · 12 pts · 42d
It depends on where exactly that 5% lies. If it's in the core API that's used by the rest of the architecture, it essentially makes the whole codebase unsafe when used irresponsibly.
I don't know if that's the case here, just pointing out that the 5% doesn't mean much.
FizzyOrange@programming.dev · 0 pts · 42d
Not exactly. It means that any of the code could lead to memory unsafety, but it's still better than Zig or C because you still only have to read 5% of the code to debug/fix those issues, instead of 100%.
5% is clearly better than 100%. Whatever else you think about this port you can't argue against that. In fact I can prove that it's better.
Does Rust's memory safety design improve memory safety? Yes, this is proven by experience (e.g. see Google's blog posts).
Does "normal" (not slop) Rust code rely on some
unsafe? Yes. All Rust code must use someunsafebecause it's used in the standard library, and even if you ignore that (there is an effort led by Amazon to formally verify it), it's usual for Rust projects to use at least someunsafe. Let's say 0.1% of lines.So 0.1% unsafe is clearly better than 100%. Is it possible for 0.1% unsafe to be better than 100%, but somehow 5% isn't? That would require things to be non-monotonic which is completely implausible.
SinTan1729@programming.dev · 7 pts · 42d
I'm sorry, but since we're being pedantic, this is not a proof. It's full of assumptions, some of which are wrong.
Never denied it. 0% is even better. What matters is where it's used. If it's used for FFI, that's understandable. Any other use should be scrutinized more. And that's the issue. The claim of Zig's creator is that the devs of Bun are not reliable. And to me at least, his arguments make sense.
Doesn't seem like it. This article claims that only about 20% of Rust crates use
unsafeat all. Even among those, the vast majority use it for FFI, which is kinda unavoidable.Again, no one claimed that. But we need more than "better than 100%" when it's a JS runtime. And the "better"ness isn't necessarily linear. So, even though it might be technically "better", it might not be by much. At that point, what even is the point of the rewrite?
Again, I'm not claiming that it's actually badly written. I'm only claiming that your arguments are not adequate, and that Bun is not a reliable company, so take whatever they claim with a grain of salt.
tracyspcy@lemmy.ml · 5 pts · 42d
So it is a reaction to Andrew Kelley’s reaction to bun / anthropic blog post that in their case was reaction to dev community reaction to sloppy rewrite from zig to rust with ai?
Jayjader@jlai.lu · 1 pts · 40d
Haven't you heard? "React" content is the new meta (/s only half way).
ExLisper@lemmy.curiana.net · 3 pts · 40d
This is soap opera level drama. "It was a toxic relationship and we're happy they are gone".
I get it, they made you look bad when they were using Zig and they made you look even worse when they switched. It's just sad that software projects have to deal with issues like that instead of just focusing on engineering.
vanillama@programming.dev · 1 pts · 40d
It's more that most people would only associate them with that one project. It's not as bad as it could be, but for instance in the Ruby world everyone just thinks of Rails and, if they're aware of it, the main guy behind it flirting with white supremacy
ExLisper@lemmy.curiana.net · 1 pts · 40d
I think Rust was lucky no to get assassinated with just one app. It was created around the same time as Zig and 15 years after Ruby but it feels like its development is more mature. A lot of haters but few dramas.
BB_C@programming.dev · -6 pts · 42d
I guess the target audience is non-coding AI skeptics looking for pseudo-intellectual takes, which appears to be a growing market. Because getting the very first technical detail, and a very basic one at that, this wrong is not a good look.
assaultpotato@sh.itjust.works · 16 pts · 42d
https://bun.com/
HTML title: Bun: A fast all-in-one JavaScript runtime
https://bun.com/docs/runtime
Am I missing something? How is that claim incorrect? I've never used Bun but their marketing material lines up exactly with the claim.
BB_C@programming.dev · -6 pts · 42d
First of all. Strictly speaking, there is no such a thing as a TS runtime. TS compiles to JS.
Second of all, bun binds against
JavaScriptCore, which is the JS engine used in Safari. Node binds againstV8, which is the engine used by Blink (Chromium et al). Both are implemented in C++. And the latter is considered the fastest engine.Ironically, both engines are mentioned by name in the very bun blog post being discussed, which points to a problem that is almost bigger than mere tech literacy from the pseudo-intellectual OP.
assaultpotato@sh.itjust.works · 12 pts · 42d
Saying there's no typescript runtime is (imo) a bit pedantic - if you JIT transpile TS down to JS at run time with hot-reloading you're effectively a TS runtime. For a non-technical one-liner on Bun, I feel that is a very reasonable simplification to make.
Perhaps bun would be even faster if they bound against another JS API, but that doesn't mean that Bun isn't faster than Node.js. They claim it's 3x faster than Node in aggregate, and that can potentially be true even if they use slower machinery under the hood. Python is a slow language but a fast framework can outperform a poorly written C++ implementation.
I'm not going to defend the article, I have no horse in that race, but until I see benchmarks that say Bun isn't faster than Node in aggregate, I don't think the claim can be called "wrong" on its face.
E: that's exactly what Bun does: "Bun supports TypeScript and JSX with no configuration. Bun transpiles every file on the fly with its native transpiler before running it."
BB_C@programming.dev · -5 pts · 42d
I'm going to call
cargoa Rust runtime from now on, consideringcargo-scriptexists.vanillama@programming.dev · 6 pts · 41d
Take the L and move on