71–80 of 560 posts
My biggest issue currently, is I can't seem to get a code review that's about the simplicity of the code, and no /simplify ain't it. Removing certain bugs and generally working seems to be doing alright, especially if it's following either an example code (like in the Bun rewrite case) or a well defined "spec" of how to proceed.
Earlier quoted context omitted.
Eh... rust's safety isn't free, but not having it and wasting time on "oh I forgot to change this call site" also isn't free. On the whole I'd say the safety assists in iteration time. What costs rust in iteration time in my opinion is the low level (by default) nature of it. There's a faster-to-iterate language that has yet to be created which is rust but we sacrifice performance (and memory fiddling ergonomics for…
Maybe something like Hylo? But personally I don't see anything displacing rust for the next few years, as I think there's enough rust in the training data for it to be the best "serious" language for agentic systems-level development. It's really the only systems language in its exact niche.
I'm suggesting a language where there's no difference between Box and u32. &Vec and &[u8] are the same thing. I don't need to write Box::new(...) around my closures to pass them to functions that take a function pointer. This comes with overhead, but in exchange we get simpler less verbose code. I.e. a language that isn't systems level, and isn't particularly machine-empathetic. But still has all the lightweight-formal-methods power of rust with lifetimes and mutable vs shared borrows (and thus references to references) and so on.
My impression of Hylo is that it's purpose is to be a similarly low level systems language to rust, just with a less complicated, and as a consequence less expressive, lightweight formal methods system for proving correctness.
I agree I don't expect rust to be displaced anytime soon. It creates a lot of time to create a good compiler, and a lot more to create the ecosystem of code, tools, and community around it.
Earlier quoted context omitted.
[flagged]
Jokes require mutual context. You failed to create a joke because you did not ensure the prerequisites were met.
The article itself is the context. Even the chatbots: ChatGPT, Claude and Gemini 'understand' the joke in the comment.
Go ahead and ask them.
> You failed to create a joke because you did not ensure the prerequisites were met.
The prerequisites was for you to read the article first.
The joke:
"Now Claude, rewrite Claude Code from TypeScript to Rust. Make absolutely zero mistakes."
You: ???
Earlier quoted context omitted.
> what say you now? I think that when you have a $165,000 hammer, all of your problems begin to look a lot like nails.
I would guess the cost to do this with humans would be _at least_ $1.5M in compensation alone (I'm thinking three 500k/year Bay Area engineers) so this is already an order of magnitude cheaper. Is it worth $165K? I'm less sure of that but it's honestly a moot point - this will get to 5 then 4 digits of cost pretty fast.
I will be a lot more excited when this is possible with <10k of api costs.
This blog post further undermines my trust in Jarred. He makes it sound like Claude did a fantastic Rust rewrite, and "the work continues." But when the Rust port merged to main, the state of the code was very, very bad. There were 13,000 instances of `unsafe`, no Miri tests at all, and, sure enough, it exposed UB in safe Rust. https://github.com/oven-sh/bun/issues/30719 Observers could see this coming from a mile aw…
I mean yeah, that's what this whole post is about. It's about the process of going from that original state to something that's now shipping in production.
However, I've been skeptical of using Bun, because I want a project whose first and foremost goal is to build good tools that achieve the objectives of the project.
It reminds me of asking game developers: Do you want to build a game, or do you want to build a game engine? Building a game engine is fine, but if you're goal is to make a game, then building an engine is a poor way of achieving your goals.
Likewise, I've wondered if the creators of Bun wanted to build better JavaScript tools, or if they wanted to use Zig.
Earlier quoted context omitted.
Not a compiler expert - shouldn't language verbosity and binary size be, at best, very loosely related?
I don't think you can draw the conclusion that source length and binary size are correlated. For example, in Rust: #[derive(Copy, Clone)] enum Expr { Int(i32), Add(i32, i32), Neg(i32), } fn eval(expr: Expr) -> i32 { match expr { Expr::Int(x) => x, Expr::Add(a, b) => a + b, Expr::Neg(x) => -x, } } Rust's enums can carry data. You can write the same thing in C, but because it does not have the enum feature, you have to…
As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026. Rust gives you that in a performant package, so if you are turned off by GCs and immutability for performance reasons, you still have the option to use Rust.
I can understand when you need the absolute best performance and you decide to drop to down to C++, and I also relate with just personal preference, but beyond those it seems a no brainer to me.