MurphyA/hacker-news huggingface dataset:
by neilv | 2025-06-03 18:47:06+00:00
> If you're writing for smart people about important things, you're writing for the young.

PG has seemed to have a fixation on youth, since at least one essay before YC was started, and there's still hints of it in YC practices today.

And I sometimes wonder whether our field would have so much techbro ageism, and the irrationally large egos of many early-20s 'founders', had PG not influenced tech industry culture quite so much.

Traditionally, in our teens and early 20s, we'd be vapid hormonal know-it-alls. (That's OK, it's normal, I did it too; no criticism.)

And the most validation of that we'd get (outside our equally naive peers) would a condescending pat on the head, from people who'd gone through that enthusiastically naive developmental phase themselves.

About up until the time we had to get a real job, and then we were confronted with not being as good as the experienced people, and the real world wasn't putting congratulatory star stickers on our homework.

So we'd grow out of it, and buckle down for the real education of post-school life.

Until then -- unless we were a not-yet-injured athlete in a marketable spectator sport, or an aspiring star working our way up the Hollywood casting couches, or being lured into a cult -- not many people would tell us that we were the superior person to be pursuing something, better than the people with experience and wisdom.

Maybe that was a good thing. (Not the youth who got exploited, but that the rest of us weren't given stuffed heads when we needed to start learning with humility.)

But then we got survivor bias kids of the dotcom boom and early PG influence era, like Zuckerberg, who, once they won the lottery, very vocally promoted the ageism. Because, hey, it worked for them.

The current tech industry jobs bloodbath will disabuse a lot of people of the silliness, too late for them. But we'll still have founders/managers aspiring to be billionaires, taking astrology-based lottery number-picking advice from past lottery winners.
by DonHopkins | 2025-06-03 18:47:58+00:00
In practice that's what you could do with HyperLook on NeWS:

SimCity, Cellular Automata, and Happy Tool for HyperLook (nee HyperNeWS (nee GoodNeWS))

HyperLook was like HyperCard for NeWS, with PostScript graphics and scripting plus networking. Here are three unique and wacky examples that plug together to show what HyperNeWS was all about, and where we could go in the future!

https://donhopkins.medium.com/hyperlook-nee-hypernews-nee-go...

HyperLook SimCity Demo Transcript

This is a transcript of a video taped demonstration of SimCity on HyperLook in NeWS.

https://donhopkins.medium.com/hyperlook-simcity-demo-transcr...

Discussion with Alan Kay about HyperLook and NeWS:

Alan Kay on “Should web browsers have stuck to being document viewers?” and a discussion of Smalltalk, HyperCard, NeWS, and HyperLook

https://donhopkins.medium.com/alan-kay-on-should-web-browser...
by pie_flavor | 2025-06-03 18:48:22+00:00
No, actually, an operator that's essentially a macro for this entirely boilerplate operation would be less terrible, exactly the same decision Rust made for the exact same reason. So would Cox's proposal, so would others. Doing nothing, as a permanent solution, because you can't figure out which of the better things you should do, is not a virtue. You may be confusing it with the virtue of holding out on simpler solutions while a better solution is implemented, or the virtue of not solving things which aren't problems, but this is a problem and they have intentionally blocked the solution indefinitely.
by eszed | 2025-06-03 18:48:40+00:00
Oh, my yes. That is the (literal) trillion (and more) dollar question alive in the world right now.

My guess (though I repeat your BWDIK) is that the US military would adapt less quickly than the Ukrainians (if only because it's got a lot more doctrinal inertia), but more rapidly than the Russians did. There is a sub-genre of military history dedicated to figuring out how/why democracies - going back to antiquity - tend to punch above their military weight. The suppositions tend to cluster around 1.) they don't fight unless it's truly popular, which unlocks a comparative man-power advantage, and 2.) an egalitarian social / political structure makes distributed authority and acceptance of new ideas more possible / palative.

Unfortunately, the Russians have now adapted to drone warfare (even if they haven't matched the innovative pace of the Ukrainians), and I think Western Europe should be more scared of their military than they were two years ago. That's my cold hard-eyed real politiik case for supporting Ukraine: the West needs the world experts on this new military paradigm on-side. Perhaps the primary challenge this argument faces (particularly in the US - the Europeans don't all share this psychology) is a reluctance to admit (in culture or military doctrine) that "we" aren't The Best at something. The notion that OCS could be materially improved by importing any random captain from the Ukrainian front to teach a few classes is a tough one to swallow.

Disclaimer: I'm not military, only an observer through media, and through conversations with current and ex-military friends. Several of those military friends have become, in the past few years, super interested in flying drones in their spare time. They're already preparing to adapt, even if their commands are moving more slowly.
by ulnarkressty | 2025-06-03 18:49:05+00:00
Pandora's box is now open and multiple groups have access to drones[0].

This is something that I think escapes engineers in this line of work - that something they invented will eventually end up (legally or not) in the hands of people with no scruples.

[0] - https://www.msn.com/en-za/news/other/drones-in-africa-are-a-...
by jjani | 2025-06-03 18:49:08+00:00
Hi, early user here :) Liking the product so far. We just started using the CLI parts for our RN app, with your cloud translations.

Few things to put on your roadmap if they aren't on it yet:

- Would like it if we could set the model per language. I'm sure you do your best trying to find the best one for each language, but in our experience some of them aren't optimal yet.

- Multiple source languages would be cool. Example: It can make sense to have JA as source for KO but EN as source for FR. Or probably better, sending both (e.g. EN + JA when doing KO).

- MCP doesn't seem to be working (we posted a log on the discord)

- We seem to have spotted cases where key names were taken into account a little too much when translating, but understand this is super hard to tune and can be fixed by improving our keys.
by hnlmorg | 2025-06-03 18:49:36+00:00
I do something similar. I leave a comment but with a short comment why it’s inverted.

It’s usually pretty obvious why: eg

if err == nil { // we can exit early because we don’t need to keep retrying

But it at least saves me having to double check the logic of the code each time I reread the code for the first time in a while.
by GoatInGrey | 2025-06-03 18:49:44+00:00
The rub there is that you'll have varying styles in which error handling statements appear in your code. With simplistic instances appearing one way and less simplistic ones appearing similarly or differently depending on where each lands on the complexity spectrum. The idiomatic approach is for all instances to be written in the same way regardless of technical nuances.

All of that aside, I've come to learn that passing errors up the call stack without any wrapping or handling is a code smell. It is less than useless for me to attempt setting the value of cell A1 in an Excel sheet to "Foo" and then receive an out-of-range error because the developer made no attempt to even inform me of the context around the error. Let alone handling the error and attempting to correct state before giving up.

In my Excel example, the cause of the error was a data validation problem a couple columns over (F or so). The error was legitimately useless in troubleshooting.
by cdrini | 2025-06-03 18:50:02+00:00
> One could also conclude that a large portion of software engineering is rather is mostly implementation of things that have been implemented many times before

Strong +1. That's one of the reasons I enjoy using LLMs, cause I'm often using it for the pieces of code which I don't even find rewarding to write; it's just glue code which I know has been written 1000 times over, which _I've_ already written 1000 times over across different projects.
by hackingonempty | 2025-06-03 18:51:25+00:00
The draft design document that all of the feedback is based on mentions C++, Rust, and Swift. In the extensive feedback document you link above I could not find mention of do-notation/for-comprehensions/monadic-let as used Haskell/Scala/OCaml. I didn't find anything like that in the first few pages of the most commented GitHub issues.

You make it out like the Go Team are programming language design wizards and people here are breezily proposing solutions that they must have considered but lets not forget that the Go team made the same blunder made by Java (static typing with no parametric polymorphism) which lies at the root of this error handling problem, to which they are throwing up their hands and not fixing.
by pvg | 2025-06-03 18:51:50+00:00
Right but modern theatre is pretty new itself. The number of people involved in performance for the enjoyment of others has spiked, err, dramatically. My point is that making this type argument seems to invariably involve picking some narrow thing and elevating it to a true and valuable artform deserving special consideration and mourning. Does it have a non-special-pleading variety?
by mlsu | 2025-06-03 18:52:19+00:00
Efficiency to corporate knowledge? Absolutely not, no way. My coworkers are beginning to use AI to write PR descriptions and git commits.

I notice, because the amount of text has been increased tenfold while the amount of information has stayed exactly the same.

This is a torrent of shit coming down on us, that we are all going to have to deal with it. The vibe coders will be gleefully putting up PRs with 12 paragraphs of "descriptive" text. Thanks no thanks!
by maxpr | 2025-06-03 18:52:46+00:00
> half-assed translation that was obviously made by a machine

That's exactly what we want to solve.

Here's the thing:

It turned out, AI translates better than humans when provided with enough correct context. Both macro context, like what the product does, and micro context, like what the component represents on screen and how it relates to other components.

As a result, algorithms extract the needed contextual hints, and a correctly configured LLM model finishes the rest.
by archagon | 2025-06-03 18:53:00+00:00
I am also from Russia. Since this apparently gives me authority to speak on these matters, I can confidently say that what’s happening in the US today looks remarkably like Putin’s consolidation of power. How long until Congress is nothing more than an executive rubber stamp like the Duma? The judicial system is currently functioning as the only check against executive overreach, and it’s just a matter of time until injunctions are nullified or ignored as a matter of course.
by tinkywinky22 | 2025-06-03 18:53:15+00:00
I’ve just launched Zelkra, a simple marketplace where devs and indie hackers can sell unfinished side projects, SaaS MVPs, domains, or even just ideas.

We all have half-built tools, apps, and repos sitting idle — Zelkra gives them a second chance. It’s free to list, and you keep 100% of the sale. Optional upgrades boost your listing for more visibility.

I'm trying to make this a “micro-Flippa” for makers — simple, low-pressure, and useful. Would love feedback from HN:

What would make you want to list a project? If you're a buyer, what filters or details matter most? Should I stay commission-free or charge a % for verified deals?
by godelski | 2025-06-03 18:53:34+00:00
I understand how you interpreted my comment as this. That's my bad.

But even when taking state of the art knowledge as a ground truth aligning to that is incredibly hard. Medicine is a great example. You're trying to create a causal graph in a highly noisy environment. You ask 10 doctors and you'll get 12 diagnoses. The problem is subtle things become incredibly important. Which is exactly what makes measurements so fucking hard. There is no state of the art in a well defined sense.

The point is that in most domains this is how things are. Even in programming.

Getting the right answer isn't enough
Ask HN: Carbon Sequestration Recommendations
by gametorch | 2025-06-03 18:53:45+00:00
Hello HN!

We are GameTorch, a pre-launch startup that lets you generate 2d video game assets and publish them to the Creative Commons.

We use image models that were energy intensive to train. We care about the earth and have made a promise to be carbon positive at the inference level. It would be extremely ideal if the sum of all AI driven companies were so carbon positive that we also outweigh the costs of training these models.

We need to make good on our promise. Does HN have any recommendations for carbon sequestration companies?

Separately, any feedback or advice on the following analysis of our energy usage and carbon emissions would be greatly appreciated. We really truly care about making a positive impact on the Earth and are eager to hear about any flaws in our thought process. It's not about PR, it's about doing things the right way. Here's our current analysis:

Energy Use, CO₂ Emissions, and Cost per Image Generation

Approximate energy use per image generation: ~0.5 Wh (watt-hours)

CO₂ emissions per image (US grid average): ~0.00008 kg (0.08 grams)

Total for 1,000 images: 0.5 kWh, 0.08 kg CO₂

Context: A typical US domestic flight (e.g., NYC to Chicago) emits about 300 kg CO₂ per passenger—over 3 million times more than a single image generation.

Context: Boiling water for one pour-over coffee (about 12 oz/350 ml) uses ~50 Wh and emits ~0.02 kg (20 grams) CO₂—about 100× more energy and 250× more CO₂ than generating one image.

Cost to sequester CO₂ from 1,000 image generations: At scale, permanent carbon removal is about $100/tonne. Sequestering 0.08 kg (from 1,000 images) costs about $0.008 USD.
by tptacek | 2025-06-03 18:54:20+00:00
It's even simpler than what 'rfrey said. You're here using "ground truth" in some kind of grand epistemic sense, and I simply mean "whether the exit code from a program was 1 or 0".

You can talk about how meaningful those exit codes and error messages are or aren't, but the point is that they are profoundly different than the information an LLM natively operates with, which are atomized weights predicting next tokens based on what an abstract notion of a correct line of code or an error message might look like. An LLM can (and will) lie to itself about what it is perceiving. An agent cannot; it's just 200 lines of Python, it literally can't.
by Teever | 2025-06-03 18:54:46+00:00
I'm very interested in the consequences of vigilante applications of this kind of technologies. Imagine a scenario where people start taking out corrupt police officers who have until now been able to terrorize small communities with impunity.

It may motivate actual reform in policing because law enforcement will realize that police officers who kill innocent people with no regard for the law are safer in prison than out on the streets with a paid vacation / desk job punishment.
by bonoboTP | 2025-06-03 18:54:47+00:00
Yes, the consequences will be that mediocre devs will have a harder time finding jobs. The higher skilled will be fine (for some time at least), but the trend is clear. LLMs are going to make the top engineers more effective and the less skilled will have less and less to contribute. The skill floor for useful contributions is rising. Just like in other industries. Most of the world's software projects aren't at the forefront of humanity's knowledge that needs brilliant minds. It's integration, dependencies, routing around edge cases, churning out some embedded code for another device, mostly standard stuff but enough differences that previous automation paradigms couldn't handle the uniqueness. LLMs plus a few highly skilled people (who know how to prompt them effectively) will get it done in less time than a team does today.

It's not that LLMs turn low skilled people into geniuses, it's that a large segment of even those with enough cognitive skills to work in software today will no longer have marketable skill levels. The experienced good ones will have some, but a lot won't.
by genewitch | 2025-06-03 18:54:49+00:00
Software that came preloaded with what sounds suspiciously like a rootkit to keep the background service running on some phones.

Please don't "don't that phone then" because it's the same all the way down to rotary telephones.

I still didn't consent to meta tracking me on my telephone. I understand the shadow profiles and tracking pixels and whatnot, but cmon.

Next year "actually meta was listening to conversations captured by android devices and using it to target ads"

Don't use a cellphone? Meta and Google track desktop web use. Don't use a computer? Okay, that's cool.
by aerhardt | 2025-06-03 18:54:59+00:00
> it takes more time to be producted, and it is harder too because you always need to supervise and correct what's done

This is hogwash, the lead dev in charge of this has commented elsewhere that he's saved inordinate amounts of time. He mentioned that he gets about a day a week to code and produced this in under a month, which under those circumstances would've been impossible without LLM assistance.
by jeroenhd | 2025-06-03 18:55:03+00:00
Java has had AOT compilation for a while, so traditional GC and its massive overhead are no longer a strict necessity. Even AOT Java will probably stay behind Swift or any other natively compiled language in terms of memory usage, but it shouldn't be that drastic.

As for performance and locality, Java's on-the-fly pointer reordering/compression can give it an edge over even some compiled languages in certain algorithms. Hard to say if that's relevant for whatever web framework Apple based their service on, but I wouldn't discount Java's locality optimisations just because it uses a GC.
by hackingonempty | 2025-06-03 18:55:03+00:00
The language is designed for Google, which hires thousands of newly graduated devs every year. They also have millions of lines of code. In this environment they value easy of onboarding devs and maintaining the codebase over almost everything else. So they are saddled with bad decisions made a long time ago because they are extremely reluctant to introduce any new features and especially breaking changes.
Ask HN: Most (Writing) Tools Are AI-Enabled, Not AI-First. What's Still Missing?
by Danao | 2025-06-03 18:55:47+00:00
I feel like most AI writing tools are still just that—tools with AI bolted on. They’re not really built around how people actually write. There’s a lot of smoke and mirrors, and not enough stuff that fits the real context and constraints of writing.

I’m trying to figure out where the real gaps are, so builders (myself included) can aim at problems that matter, not just whatever’s hyped this week.

So I’d love to hear from folks who write a lot (docs, specs, marketing copy, essays, whatever) and already use AI tools, (ChatGPT, Claude, built-in stuff like Notion’s AI etc.).

Where does it break your flow? What keeps you from using it more? If you could wipe your current setup and build an AI-first editor from scratch, what would have to be in it?

Looking for edge cases, pain points, weird workflows, hacks you’ve come up with, that one feature you keep wishing existed, anything that’s real and grounded.
by roywiggins | 2025-06-03 18:55:49+00:00
Annoying. The actual braille on the sign was "⠁⠒⠑⠎⠎⠊⠼" which I gather means "accessible" in abbreviated braille. None of my attempts got it to even transcribe it to Unicode characters properly. I got "elevator", "friend", etc. Just wildly making stuff up and completely useless, even when it wasn't distracted by the No Smoking sign (in the second case I cropped out the rest of the sign). And in all cases, supremely confident.

This seems like something a VLM should handle very easily, but instead I got pure nonsense.

https://www.facebook.com/share/p/12Gw55Gr2SZ/
by ummonk | 2025-06-03 18:56:06+00:00
There are two possibilities.

1) There isn't consensus that improved syntax for error handling is needed in the first place. If that is the case, they should just say so, instead of obfuscating by focusing on the number of proposals and the length of the process.

2) There is consensus about a need for improved error handling syntax, but after seven years of proposals they haven't been able to find community consensus about the best way to add said syntax. That would mean that improved syntax for error handling is necessary, but the Go team is understandably hesitant to push forward and lock in a potentially inferior solution. If that is the case, then would be reason to continue working on improved syntax for error handling, so as to find the best solution even if it takes a while.
by isoprophlex | 2025-06-03 18:56:08+00:00
I'm running a large scale object detection/classification and ocr pipeline at the moment, figuring out the properties of all doorbells, mailboxes and house number signs in an european country (don't ask lmao).

This article resonates a lot, we have OCR and "semantic" pipeline steps using a VLM, and while it works very well most of the time, there are absurdly weird edge cases. Structuring the outputs via tool calls helps a little in reducing these, but still, it's clear that there is little reasoning and a lot of memorizing going on.
by unclad5968 | 2025-06-03 18:56:15+00:00
Yeah that makes sense. My assertion was definitely incorrect, but also not really what I was trying to describe. My argument is that they are not conceptually different. The implementation is different, in that a union occupies the same memory for either value, but whether they occupy the same memory or not, you have to check the value to determine that is an error. The compiler can force you to handle multiple return values the same way it can force you to check a variant.
by jdonaldson | 2025-06-03 18:56:21+00:00
Zelda series has always been a showcase for great low level aesthetic gameplay design choices. I love how they handled simple things like grid-based movement : https://dev.to/robotspacefish/game-studies-link-s-movement-i...

I feel like the dungeons in BOTW all resemble the rooms in Portal. I.e. they feel highly artificial and contrived. However, this lets the player focus on the puzzle itself, rather than worry about the story at that moment. The puzzles there really force you to "get good" at a particular maneuver the game requires of the character. Rather than getting an item or advancing a world event, the player's reward is simply to suck less by accomplishing the task.

Plus, let's be honest, Zelda's story is really pretty fungible. The linear progression was mainly due to hardware limitations rather than aesthetic choice.
by guptadeepak | 2025-06-03 18:56:40+00:00
As AI-powered answer engines reshape web discovery, growth tactics are shifting from classic SEO to Answer Engine Optimization (AEO). Three key changes: structuring content for entity extraction, optimizing for conversational queries, and using advanced schema markup for machine parsing.

A major challenge is tracking ROI as zero-click answers obscure attribution—metrics like “answer appearance rate” are emerging but still evolving. How are others adapting their content architecture for AI retrieval and handling attribution in this new landscape?
by tptacek | 2025-06-03 18:56:45+00:00
Especially coming from you I appreciate that impulse, but I had the experience of running across someone else the Internet (or Bsky, at least) believed I had no business not knowing about, and I did not enjoy it, so I'm now an activist for the cause of "people don't need to know who I am". I should have written more clearly above.