MurphyA/hacker-news huggingface dataset:
by aDyslecticCrow | 2025-11-19 12:14:50+00:00
Computers beat us in maths decades ago, yet LLMs are not able to beat a calculator half of the time. The maths benchmarks that companies so proudly show off are still the realm of a traditional symbolic solvers. You claiming much success in asking LLMS for math makes me question if you have actually asked an LLM about maths.

Most AI experts not heavily invested in the stocks of inflated tech companies seem to agree that current architectures cannot reach AGI. It's a sci-fi dream, but hyping it is real profitable. We can destroy ourselves plenty with the tech we already have, but it won't be a robot revolution that does it.
by w3news | 2025-11-19 12:14:55+00:00
Microsoft just fork Atom, and Atom had already good and a lot of extensions. Before Microsoft buy Github, there was no reason to switch to VSCode instead of Atom. When Microsoft buy Github, it received Atom from the Github team, and Microsoft stops the development of Atom. VSCode was just Atom with the Microsoft brand, and some little tweaks from Microsoft, never a game changer compared to Atom, like Atom was in it's time. Now Antigravity is again a fork with some little tweaks from VSCode, no game changer, just with the Google branding.
by croes | 2025-11-19 12:15:35+00:00
Having many kids is often because of a necessity like cheap workforce for the family or high child mortality.

Kids can be fun but also can be really exhausting.

How many kids are really born just for having am offspring and not because of other reasons.

If people can consciously decide to have or not to have kids my bet is on falling birth rates.

For stable population you need two kids per couple and first could be an eye opener that children are a lot of work.
by CyberWatchAU | 2025-11-19 12:15:45+00:00
https://cyberwatchau.com CyberWatch AU is a lightweight, fast threat-intel and vulnerability-tracking platform focused on Australian security news. It aggregates breaking cyber incidents, vendor advisories, and CVE updates into a single, no-BS feed with simple filtering and a clean UI. Built to give security engineers and tech-minded readers a quick snapshot of what actually matters each day.
by pranav_dhoolia | 2025-11-19 12:15:56+00:00
i came across the huxley godel machine while building clonebob.com. my key takeaways are: - it is a self-evolving codebase - it improves against a benchmark (e.g. SWE-bench, polyglot) over multiple iterations (genetic variants of itself)

my questions: - in the paper, it is applied only to SWE-bench, while it is said that it is extensible to other domains. what if the "domain" in question is arbitrary? do we construct our own benchmark manually?

- how does it hold up against OpenEvolve and Backpropamine? (it is my believe that Backpropamine shows actual plasticity, and not just in code; i.e. it is fundamentally different from HGM and DGM)?

- which one of these paradigms are more promising?
by mattacular | 2025-11-19 12:15:59+00:00
There is a prevailing mentality that LLMs make it easy to become productive in new languages, if you are already proficient in one. That's perhaps true until you suddenly bump up against the need to go beyond your superficial understanding of the new language and its idiosyncrasies. These little collisions with reality occur until one of them sparks an issue of this magnitude.

In theory, experienced human code reviewers can course correct newer LLM-guided devs work before it blows up. In practice, reviewers are already stretched thin and submitters absolute to now rapidly generate more and more code to review makes that exhaustion effect way worse. It becomes less likely they spot something small but obvious amongst the haystack of LLM generated code bailing there way.
by imtringued | 2025-11-19 12:17:16+00:00
I personally think the article still concluded that AA batteries suck. They suck because they present a "standard" interface that is utterly dependent on the specific battery chemistry. What people expect is that the device should support a large voltage and current range as input, but they don't.

The AA battery standard is nothing but compromises. Zinc-carbon sucks because the internal resistance is too high, making them a throwaway product that shouldn't be sold. Alkaline batteries are okay-ish, but they are not rechargeable.

NiMH has a lower voltage than Alkaline. Any sane person would have proposed a different standard than AA for the rechargeable case so that the devices can be built to support the lower voltage out of the box. Meanwhile lithium AA batteries "suck" because lithium based batteries are too good (3.6 V) in comparison to their Alkaline and NiMH counterparts.

