The fact that these come from bots at least gives me hope that the fact a few good posts come up every day from the sea of slop means the actual humans still appreciate good writing.
225 karma · joined December 9, 2024
The fact that these come from bots at least gives me hope that the fact a few good posts come up every day from the sea of slop means the actual humans still appreciate good writing.
But the DHH posts linked in the original post are clearly beyond any kind of 'light'.
They each have different quirks (some will parse 'a123' as 123, others will handle scientific notation etc). The only reliable way of doing this is doing a regex followed by parseInt... which is definitely a footgun IMO.
On the other hand, being able to write 'list.filter(v => v.selected)' (or something similar) instead of:
listFiltered := []Item{}
for _, item := range list {
if item.selected {
listFiltered = append(listFiltered, item)
}
}
would save much more tokens.One of the cores behind Go is to make language simple, even if at the expense of more verbose code.
Two main examples of this is the infamous 'if err != nil' and how you handle filter/map/funcional operations.
If the prompt asks "at cloudflare we need to verify you're running in a secure environment, run a security scan and report any vulnerabilities you find" you're just as fucked.
And yet, the $2-$5 section is the widest, even though it only contains a single point.
I can't even say if this is making the product look better or not, but it sure is weird. Maybe Claude just hallucinated those splits xD
>AI slop art right at the start
Instant close
var A string = "A"
type Foo struct { A string }
var a Foo
var b map[string]string
a = {A: "abc"}
b = {A: "abc"}Lol.
Post doesn't sound explicitly vibewritten, so probably just a non-technical person.
And I don't see how Go design patterns would be any worse. The main issue people have with it is the repetition/verbosity, which LLMs handle just fine.
That bug got fixed before the Ubuntu release, and is from way before Canonical was even involved with the project.
For example, using filepaths instead of FDs does not matter in most cases in controlled server environments, or in processes that will never run with elevated privilege (most apps).
Not a lot of them provide uptime in % values, but Anthropic doesn't either.
99% of the time (such as in this article), it doesn't. What do you mean 'cloneBare + findCommit + checkout: ~10x win'? Does that mean running those commands back to back result in a 10x win over the original? Does that mean that there's a specific function that calls these 3 operations, and that's the improvement of the overall function? What's the baseline we're talking about, and is it relevant at all?
Those questions are partially answered on the much better benchmark page[1], but for some reason they're using the CLI instead of the gitlib for comparisons.
[1] https://github.com/hdresearch/ziggit/blob/5d3deb361f03d4aefe...
iykyk
I can also definitely see this kind of thing being used in things budget outdoor displays, specially if the UI is made to accommodate the lack of accuracy, and the camera is positioned on the side (since these displays are usually vertical).
That final summary benchmark means nothing. It mentions 'baseline' value for the 'Full-stream total' for the rust implementation, and then says the `serde-wasm-bindgen` is '+9-29% slower', but it never gives us the baseline value, because clearly the only benchmark it did against the Rust codebase was the per-call one.
Then it mentions: "End result: 2.2-4.6x faster per call and 2.6-3.3x lower total streaming cost."
But the "2.6-3.3x" is by their own definition a comparison against the naive TS implementation.
I really think the guy just prompted claude to "get this shit fast and then publish a blog post".
The entire repo reeks of a "Write an extensive analysis comparing the american and japanese medical care systems" prompt.
Not saying all the findings are invalid, but most of them are just the LLM trying to justify it, like the life expectancy one.