MurphyA/hacker-news huggingface dataset:
by jerf | 2026-01-08 16:23:43+00:00
Author is still early in their exploration and has some definite mistakes in here. Probably the biggest one is around the error handling, thinking that the only way to interact with an error is through the error interface itself. That is intended as a baseline interaction, a fallback for when nothing else is appropriate, such as just slamming an error into a log. If you want to interact with specific errors, you should use the various functions in the errors package [1] to check for specific types, and then use those specific types in whatever they support. Go error support is quite good; you can return an error object that says "The user was not found, the file the user was supposed to be found in was not found, and while trying to log this the log failed to accept the write" as various error types composed together, and any consumer of the error using the errors package can pick out the various bits of the error they understand using those tools without having to understand the error binding them together or the components it doesn't care about . You should never use string manipulation to check errors unless you have no choice, and whatever library left you with no choice should have an issue filed against it. It doesn't come up often, but it does sometimes come up; most recently I had the AWS SDK emitting an error I could only use string functions on, but I think they've since fixed it.

I don't like the term "enums" because of the overloading between simple integers that indicate something (the older, more traditional meaning) and using them to mean "sum types" when we have the perfectly sensible term "sum type" already, that doesn't conflict with the older meaning. If you want sum types, a better approach is to combine the sort of code structure defined here: https://appliedgo.net/spotlight/sum-types-in-go/ with a linter to enforce it https://github.com/alecthomas/go-check-sumtype , which is even better used as a component of golangci-lint: https://golangci-lint.run/

I'd also add my own warnings about reaching for sum types when they aren't necessary, in a language where they are not first class citizens: https://jerf.org/iri/post/2960/ but at the same time I'd also underline that I do use them when appropriate in my Go code, so it's not a warning to never use them. It's more a warning that sum types are not somehow Platonically ideal. They're tools, subject to cost/benefit analysis just like anything else.

[1]: https://pkg.go.dev/errors
by fc417fc802 | 2026-01-08 16:23:43+00:00
> Attackers use automated scripts to locate vulnerable systems.

I'm aware. I thought we were talking about something a bit higher effort than that.

> online data backup service

That isn't what I said. I suggested federally backed FOSS tooling for the specific usecase. If nothing else that would ensure that low effort scanners came up empty by providing purpose built software hardened against the expected attack vectors. Since it seems we're worrying about the potential for broader system misconfiguration they could even provide a blessed OS image.

The breach in the article has nothing to do with what we're talking about. That was a case of shadow IT messing up. There's not much you can do about that.
by cogman10 | 2026-01-08 16:23:43+00:00
NT would be pretty easy to guess from just about any verse. The hardest part would be placing one of the epistles or determining exactly which gospel a verse came from.

OT is a lot harder simply because of the number of writers and how boring/similar a lot of the writing is. To be successful you'd need to have something pulled from like the pentateuch. Maybe psalms or something like Kings/Chronicles.
by oceanplexian | 2026-01-08 16:24:14+00:00
I run models with Claude Code (Using the Anthropic API feature of llama.cpp) on my own hardware and it works every bit as well as Claude worked literally 12 months ago.

If you don't believe me and don't want to mess around with used server hardware you can walk into an Apple Store today, pick up a Mac Studio and do it yourself.
by virgil_disgr4ce | 2026-01-08 16:24:28+00:00
> cautious that this is the type of reasoning which propels the anti-vax movement

I hear you but there are two fundamentally different things:

1. Distrust of / disbelief in science
2. Doctors not incentivized to spend more than a few minutes on any given patients

There are many many anecdotes related to the second, many here in this thread. I have my own as well.

I can talk to ChatGPT/whatever at any time, for any amount of time, and present in *EXHAUSTIVE* detail every single datapoint I have about my illness/problem/whatever.

If I was a billionaire I assume I could pay a super-smart, highly-experienced human doctor to accommodate the same.