To maintain the facade of the AA standard, the lithium AA batteries must have an internal DC converter. You might now ask what the problem with a DC converter is, after all, it seems to work just fine. The AA standard is based around the idea that the voltage across the battery is always on. There is no concept of a turned off battery. This means the DC converter is always on and actively discharging the lithium battery. If the lithium AA battery is of low quality, it may not shut off and deeply discharge itself or prevent further recharging. If the lithium AA battery is of high quality, you can probably (wishful thinking) recharge it, as long as the charger comes from the same vendor. The charger turns on at higher voltages (3.7 V to 5 V), which is how the lithium AA battery detects that it needs to switch to the charging mode. When you see some ridiculous advertising like 3200mWh, always consider that this might be equivalent to some much smaller capacity NiMH/Alkaline battery, due to the permanent self discharge.
by yakshaving_jgt | 2025-11-19 12:17:41+00:00
I don't write Rust so I don't really know, but from someone else's description here it sounds similar to `fromJust` in Haskell which is a common newbie footgun. I think you're right that this is a case of not using the language properly, though I know I was seduced into the idea that Haskell is safe by default when I was first learning, which isn't quite true — the safety features are opt-in.

A language DX feature I quite like is when dangerous things are labelled as such. IIRC, some examples of this are `accursedUnutterablePerformIO` in Haskell, and `DO_NOT_USE_OR_YOU_WILL_BE_FIRED_EXPERIMENTAL_CREATE_ROOT_CONTAINERS` in React.js.
by meltyness | 2025-11-19 12:17:44+00:00
tokio default behavior within a task is to ignore panics, such as an Err/None unwrap, and only crash that task, so it's impact limited so that's nice, maybe that's where the snowblindness came from.

it'd be kinda hard to amend the clippy lints to ignore coroutine unwraps but still pipe up on system ones. i guess.

edit: i think they'd have to be "solely-task-color-flavored" so definitely probably not trivial to infer
by emyrk | 2025-11-19 12:18:12+00:00
Using Golang as the source is easier for a Golang backend team. Native types are always going to be the most convenient.

The theory when we came out with guts was that Golang's typing system is very simple (this was before generics when it was made). So how hard could it be to write a simple converter?

The first iteration of guts was written in an afternoon. Eventually I moved it to its own repo, mainly for personal use.

So honestly it really comes down to making it as easy as possible to write backend code. Using another spec that autogen's the Golang would be an extra step we did not feel we needed.
by jeroenhd | 2025-11-19 12:19:22+00:00
The protocol makes sure a message sent from one phone/tablet/watch makes it to the other end. If you want to synchronise that message between your devices, you'll have to build that locally.

Apple, Google, and Samsung can synchronize SMS messages through their cloud services, so the same also goes for RCS. For more privacy-oriented folk, KDE Connect can also offer SMS messaging to the desktop by synchronising locally with a connected phone.
by segmenta | 2025-11-19 12:19:39+00:00
In the demo - for the voice and music, it uses the ElevenLabs MCP server for TTS, and ffmpeg locally to stitch the audio together. In the demo we pull content from Tweets via an MCP tool, but you can swap that step for anything — for example, fetching your saved articles with curl. There’s no special model required; any LLM that can call tools will work.
by emyrk | 2025-11-19 12:20:33+00:00
I know there exists more generic typing tools. One idea I had was to make a "guts" to convert Golang -> Generic Typing -> All languages.

The reason to keep Golang as the source of truth is these types originate from the backend. So when you are writing the backend, it is just the easiest place to write and maintain things. No obstacles.

Golang types are also very simple. I imagine almost all Go types can be converted because of that.
by Esophagus4 | 2025-11-19 12:21:57+00:00
College for trade schools almost never costs $100k. Again, this is Googleable.

Look at this list of schools they support: https://techforce.org/fordphilanthropy/

Most of them are community colleges and trade schools that charge around $10k - $30k total for the degree. In which case, an additional $5k in scholarships is nice.

If you want to be mad at a big company, this probably isn’t your strongest leg to stand on, and there are plenty of other targets for you to be mad at.
by TheCraiggers | 2025-11-19 12:23:03+00:00
> I don't quite think companies realize how bad it would be if EG AWS was hacked.

