591–600 of 731 posts
Earlier quoted context omitted.
Can you release it as open source code?
Sure; I’ll throw it online in a few hours when I’m at my computer.
Live version: https://seph.au/claude-webmail/
Earlier quoted context omitted.
Is it any surprise that the cocaine cartels really want you to buy more cocaine, so they don't focus on its usefulness in pain relief and they refine it and cut it with the cheapest substances that will work rather than medical-grade reagents? Same thing.
LLMs are drugs because they’re addictive and sap your abilities, is it? (or generally: “Is the cocaine cartel comparison fair or unfair?”)
And in my experience potheads offer you a toke and if you politely refuse, no problem at all. Coke addicts don't want to take no for an answer and insist that everybody should do it, they get so much more done, decisions are faster and better and what the hell is wrong with you if you don't want some?
So, the users are similar too.
I'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…
I never fell in love with Rust or got particularly excited about adopting it. But, I just don't see a serious alternative (maybe Swift is fine for some cases but not in my field).
I believe Google's Rust journey was even more closely aligned with Ladybird: "we want memory safety, but with low impedance mismatch from C++". After like 5 years of trying to figure something like that out they seemed to go "OK actually fuck that we just have to use Rust and deal with the challenges it brings for a C++ shop".
Given it's not launched and it's donor driven, I guess conserving developer time is a key priority? Dual track sucks lots of time?
The byte-for-byte identical output requirement is the smartest part of this whole thing. You basically get to run the old and new pipelines side by side and diff them, which means any bug in the translation is immediately caught. Way too many rewrites fail because people try to "improve" things during the port and end up chasing phantom bugs that might be in the old code, the new code, or just behavioral differences.…
> Way too many rewrites fail because people try to "improve" things during the port I'd say that porting is a great time to "improve" many things, but like you suggest, not a great time to add new features. You can do a lot of improvements while maintaining output parity. You're in the weeds, reading the code, thinking about the routines, and you have all the hindsight of having done it already. Features are great to…
Earlier quoted context omitted.
> Interface defines an open class of types But can also define a closed set of types, perfectly satisfying "sum types". > This enables different syntax, like the match expression to be used, in which you exhaustively list all the variants. Go does not provide this out of the box, but that is not prerequisite for sum types. The mathematical theory says nothing about "the compiler must produce an error if the user does…
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).
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 ergonomics, but logically when talking about those ergonomics you'd call those ergonomics by name, not by some unrelated thing from type theory.
Earlier quoted context omitted.
First, it is important for these discussions that people include details like I did. We're all better off to not generalize. RE: Claude Code, no I haven't used it, but I did do the Anthropic interview problem, beating all of Anthropic's reported Claude scores even with custom harnesses etc. It's not a dunk that agents can't produce "as fast as can be" code; their code is usually still reasonably fast; it's just often…
There is a lot to be done with good prompting. Early on, these code agents wouldn't do basic good hygiene things, like check if the code compiled, avoid hallucinating weird modules, writing unit tests. And people would say they sucked .... But if you just asked them to do those things: "After you write a file lint it and fix issues. After you finish this feature, write unit tests and fix all issues, etc ..." Well, th…
Use it as if you're the tech lead managing a fresh hire. Tell it clearly what you want it to focus on and you get a much better result.
This may sound stupid, but I wonder if using GPUI for a web browser could have some performance benefits...
Earlier quoted context omitted.
When you do fully value-oriented programming in Rust (i.e. no interior mutability involved) that's essentially functional programming. There's mutable, ephemeral data involved, but it's always confined to a single well-defined context and never escapes from it. You can even have most of your code base be sans-IO, which is the exact same pattern you'd use in Haskell.
I actually like rust more than Haskell, but `You can even have most of your code base be sans-IO, which is the exact same pattern you'd use in Haskell.` glosses over the fact that in Haskell it's enforced at compile time.
Even rust has need of this. For example, I want a nopanic effect I can put on a function which makes it a compile error for anything that function calls to panic.
If it is this easy, surely the trend is Rust output being an intermediate pass of the LLM super compiler. A security subset if you will (like other kinds of optimization), it will move from Rust specs to some deeper level of analysis and output the final executable. Some brave souls will read the intermediate Rust output (just like people used to read the assembler output from compilers) but the LLM super compiler wi…
Do you seriously think LLMs will not just spam unsafe blocks in it like they do with any task ever?