But short of that, we have GPs who have no incentive to spend any time on you. That doesn't mean they're bad people. I'm sure the vast majority have absolutely the best of intentions. But it's simply infeasible, economically or otherwise, for them to give you the time necessary to actually solve your problem.

I don't know what the solution to this is. I don't know nearly enough about the insurance and health industries to imagine what kind of structure could address this. But I am guessing that this might be what is meant by "outcome-based medicine," i.e., your job isn't done until the patient actually gets the desired outcome.

Right now my GP has every incentive to say "meh" and send me home after a 3-minute visit. As a result I more or less stopped bothering making doctor appointments for certain things.
by GuB-42 | 2026-01-08 16:24:36+00:00
I admit that I expected more. They really did the minimum, as in, anything less should have been illegal. It is praiseworthy, but it is unfortunate that it is.

Seeing that, I expected the ability to build and run a custom firmware, like with an Android device with its bootloader unlocked. But it is not that, and they didn't open source their app either.

What they did is that they removed dependence on their servers, and opened their device to be controlled by third party apps. That is, they let users use their device past its end of life, including when the first party app will stop being maintained, but not to the point of letting user add features.

In understand why they would do that, they don't want users to backport features only available on their latest models that are sold at a premium, therefore competing against themselves. After all, the value in smart speakers is not the sound producing device, which I think is a problem that has been solved more than a decade ago at the consumer level, it is all about software features.
by PaulHoule | 2026-01-08 16:24:38+00:00
It's not the hardware getting cheaper, it's that LLMs were developed when we really didn't understand how they worked, and there is still some room to improve the implementations, particularly do more with less RAM... And that's everything from doing more with fewer weights to things like FP16, not to mention if you can 2x the speed you can get twice as much done with the same RAM and all the other parts.
by bombcar | 2026-01-08 16:24:46+00:00
5–10× the ROI of the S&P 500 - which is really only true because we allow massive leverage on real estate that we'd not on stocks themselves.

And leverage brings all the problems associated with it; if you own your house outright and it goes down %10 you're out 10%; if you only have 10% equity and the same happens you're down 100%. The gains, of course, work similarly which is why for so long it's been a heads I win, tails I win.
by SilasX | 2026-01-08 16:24:57+00:00
The whole point is that you don't need to get anyone to consciously follow any proposal, you just push common usage in the direction of saying "sen" to the point that it becomes correct, and you can take action now to assist it, without having to coordinate, and without breaking your existing communication.

With respect, your comments read as ignoring all the points I brought up in in order to show off knowledge you're proud to have.
by ajross | 2026-01-08 16:25:15+00:00
I don't buy that example about errors at the end at all. The problem the author is trying to solve is to write code that calls a foreign/fixed-API function that is known to return a particular subtype of Error, and wants to extract structured information from it. But you can't, because the type returned is just the outer Error type that only has a string.

Obviously, though, the only way this happens is if you know a priori what actually failed, because otherwise it might be some other error type. And you don't, obviously, because it's an error! If your behavior is deterministic then just return whatever you want in your own API. If it's not, you need to parse/extract/inspect the error.

Basically it's entirely contrived. This never happens, and to the extent it does it's a terrible bug where you have code making assumptions about runtime error state without fully inspecting that state.

The second failure is that Go does in fact have runtime type inspection facilities ("type assertions" is the particular jargon) and if you want you can absolutely "cast" that error into a derived type to get the data out. So it's not even a problem in the language as it exists.
by Dwedit | 2026-01-08 16:25:33+00:00
I actually compared WASM to Javascript for a particular integer-math-heavy task. For a single run, Javascript beat out WASM because WASM had a lot more setup time. After running both 1000 times, they were almost equal in runtime.

Yes, even though the Javascript was written using Doubles and the WASM was written using 64 bit ints. It just means that it's possible to write optimized Javascript (mainly by reducing object allocations, reuse objects instead)
by threethirtytwo | 2026-01-08 16:26:15+00:00
Malpractice is deliberate harm by not following standard professional practices or doing deliberate harm.