I don't think they'd care. Companies only care about one thing: stock price. Everything rolls up into that. If AWS got hacked and said company was affected by it, it wouldn't be a big deal because they'd be one of many and they'd be lost in the crowd. Any hit to their stock/profits would be minimal and easily forgotten about.

Now, if they were on prem or hosted with Bob's Cloud and got hacked? Different story altogether.
by ants_everywhere | 2025-11-19 12:23:11+00:00
No it's not. I mute people who post that sort of content and it's the math instance.

If you are forced to see it despite spending most of your time silencing it, it's not the people you follow it's the culture.

Judging from the CEO's letter and actions, it sounds like it's possible a bad culture example was set by the top of the project. Although that doesn't always happen. For example, Linux doesn't have a culture of over-the-top personal insults despite that being Linus's personal style.
by dspillett | 2025-11-19 12:24:33+00:00
> To do simple input validation on data that has the potential to break 20% of the internet?

There will always be bugs in code, even simple code, and sometimes those things don't get caught before they cause significant trouble.

The failing here was not having a quick rollback option, or having it and not hitting the button soon enough (even if they thought the problem was probably something else, I think my paranoia about my own code quality is such that I would have been rolling back much sooner just in case I was wrong about the “something else”).
by beeflet | 2025-11-19 12:24:43+00:00
I don't have time to fiddle around with some locked-in ecosystem in exchange a little more productivity or the ability to pretend not to be using my computer. And I don't even have a day job.

If it was just a heads-up display for android like xreal, but low power and wireless that might be cool for when I'm driving. But everyone wants to make AI glasses locked into their own ecosystem. Everyone wants to displace the smartphone, from the Rabbit R1 to the new ray-bans. It's impossible.

In the end this tech will all get democratized and open sourced anyways, so I have to hand it to Meta and others for throwing money around and doing all this free R&D for the greater good.
by jeroenhd | 2025-11-19 12:25:02+00:00
I know what net neutrality is. I just doubt it applies to RCS. Packet switched versus circuit switched transmission of digital messages is just an implementation detail.

With the introduction of LTE, everything from calls to texts have been IP based TCP/UDP/maybe SCTP packets. Does WhatsApp get to file a net neutrality violation because the phone's native SIP client gets priority by the modem/carrier? Does Gmail get to file a claim because SMS messages exchanged through SIP are delivered faster than their push notifications? Does Telegram get to file a claim because you have to pay for a megabyte of roaming costs traveling abroad while you only pay for a single "SMS" despite both being a TCP packet? I don't know. I don't expect those claims to apply.

RCS is the same, in that it's a core carrier feature that communicates between your phone's messaging service and your carrier's infrastructure. RCS' envelope is actually quite similar to MMS' design, except MMS' data transmission still had to be implemented in a circuit-switched way because it came from the 3G era.

Google muddied the water by offering carrier infrastructure (an RCS server) worldwide to any phone that wants to connect to it. It's as if I would host my own SMSC I'd let anyone in the world connect to. It's not the normal use case and as carriers are implementing their own RCS services, I expect this anomaly to slowly disappear over time.

The distinction between third party messengers and SMS/MMS/RCS is a good thing, in my opinion. SMS/MMS/RCS providers need to be able to exchange what is essentially a live feed on a phone number with law enforcement at a moment's notice. Messengers like Signal don't. If third party services would fall under the same category as RCS, it'd stand to reason that the same would also apply in terms of law enforcement orders, and I don't think anyone but the law enforcement agencies would want that.
by mananaysiempre | 2025-11-19 12:25:28+00:00
No, in the cases 'throwaway150 and I are talking about, your site is not back up. You (hopefully) got an email in your inbox saying your hosting provider has decided to take your website offline because of anomalous traffic or whatever, and after the attack ends you’ve got at least a couple of days of back and forth with support ahead of you before your downtime is actually over.
by ctenb | 2025-11-19 12:25:31+00:00
Regarding typing latex vs unicode, I use WinCompose/XCompose with a list of bindings that include most latex symbols. So instead of \cup I'd type <compose>cup

