upvote

points

by q3k26 days ago |
comments
upvoteby kllrnohj26 days ago|
next
[-]
> At some project scale the language really stops being any limiting factor

That's not entirely true. At a certain scale, some languages start becoming increasingly more of a factor. Memory issues in C/C++ codebases, for example. This is pretty well established at this point, which is why there's a push to move away from memory-unsafe languages. Which likely would include Zig, for better or worse.

reply
upvoteby q3k26 days ago|
parent|
[-]
I agree that new software should avoid memory unsafe languages, but I would disagree that rewriting existing projects in a memory safe language at all cost is a universally good idea.
reply
upvoteby hombre_fatal25 days ago|
parent|
[-]
But you just shifted the claim to "at all cost".

What if there isn't much cost? What if the benefits outweigh the cost?

reply
upvoteby zx0r2325 days ago|
parent|
[-]
I mean... the token cost alone on this thing...
reply
upvoteby cmrdporcupine25 days ago|
prev|
next
[-]
It's I think not churn for the sake of churn. It's likely encouraged by the fact that Zig itself will not accept AI written code contributions.

So now imagine your company and project -- written in Zig -- has just been acquired by the world's biggest/second-biggest AI company.

That company's most successful and popular tool is running on your platform that is written Zig.

And Zig maintainers want nothing to do with you.

What kind of pressures, real or imagined, do you think that puts on the developers of Bun?

Honestly, from what I've seen from a distance, actual rigorous software engineering doesn't happen at Anthropic. From what we saw of the Claude Code source, the reliability issues over the last few months, and now this. It's just a bunch of people getting high on their own supply falling all over each other. Quality issues galore and a delirious frenzy.

FWIW I don't think it's intrinsic to AI. Codex is very well written (in Rust, BTW), fast, and consistent.

reply
upvoteby nefasti26 days ago|
prev|
[-]
The "idiomatic Rust" thing rubs me the wrong way. If someone writes Rust that compiles and works, that's Rust. full stop. Telling people it doesn't count until it's "idiomatic" is just gatekeeping. It quietly says you're not a real Rust dev until you've put in years and absorbed all the unwritten rules, which shuts out exactly the people who are still learning. Everyone writes "non-idiomatic" code when they start. That's not a failure, that's how learning works. Even if being written by LLMs, the devs still will need to improve their knowledge to keep the codebase.
reply
upvoteby eesmith26 days ago|
parent|
next
[-]
I beliebe q3k's comment should be read as "[even if it's acceptable to the most stringent of gatekeepers] then this would be churn for the sake of churn."'

Not that only idiomatic Rust is appropriate.

reply
upvoteby cogman1026 days ago|
parent|
prev|
next
[-]
I get the feeling, and shooting for idiomatic on a rewrite is definitely wrong.

That being said, "idiomatic" is more just saying "clean and familiar". It's using the right language features in the right places.

For example, you could write something like this

    fn add_double(a: f64, b: f64) -> f64 {
      return a + b;
    }

    fn add_float(a: f32, b: f32) -> f32 {
      return a + b;
    }
But that's not idiomatic. Idiomatic would look something like this

    fn add<T: std::ops::Add<Output = T>>(a: T, b: T) -> T {
      return a + b;
    }
The benefit of the idiomatic approach is now you have a function which handles a bunch of types from u32, to f64 and it also handles custom types and traits which implement the add ops.

The first method is what you might write if you were, for example, translating from C to Rust. It isn't idiomatic but it's easy to do.

The other thing to realize is that compiler authors optimize for idiomatic. The more you do things in a strange fashion, the more likely you are to stumble over a way of writing code which isn't being looked at when the language team is looking at performance and compile time optimizations.

There's nothing wrong with non-idiomatic code per say. However, part of learning a language is learning the idioms. It makes you better at that language.

reply
upvoteby bschwindHN25 days ago|
parent|
[-]
Pedantic:

    fn add<T: std::ops::Add<Output = T>>(a: T, b: T) -> T {
      a + b
    }
reply
upvoteby IshKebab26 days ago|
parent|
prev|
[-]
Not really. Rust is designed to be written in a certain way. If you machine translate C into Rust you end up with a load of `unsafe` code that follows the C style but consequently doesn't get any of the benefits of being written in Rust.

Imagine if you translated assembly to C++, but you just did it by putting everything in `asm("...")` calls. That's not idiomatic C++ and you wouldn't get any of the benefits of using C++.

That said, the Rust code I skimmed actually did look surprisingly idiomatic. It wasn't full of `unsafe` like I would have expected.

reply