I’m not talking about that. What I’m talking about is fucking simple. A doctor gives you advice and you pay him thousands for it. That advice is completely fucking wrong.

In what universe does that payment make sense? In what universe is giving wrong information deserving of thousands of dollars of payment for services rendered. It’s bloody simple: it’s not deserved and a refund is in order.
by majani | 2026-01-08 16:26:32+00:00
Increasing supply would see your property value rise astronomically. Suddenly there would be developers wanting to build a 30 storey building in place of your single family unit. The ROI on that 30 storey would be high enough for them to give you multiple millions of dollars for your land. What would decrease is the beauty of the neighborhood, but people can be taught to appreciate the beauty of highrise buildings
by anttiharju | 2026-01-08 16:26:51+00:00
I like Rust.

I don't like that for fairly basic things one has to quickly reach for crates. I suppose it allows the best implementation to emerge and not be concerned with a breaking change to the language itself.

I also don't like how difficult it is to cross-compile from Linux to macOS. zig cc exists, but quickly runs into a situation where a linker flag is unsupported. The rust-lang/libc also (apparently?) insists on adding a flag related to iconv for macOS even though it's apparently not even used?

But writing Rust is fun. You kind of don't need to worry so much about trivialities because the compiler is so strict and can focus on the interesting stuff.
Show HN: Plotnik – type-safe query language for Tree-sitter
by srgzzz | 2026-01-08 16:26:57+00:00
For many years, I was writing and maintaining parsers to extract package metadata. Some were JSON files, others written in the programming language they represent. Regex covers 90-95% of cases, but edge cases result in bug reports, and you end up adding increasingly complex workarounds. I tried building a parser combinator library, but it wasn't good enough either.

Tree-sitter solves parsing part, but extracting the data still requires some glue code. I created a query language where the query determines the type of its result, so you don't need to use defensive programming and type checks at runtime. It's similar to tree-sitter native queries, but adds recursion, type annotations and Rust-like error diagnostics.

It compiles to cache-friendly binary representation and runs on special tree-walking VM. The compilation via proc macros is planned in future.
by iamcalledrob | 2026-01-08 16:27:08+00:00
I'd encourage the author to spend more time learning Go. They've come to incorrect conclusions -- especially regarding errors. Read more of the stdlib to see how powerful they can be, e.g. net.OpError: https://cs.opensource.google/go/go/+/refs/tags/go1.25.5:src/...

> The user now has an interface value error that the only thing
> they can do is access the string representation of ... The only
> resort the consumer of this library has is to parse the string
> value of this error for useful information.

This shows a lack of understanding about the `error` interface, `errors.Is`, `errors.As`, error wrapping etc.

Personally, I think Go errors are fantastic, just the right sprinkling of structure on top of values. And panic/recover for truly exceptional circumstances.
by wozzio | 2026-01-08 16:27:16+00:00
OP here. One detail I left out:

We are currently looking for 3 engineering teams to be 'Design Partners.'

If you are managing a cluster with high variance (e.g., AdTech, AI, Data Services) and suspect you have 'Sleep Insurance' waste (requested > used), I’d be happy to manually audit your Helm charts and set up these guardrails for you for free.

I’m looking for feedback on our 'Blended Rate' math vs. real-world billing. If interested, my email shoot me a note.
by minimaxir | 2026-01-08 16:27:34+00:00
I suspect 99% of coding agents would be able to say "hey wait, there's no 'index_value' column, here's the correct input.":

df['new_column'] = df.index + 1

The original bug sounds like a GPT-2 level hallucination IMO. The index field has been accessible in pandas since the beginning and even bad code wouldn't try an 'index_value' column.
by 10729287 | 2026-01-08 16:27:36+00:00
Typical so called audiophile stance here. I have numerous headphones (including high ends ones) and always been happy with my Bose. Sound is great and gently enhanced for listening enjoyment, whatever snobs could say about it, and the hardware is really nice. My Bose SoundSport earbuds are the best fit I ever had in 30+ years of wearing earbuds and my QC35 never failed on me. That move from adds to all the great things I can say about this brand. Sure it's not flat perfection for the so called happy fews but it's great gear.
by maerF0x0 | 2026-01-08 16:28:05+00:00
All these things are actually rules of thumb that aim to be easy, and less focused on accurate.

