- MoonMelon@lemmy.mlEnglish11 hours
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?
- 10 hours
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.
- 2 hours
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.
11 hoursfor 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
- slazer2au@lemmy.worldEnglish11 hours
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.
- 10 hours
my comment was just pointing out to unsafe rust blocks used in sloppy rewrite.
- 8 hours
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.- 8 hours
You can interface with a C++ JS engine without
unsafe(which is equivalent to just using C btw), if you just really put a real effort into it.😇
I do love me some internet gantry commentary. Especially when it’s super confident and acting knowledgable, with multiple layers of genius on display.
- 10 hours
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.
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.
- 5 hours
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.
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 code uses
unsafeat all. Even among those, the vast majority uses it for FFI, which is 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.
-
- 10 hours
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?
- 10 hours
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.
HTML title: Bun: A fast all-in-one JavaScript runtime
Bun is designed as a drop-in replacement for Node.js
execute javascript/typescript files […] with Bun’s fast 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.
- 7 hours
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.
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.”
- 2 hours
I’m going to call
cargoa Rust runtime from now on, consideringcargo-scriptexists.
