kiitos

21 ms·

271.
by kiitos 1y ago
> one degree removed You're letting Claude do your programming for you, and then sweeping up whatever it does afterwards. Bluntly, you're off-loading your cognition to the machine. If that's fine by you then that's fi
272.
by kiitos 1y ago
> When you say "the LLM can easily hallucinate code that will satisfy the compiler but still fail the actual intent of the user", all you are saying is that the code will have bugs. My code has bugs. So does yours. You don&#x27
273.
by kiitos 1y ago
No, that's not at all my claim, as it's obvious from the commit history that Kenton is reading the code he's generating before committing it.
274.
by kiitos 1y ago
The sequence of commits talked about by the OP -- i.e. kenton's coding session's commits -- are like one degree removed from 100% pure vibe coding.
275.
by kiitos 1y ago
> if you can't look at a work week and spot huge fractions of work that you're doing that isn't fundamentally discerning or creative, but rather muscle-memory rote repetition of best practices you've honed over your c
276.
by kiitos 1y ago
Irrelevant, really. Tests establish a minimum threshold of acceptability, they don't (and can't) guarantee anything like overall correctness.
277.
by kiitos 1y ago
> `return fmt.Errorf("annotation: %w", err)` is just a log-friendlier version of `return err` This claim isn't true. The annotation-wrapping isn't just about making the returned error 'log-friendlier', it&#x
278.
by kiitos 1y ago
> If the LLM hallucinates, then the code it produces is wrong. That wrong code isn't obviously or programmatically determinable as wrong, the agent has no way to figure out that it's wrong, it's not as if the LLM produces
279.
by kiitos 1y ago
PAR isn't any kind of panacea or golden rule for nodes in a distributed system, it describes properties of nodes that meet very narrowly-defined requirements, which are in no way universal, and which are in no way requirements for thos
280.
by kiitos 1y ago
What on earth are you talking about?? If the LLM hallucinates, then the code it produces is wrong. That wrong code isn't obviously or programmatically determinable as wrong, the agent has no way to figure out that it's wrong, it&#
281.
by kiitos 1y ago
I've read that paper, and all of the papers that TigerBeetle mentions in any and all of its docs/blog posts/etc. Stable storage doesn't matter to the points I'm trying to shine a light on here. It's not "d
282.
by kiitos 1y ago
I've read that paper for sure! > Disks and flash devices exhibit a subtle and complex failure model: a few blocks of data could become inaccessible or be silently corrupted [8, 9, 32, 59]. Although such storage faults are rare compa
283.
by kiitos 1y ago
No, it is not widely considered to be a misnomer. What are you trying to communicate with this comment?
284.
by kiitos 1y ago
Mendoza doesn't appear to provide a spec?
285.
by kiitos 1y ago
> it must be done in a central error translator. By definition. And this translation must either do a dozen+ Is() and As() calls, or it can be done efficiently, as I've described. These claims are, bluntly, incorrect. There are no w
286.
by kiitos 1y ago
[disks are] somewhere between non-byzentine fault tolerance and Byzantine fault tolerance ... you expect the disk to be almost an active adversary ... ... so you start to see just a single disk as a distributed syste
287.
by kiitos 1y ago
Any code that looks like that is almost certainly broken. If the things you're describing as "my opinion" are counter-indicated in the code that you're used to working with, then you're working with code that's
288.
by kiitos 1y ago
The fmt.Errorf expr is wrapping the error, with relevant context at the wrap-site. It's not just "log-friendlier" it's actually important metadata.
289.
by kiitos 1y ago
See for yourself: https://go.dev/play/p/Q7IPuPS5CwQ
290.
by kiitos 1y ago
errors.Is definitely doesn't use string comparison internally: https://cs.opensource.google/go/go/+/refs/tags/go1.24.3:src/...
291.
by kiitos 1y ago
Extraordinarily good stuff! Thanks for sharing, I haven't seen it before.
292.
by kiitos 1y ago
In what universe?
293.
by kiitos 1y ago
I absolutely deny that there are any interesting ideas in there. We've done this, it was called the dark ages and it sucked and we moved past it. Engaging with this pablum in any way is granting it attention and vigor it obviously does
294.
by kiitos 1y ago
He never had interesting ideas, even in the past. It was always just neo-reactionary feudalist garbage from day 1.
295.
by kiitos 1y ago
Yeah, I mean, Go doesn't see types as particularly special, rather just as one of many tools that software engineers can leverage to ship code that's maintainable and stands the test of time. If your mindset is type-oriented then
296.
by kiitos 1y ago
> I absolutely agree that the code yielding the error cannot know (again, with the exception of panic, but I believe that we agree that this is not part of the scope of our conversation). Which in turn means that every function should do
297.
by kiitos 1y ago
> Indeed, you can absolutely handle some cases with combinations of `errors.Is` and `fmt.Errorf` instead of implementing your own error. Not "some cases" but "almost all cases". It's a categorical difference. &gt
298.
by kiitos 1y ago
Returning an error -- or, more accurately, identifying an error and returning an annotation or transformation of that error appropriate for your caller -- is a way of handling it. The cases where, when your code encounters an error, that
299.
by kiitos 1y ago
Again, you don't need to define a new error type in order to allow callers to do something about it. Almost all of the time, you just need to define an exported ErrFoo variable, and return it, either directly or annotated via e.g. `fmt
300.
by kiitos 1y ago
> A type assert/switch is exactly how you implement Error.Is [^0] errors.Is is already implemented in the stdlib, why are you implementing it again? I know that you can implement it on your custom error type, like your link shows,

More ›