A reasonably close rule of thumb can actually be 1g of protein per cm of height.

Also not accurately represented is that your body absorbs less protein per gram consumed the older you get. (I couldnt find a source with an actual ratio, just recommendations for _more_ as you get older).

When listening to folks like Layne Norton, they have said that surprisingly many people who simply increase their protein inadvertently begin to lose weight due to greater satiety per net calorie. (remember, roughly 20% of protein calories are lost in digesting/absorbing/converting the protein)
by Groxx | 2026-01-08 16:28:05+00:00
I'm good without the animations, thanks. I disable them everywhere already.

Small touch targets is true, but with how expansive UIs have gotten since Windows Mobile it's FAR less of an issue and I've used it just fine in the past (external touch display). The most difficult target is usually the window close button, but the consequences for missing that are nearly zero, and practically everything else is more than large and space-buffered enough if you don't close your eyes before reaching for the screen. And that's before liquid glass redesigns.
by metobehonest | 2026-01-08 16:28:08+00:00
I can imagine Claude getting worse. I consider myself bearish on AI in general and have long been a hater of "agentic" coding, but I'm really liking using aider with the deepseek API on my huge monorepo.

Having tight control over the context and only giving it small tasks makes all the difference. The deepseek token costs are unbeatable too.
by jrm4 | 2026-01-08 16:28:15+00:00
Perfectly? No. No. A million times no.

You're getting downvoted because "stop giving your resources to the bad actors" is not even remotely close to a viable solution. There is no opting out in a meaningful way.

NOW, that being said. People like you and me should absolutely opt out to the extent that we can, but with the understanding that this is "for show," in a good way.
by idiotsecant | 2026-01-08 16:28:16+00:00
There are plenty of studies that take place outside north america saying the same thing.[1], for example. If you insist on this not being true thats fine, everyone gets to think whatever they want, but you're clearly not supported by the data in saying so.

[1]https://link.springer.com/article/10.1186/1741-7015-11-63?ut...
by andrepd | 2026-01-08 16:28:42+00:00
Maybe I'm not understanding what you mean but isn't this just... a shared calendar? You have a work calendar which is public and other people can open to view your availability, and propose meeting times. And vice-versa you can see their calendar.

Modulo your problem with travel times (but calendars have location info, so hacking something where the travel time between two consecutive locations is accounted for should not be too difficult). So I don't quite understand where "AI" fits into this.
by toast0 | 2026-01-08 16:28:45+00:00
> Also, anyone driving in the city with their high-beams or fog lights on should be ticketed at an increasing rate.

At least in my neck of the woods, it seems like lighting enforcement has gone from slim to none. I regularly see vehicles with only one of three brake lights functioning... and sometimes I've seen the same vehicle with the same lighting issue for several months.

If there's no enforcement on vehicle lighting from behind, there's definitely not going to be much on the front lighting, because an officer would need to see the lighting, turn around and give chase. Well, that or inspections, but the vast majority doesn't want inspections because they cost money.

All that said, what's the problem with fog lights? They're not actually useful, but they don't present a safety hazard and it's always fun to wonder how long a car has had one fog light out, and if they'll figure out how to turn the fog lights off before the other one burns out.
by PaulHoule | 2026-01-08 16:28:46+00:00
You are better off talking to Google's AI mode about that sort of thing because it runs searches. Does great talking about how the Bills are doing because that's a good example where timely results are essential.

I haven't found any LLM where I totally trust what it tells me about Arknights, like there is no LLM that seems to understand how Scavenger recovers DP. Allegedly there is a good Chinese Wiki for that game which I could crawl and store in a Jetbrains project and ask Junie questions about but I can't resolve the URL.
by richarme | 2026-01-08 16:28:52+00:00
Cool to see the Invoke getting mentioned!

