[dead]
Ladybird adopts Rust, with help from AI
601–610 of 731 posts
Re: Ladybird adopts Rust, with help from AI
#602Earlier quoted context omitted.
By that definition a void* pointer in C is a sum type. By that definition assembly has sum types. This argument feels like the “we have sum types at home” meme. Ergonomics matter. I write a lot of rust. Rust has traits which are similar to Go’s interfaces. But the features aren’t the same, and I use enum all the time. (I also use trait all the time, but I use trait and enum for different things).
> By that definition a void* pointer in C is a sum type. No. That doesn't make any sense. void* is essentially equivalent to any in Go, which isn't sum types either. You can construct sum types in C by combining structs, enums, and unions, but it is not an out of the box feature like in Go. Sum types are a first-class citizen in Go. > Ergonomics matter. Math doesn't care about ergonomics. You might care about ergonom…
> You can construct sum types in C by combining structs and unions, but it is not an out of the box feature like in Go. Sum types are a first-class citizen in Go.
Maybe I'm misunderstanding what you mean. Can you give me an example? How would you write a Result type in Go? (Result is defined as either Ok(val) or Err(err))
Re: Ladybird adopts Rust, with help from AI
#603Earlier quoted context omitted.
> By that definition a void* pointer in C is a sum type. No. That doesn't make any sense. void* is essentially equivalent to any in Go, which isn't sum types either. You can construct sum types in C by combining structs, enums, and unions, but it is not an out of the box feature like in Go. Sum types are a first-class citizen in Go. > Ergonomics matter. Math doesn't care about ergonomics. You might care about ergonom…
> You can construct sum types in C by combining structs and unions, but it is not an out of the box feature like in Go. Sum types are a first-class citizen in Go. Maybe I'm misunderstanding what you mean. Can you give me an example? How would you write a Result type in Go? (Result is defined as either Ok(val) or Err(err))
C:
enum result_type {
OK,
ERROR
};
union result_value {
int value;
char *error_message;
};
struct result {
enum result_type tag;
union result_value value;
};
Go:
type Result interface {
isResult()
}
type OK[T any] struct {
Value T
}
func (OK[T]) isResult() {}
type Error struct {
Message string
}
func (Error) isResult() {}
Re: Ladybird adopts Rust, with help from AI
#604Earlier quoted context omitted.
> Rust is the final language. > Defect free. I am an upstream developer on the Rust Project (lang, library, cargo, others), and obviously a big fan of Rust. This kind of advocacy doesn't help us, and in fact makes our jobs harder , because for some people this kind of advocacy is their main experience of people they assume are representative of Rust. Please take it down a notch. I think Rust is the best available lan…
I’d also add: as a lover of forward progress, I really hope rust isn’t the last good idea programming language designers have. I love rust. But there are dozens of things I find a bit frustrating. Unfortunately I don’t think I’m clever & motivated enough to write a whole new language to try to improve it. But I really hope someone else is! For a taste: I wish we didn’t need lifetime annotations, somehow. I wish rust…
> For a taste: I wish we didn’t need lifetime annotations, somehow. I wish rust had first class support for self borrows, possibly via explicit syntax indicating that a variable is borrowed, and thus pinned. Unpin breaks my brain, and I wish there were ways to do pin projections without getting a PhD first. I wish for async streams. I wish async executors were in std, and didn’t take so long to compile. I could go on and on.
I would like all of that as well. I think we can do much of that in Rust. I would love to see self-borrows available, and not just via pinning; I would also like relative pointers. I would like people to almost never have to think about pin or unpin; one of my rules of thumb is that if you see Pin or Poll, you've delved too deep, and nobody should need those to write almost any async code, including the interiors of trait implementations and async runtime implementations. And I would absolutely like to see async iterators, async executors, and many kinds of async traits in the standard library.
I also think there are plenty of things we are unlikely to get to even in an edition, and that might never happen without a completely different language. I'm not sure if we'll find a path to doing those in Rust, or if they will be the domain of some future language that makes different trade-offs.
Re: Ladybird adopts Rust, with help from AI
#605Pardon my ignorance, but doesn't a byte-by-byte output recreation of the C++ code in Rust defeat the whole purpose of using Rust? For one, would it be idiomatic Rust anymore? Also, if there's a (non-memory related) vulnerability in the C++ code, would it be possible for that to be introduced in Rust too?
Re: Ladybird adopts Rust, with help from AI
#606Pardon my ignorance, but doesn't a byte-by-byte output recreation of the C++ code in Rust defeat the whole purpose of using Rust? For one, would it be idiomatic Rust anymore? Also, if there's a (non-memory related) vulnerability in the C++ code, would it be possible for that to be introduced in Rust too?
Add the fact that AI is writing the rust code...
Re: Ladybird adopts Rust, with help from AI
#607Pardon my ignorance, but doesn't a byte-by-byte output recreation of the C++ code in Rust defeat the whole purpose of using Rust? For one, would it be idiomatic Rust anymore? Also, if there's a (non-memory related) vulnerability in the C++ code, would it be possible for that to be introduced in Rust too?
Once you get a byte-by-byte duplicate, you can start refactoring into idiomatic Rust. Convert pointers to references, rip out unsafe blocks, and let Clippy go ham.
Re: Ladybird adopts Rust, with help from AI
#608I'm a long-time Rust fan and have no idea how to respond. I think I need a lot more info about this migration, especially since Ladybird devs have been very vocal about being "anti-rust" (I guess more anti-hype, where Rust was the hype). I don't know if it's a good fit. Not because they're writing a browser engine in Rust (good), but because Ladybird praises CPP/Swift currently and have no idea what the contributor's…
> I guess more anti-hype, where Rust was the hype Yeah that is the thing I struggle with. I am really happy for people falling in love with Rust. It is a amazing language when used for the right use case. The problem is that had my Rust adventures a few years ago and I am over the hype cycle and able to see both the advantages and disadvantages. Plus being generally older and hopefully wiser I don't tie my identity t…
The whole obnoxious dogmatic evangelicalism thing is definitely a wider human phenomenon outside software and junior devs picking up new languages.
Definitely isn’t one of those things that can be solved, but it’s helpful to be aware of and process on that basis. I think some personalities are likely disproportionately vulnerable to this behaviour, but I think it largely has a positive core of enthusiasm. It’s probably more a matter of those individuals growing in self awareness.
Perhaps we saw a big wave of that with rust because it meant a lot of things to a lot of different people, some more equip to express their enthusiasm with some self control than others.
Re: Ladybird adopts Rust, with help from AI
#609This may sound stupid, but I wonder if using GPUI for a web browser could have some performance benefits...
I don't get the impression they care that much about performance. Besides, it would limit the number of platforms it could run on if it requires a recent GPU.
Using Rust means they’ve limited the number of platforms already… so I doubt they care.
Re: Ladybird adopts Rust, with help from AI
#610> I used Claude Code and Codex for the translation. This was human-directed, not autonomous code generation. I decided what to port, in what order, and what the Rust code should look like. It was hundreds of small prompts, steering the agents where things needed to go. After the initial translation, I ran multiple passes of adversarial review, asking different models to analyze the code for mistakes and bad patterns.…
We keep seeing this pattern over and over as well. Despite LLM companies' almost tangible desperation to show that they can replace software engineers, the real value comes from domain experts using the tools to enhance what they're already good at.
I'd guess this is a bet on which market is more lucrative:
* domain experts paying for tooling that will enhance their productivity
* capital/management class hoping to significantly replace domain experts
Software devs have been a famously tough market to sell tools to for a long time, so the better bet is B. Plus, the story on B is fantastic for fundraising; if there's a 10% chance that it checks out, you want some part of that as your capital portfolio.