For reference, here is my personal (still evolving) .XCompose https://github.com/chtenb/dotfiles/blob/master/.XCompose
by shadowgovt | 2025-11-19 12:25:41+00:00
Oh, difference in definitions. You mean "non-configurable web server." Because you could definitely use a static site generator to create multiple versions of the site data and then configure your web server to select which data is emitted.

But agreed; if your web server is just reflecting the filesystem, add this to the pile of "things that are hard with that kind of web server." But perhaps worth noting: even Apache and Python's http.server can select the file to emit based on the Accept header.
by hnarn | 2025-11-19 12:26:09+00:00
Presumably optimal rollout speed entails something like or as close to ”push it everywhere all at once and activate immediately” that you can get — that’s fine if you want to risk short downtime rather than delays in rollout, what I don’t understand is why the nodes don’t have any independent verification and rollback mechanism. I might be underestimating the complexity but it really doesn’t sound much more involved than a process launching another process, concluding that it crashed and restarting it with different parameters.
by segmenta | 2025-11-19 12:26:20+00:00
Cline is great, but it’s primarily focused on coding workflows, similar to Claude Code. RowboatX is aimed at a different category: background agents for non-coding automations (e.g. meeting prep, daily briefings, etc).

The big difference from Claude Code (and Cline) is that RowboatX can spin up persistent background agents that run on schedules, use the system shell, and call MCP tools to automate tasks outside of coding.
by lelanthran | 2025-11-19 12:26:21+00:00
> Considering how much of the world runs on WhatsApp alone, that’s laughably wrong.

People would just switch to the next IM platform. Most would forget they ever needed whatsapp 12 hours after a permanent whatsapp shutdown.

I mean, the only reason the majority of whatsapp users use whatsapp is the network effect.

Take that away and you think people would just give up trying to IM each other?
by binsquare | 2025-11-19 12:26:35+00:00
Today it's clear that there are limitations to LLM's.

But I also see this incredible growth curve to LLM's improvement. 2 years ago, I wouldn't expect llm's to one shot a web application or help me debug obscure bugs and 2 years later I've been proven wrong.

I completely believe that trading is going to be saturated with ai traders in the future. And being able to predict and detect ai trading patterns is going to be an important leverage for human traders if they'll still exist
by delaminator | 2025-11-19 12:27:24+00:00
In an ironic twist, Claude tells me it is Rust because of the error messages.

Each project I have tried a different language.

It liked Racket but didn't think Typed Racket as really worth it.

Erlang worked out well.

It does pretty good at C#.

But don't take my word for it

> would you prefer erlang, rust, racket or c#

● Interesting comparison - these are very different tools. My preference would depend heavily on the problem:

For What We Just Did [polling an API]

I'd pick Erlang - and here's why this specific project validates that choice:

1. Long-running stateful service: Needs to run 24/7 polling aircraft data 2. Built-in state management: Mnesia for regions, rules, recent sightings 3. Concurrent by default: Multiple aircraft being processed, periodic polling, web server - all concurrent without thinking about it 4. Reliability matters: Missing aircraft alerts due to crashes would be bad; OTP supervision handles this

But Generally?

Rust would be my favorite overall: - Compile-time correctness catches whole classes of bugs that runtime systems miss - Performance without compromise - no GC pauses, predictable behavior - Modern ergonomics - cargo, excellent error messages, strong type inference - Growing ecosystem - tokio for async, axum for web, no longer as sparse as it was

The catch: Rust's learning curve is real, and for rapid prototyping it can be slower.

Racket is fascinating for: - Language-oriented programming - when you need to build DSLs - Exploratory work - REPL-driven development is wonderful - Education/research - the language tower concept is unique

But it's too niche for production systems most of the time.

C# I'd choose when: - Enterprise integration is critical - existing .NET infrastructure - Team familiarity - large pool of developers - Rapid development with good tooling - Visual Studio, LINQ, async/await

But it feels heavy and tied to the Microsoft ecosystem.

The Honest Answer

For systems that must not fail (telecom, distributed databases, message queues): Erlang