I was the engineering lead on that product, and built a SW platform from scratch for it (Microsoft provided an SDK to Cortana which they developed in parallel.)

The internal build could actually run Cortana, Alexa and Google Assistant simultaneously and you could e.g. set an alarm with one of them and query it with another, and they could interrupt each other based on priority. Obviously nobody wanted that feature, but it was hella cool that it worked. Oh, and you could make Skype calls from across the room, and the microphone array lived up to Skype's tough certification requirements which took weeks of testing in Microsoft's anechoic chamber for the DSP/algorithm team to fine tune.

I tried to push for open-sourcing the platform but it was tricky because 1) the director of engineering in Harman didn't know what open source meant and for a hardware focused business to understand the value was a hard sell, 2) it used a HW module that came with a SW stack I mostly got rid off but a few parts were remaining that would need to be replaced which would require additional resources, 3) I was burned out at that point and had limited energy left to fight the good fight. Really too bad, it could have been a cool voice agent development platform, and I honestly think it would have sold in large volumes as a developer-friendly device.

Glad you like it, sorry about the remaining Bluetooth bugs nobody got around to fix, since it basically flopped instantly.
by matkoniecz | 2026-01-08 16:29:00+00:00
likely it was not yet mapped in OpenStreetMap!

So it is missing in OpenStreetMap-based map.

Feel free to edit it if you can!

(even if this specific data is not possible to be added by you - feel free to add say nearby shop or park)

ad: if you have Android I can recommend StreetComplete (great for newbies)

if you have iPhone - GoMap!! is great though a bit more complicated to use

Vespucci is more complicated and more powerful than StreetComplete editor for Android phones

or you can edit directly on osm.org from desktop

-------------

disclaimer: I am a walking conflict of interest as far as OSM goes (for start, I am StreetComplete contributor)
by maxkfranz | 2026-01-08 16:29:00+00:00
That's a great point. There are a lot of things you can do to optimise things, and your suggestion is one of the lower hanging fruits.

I was trying to get across the point that today you can get a lot of benefit from minimal setup, even one that's vendor-agnostic. (The steps I outlined work for Codex out of the box, too.)

You're right to point out that the more you refine things, the more you'll get out of the tools. It used to be that you had to do a lot of refinements to start getting good results at all. Now, you can get a lot out of even a basic setup like I outlined, which is great for people who are new users -- or people who tried it before and weren't that impressed but are now giving it another try.
by svilen_dobrev | 2026-01-08 16:29:19+00:00
if u imagine the stack as: customers on top, over business, over analysis, over software, over machines/infrastructure..

25+ years ago i thought that DSLs and such very-high-level-mostly-formalised-descriptions will move the line between what-product-is-aka-business-analysis and software/coding towards software, reducing its part in the whole stack.

Well, it did not happen, just the opposite - instead the developers become expected to know everything from infrastructure to software to analysis to business domain and higher. So, stack became something like customers over business over... software-dev. Requirements, analysis... mostly gone / done by devs.

Now if that whole "software" part collapses into zero-margin, i see two ways: either businesses very quickly resurrect the business-analysis (what the product is) and make that their margin/moat, or the customers start making their own software (as throwaway 100 wrongs is now possible) - and removing the business from the whole transaction...
by ddoolin | 2026-01-08 16:29:21+00:00
I've only written a handful of production projects in Go so my experience isn't very deep, but I find the syntax to be the ugliest of any PL. The mixed capitalizing based on function privacy, to me, is awful (among other things, i.e. personally I loathe curly brace initialization/definition). I'm sure you get used to it? It doesn't help that it just feels very hacked together, from the wonky generics, the lack of useful types like tuples and enums, the bolted on module system, to the annoying error handling, to say the least.

That said, compile times are great, the concurrency is dead simple, it's performant, and it's still easy to be really productive in it so it's not like I'd never consider it. Many other languages have many of the same issues, anyway.