For performance-critical systems where correctness matters (OS components, embedded, infrastructure): Rust

For most other things (web apps, APIs, tools, scripts): I'd probably reach for something lighter like

Go or Python rather than any of these four.
by antihero | 2025-11-19 12:27:30+00:00
The unwrap should be replaced by code that creates enough alerting to make a P0 incidident from their canary deployment immediately.

OR even, the bot code crashing should itself be generating alerts.

Canary deployment would be automatically rolled back until P0 incident resolved.

All of this could probably have happened and contained at their scale in less than a minute as they would likely generate enough "omg the proxy cannot handle its config" alerts off of a deployment of 0.001% near immediately.
by TheOtherHobbes | 2025-11-19 12:27:34+00:00
The primary product of these enshitified companies is a perpetually rising stock price. Beyond a certain size it becomes more profitable to play bureaucratic, legal, financial, and other corporate games at the expense of the nominal service that's being sold.

They're a bizarre economic phenomenon. They basically sell casino chips (stocks) and use bureaucracy (friction and complexity), PR (lies), and intimidation to goose their value.
by whizzter | 2025-11-19 12:27:50+00:00
"Complaining neckbeards" are a part of the problem, but the bigger issue is often developer-users that has oversight (or preference due to "control") with shitty UI-decisions that have little interest or agency in fixing them. The non-movment complainers are more of an alibi for those developers with little UI improvement interests.

GIMP is just bad sadly even when it comes to basics, it has nothing to do with wanting Adobe products but more about GIMP just being a "coders-tool".

Every time in the last decade I checked, i still had to input a resolution when creating a new image layer.. that's a fundamental operation that hasn't been that clumsy in Photoshop since the 90s (Photoshop has "infinite" layers, they can be larger than the image, yes it's "bloated" but that's what you want as an artist 90% of the time.. not an annoying border).
by mlrtime | 2025-11-19 12:27:59+00:00
FWIW I don't agree with anything you're saying but again, I'm glad there is some debate from another side.

I suck at writing software, like bad. I can't remember syntax at all. I couldn't write working code on a whiteboard if you asked me.

But I don't know how to solve problems very well, and I'm good at understanding what people want and don't want. I do understand logic and pseudocode.

The code LLMs write is good enough for 99% of the things I need it for, and I'm not writing code that will be used in some life determining situation, and I'd wager that most aren't either.

We could debate on if my code is usable/supportable long-term, by myself or others. However, I don't see how that debate would be any different if I wrote it myself (worse) or somebody else.
by SXX | 2025-11-19 12:28:02+00:00
If you are good, like, no?

I mean I crafted complete complex game prototype using Gemini 2.5 Pro with nearly zero coding. I done it in a week: with client-server architecture, robust networking, AI, acceptance test coverage, replays.

It just different way to build software. You just spend 30% of time on specification, 30% on testing and 30% on refactoring also using AI.

Actual slop generarion take like 10% of time and rest of the time you turn it into maintainable code.

Of course you can do it manually, but then it will take 5-10 times the time and you wont be as flexible in changing things because with AI you can do major refactoring in a day, but manually it could take weeks and kill the project.
by quotemstr | 2025-11-19 12:28:09+00:00
If the error had been an exception instead of a result, could have bubbled up

I have been saying for years that Rust botched error handling in unfixable ways. I will go to the grave believing Rust fumbled.

The design of the Rust language encourages people to use unwrap() to turn foreseeable runtime problems into fatal errors. It's the path of least resistance, so people will take it.

Rust encourages developers to consider only the happy path. No wonder it's popular among people who've never had to deal with failure.

All of the concomitant complexity--- Result, ?, the test thing, anyhow, the inability for stdlib to report allocation failure --- is downstream of a fashion statement against exceptions Rust cargo-culted from Go.

The funniest part is that Rust does have exceptions. It just calls them panics. So Rust code has to deal with the ergonomic footgun of Result but pays anyway for the possibility of exceptions. (Sure, you can compile with panic=abort. You can't count on it.)

I could not be more certain that Rust should have been a language with exceptions, not Result, and that error objects are a gross antipattern we'll regret for decades.