MurphyA/hacker-news huggingface dataset:
by photonthug | 2025-06-04 05:54:52+00:00
Re: the YouTube thing, that’s an interesting point of comparison too. I can well imagine a younger version of myself looking at all “content production” stuff as quite silly and ephemeral, and of course much of it is.

The irony though is that lots of things more or less in this category still have a longer shelf life than software (or effort you put into technology related stuff in general). A 5 minute journal entry about that day still may serve some purpose even years later, but 5 hours/weeks/years spent on an obsolete platform or now irrelevant problem? Probably not. Even setting aside companies and professional work, bitrot gets really frustrating eventually after you realize that practically everything requires so much care and feeding. I don’t customize things like phones, browsers, or IDEs anymore because I fully expect most of the effort is pointless treadmill where most problems actively resist even semipermanent solutions.

Awareness of this kind of stuff helps some, which is why you see enlightened devs being pretty ruthless about pruning dependencies. Some tech ecosystems are obviously better than others too, but once you see the treadmill you never really unsee it
by MangoToupe | 2025-06-04 05:57:39+00:00
Well now I know about cmd-k for slack; that app has THE worst discoverability of any app I've used on the desktop.

I'm not near a keyboard so I can't check my muscle-memory, but isn't cmd-k already bound to clear buffer? I would have gone with cmd-p myself, which matches the same functionality for vscode.

Regardless, tying it to a specific key binding strikes me as a little odd.

Criticism aside, this looks insanely cool and I'll install it first thing when i get to work.
by monero-xmr | 2025-06-04 05:58:00+00:00
I have many relatives that died in war. Specifically WWI, WW2, and Vietnam. The direct stories I’ve been told are insane - my grandfather ran communication wires on the German front line and he experienced great trauma.

Then I read books about these wars, and other wars throughout ancient time, and they casually mention so many killed and raped. People struggling to survive. The Japanese called Guadalcanal the “Island of Death” because so many starved and the cannibalism was rampant.

I’m not suggesting we ignore our problems today or minimize them based on what was common even 50 years ago. But it is very helpful to appreciate what we have now, the luxuries, the safety, the technologies, when our ancestors lived in such abject pain and difficulty.
by jchw | 2025-06-04 05:59:34+00:00
I strongly do not like try/catch. Just to list the limitations of exceptions that come to mind,

- try/catch exceptions obscure what things can throw errors. Just looking at a function body, you can't see what parts of the functions could throw errors.

- Relatedly, try/catch exceptions can unwind multiple stack frames at once, sometimes creating tricky, obscure control flow. Stack unwinding can be useful, especially if you really do want to traverse an arbitrary number of stack frames (e.g. to pass an error up in a parser or interpreter, or for error cases you really don't want to think about handling as part of the normal code flow) but it's tricky enough that it's undesirable for ordinary error handling.

- I think most errors, like I/O errors, are fairly normal occurrences, i.e. all code should be written with handling I/O errors in mind; this is not a good use case for this type of error handling mechanism—you might want to pass the error up the stack, but it's useful to be confronted with that decision each time! With exceptions, it might be hard to even know whether a given function call might throw an I/O error. Function calls that are fallible are not distinguishable from function calls that are infallible.

- This is also a downside of Go's current error handling; with try/catch exceptions you can't usually tell what exceptions a function could throw. (Java has checked exceptions, but everyone hates them. The same problem doesn't happen for enum error types in Rust Result, people generally like this.)

(...But that's certainly not all.)

Speaking just in terms of language design, I feel that Rust Result, C++ std::expected, etc. are all going in the right direction. Even Go just having errors be regular values is still better in my opinion.

(Still, traditional exceptions have been proposed too, of course, but it wasn't a mistake to not have exceptions in Go, it was intentional.)
by AsthmaBoy | 2025-06-04 05:59:42+00:00
Back in the day, around 1998/1999, Oracle had tools to develop Web-applications served directly from the database.

To produce HTML one would use a variety of PL/SQL functions, one function for each HTML tag that was available at the time.

The result was that each time I had to correct a spelling error, or change a portion of the page, I had find in the code where the change was to be applied, change the code, recompile the package, and then restart the service to have the changes come into effect.

Combine it with the fact that the code written was always much more verbose that writing straigth HTML, it got really old, really fast.

In the end, I created a micro-CMS where I put the HTML code as snippets in the database that I then combined in PL/SQL to form a page that could be served to a browser.

Changes appeared on the fly as I updated the HTML snippets, and the service had no downtime due to restarts.

Not long after, we moved to using Zope to develop more advaced solutions, but thats another story.

Now, this was a long time and 2 jobs ago :), but I am curious as to why in 2025, one would prefer to go to return these types of solutions.
by JSR_FDED | 2025-06-04 06:02:04+00:00
Very well put. No need to apologize for tech as a whole, nor is there a need for boosterism.

I can relate to the OP’s disillusionment coming from the halcyon days where “computers” were simply awesome.

Software development is quite unique in that a single person can have a huge impact. If your career doesn’t let you do that, you can do it as side projects or open source. How many other professions let you do that with such low barriers to entry?
by comte7092 | 2025-06-04 06:02:49+00:00
> Transit systems would rather run empty buses

Most transit systems carry dozens of passengers per bus per hour. Fixed route services are more efficient than uber. I’m just having a conversation with your own personal biases at this point.

The major differences between uber and transit are technology yes, but also in the fact that it is a public service that is here to meet the needs of everyone. Uber doesn’t have to comply in the same manner with the civil rights act and the ADA, and it doesn’t have a unionized workforce, which in sum is as much if not more of an impact on the services provided than the technology aspects.
by urban_winter | 2025-06-04 06:07:16+00:00
Fantastic app. My wife and I are gradually becoming able to recognise more and more birds by their call. This is great because the human ear is better than the app at rejecting environmental noise - so we can spot birds by their call even close to a noisy road when the app cannot.

The app, at least on my Pixel 6, struggles with very high frequency calls - e.g. long-tailed tits.

My best spot yet? A nightingale in Wimbledon.
by kfreds | 2025-06-04 06:11:37+00:00
Thank you! I realize now that I was thinking about a different aspect of systems research, but failed to say so.

Barrelfish (multikernel) and your username made me think of manycore systems and the scheduling challenges we will surely face as systems become more heterogeneous. I'm in a period of trying to learn more about that. Any and all recommendations are much appreciated.
by Someone | 2025-06-04 06:11:38+00:00
You tune for what you have/can get. Machines with less memory tend to have slower CPUs. That may make it impossible to tune for (close to) 100% CPU and memory usage.

And yes, Apple is huge and rich, so they can get fast machines with less memory, but they likely have other tasks with different requirements they want to run on the same hardware.
by chipx86 | 2025-06-04 06:12:41+00:00
I should also mention, we didn't want to invent a brand-new diff format that required all-new tooling (a replacement for GNU patch, for instance). We want this to be able to work with existing tools that understand Unified Diffs and respect the garbage areas (as most do).

There are a lot of alternative approaches to how one might generate a diff (see VCDIFF for binary files), and much that's worth thinking about for generating diff-like formats that are not line-based. But this is not meant to be those. It is meant to be able to incorporate those as time goes on (as it does with VCDIFF today).
by carlmr | 2025-06-04 06:13:06+00:00
I thought you were pulling numbers out of your magic hat.

It seems true. Sorry for doubting you.

https://www.usatoday.com/story/news/health/2024/10/14/weight...

I guess the 2400 for middle aged people is not that far off if in the 60s the average was right around there and people were healthier.
by ryanwhitney | 2025-06-04 06:15:36+00:00
Glad he linked articles on Facebook's culpability in the genocide of the Rohingya people as well. That should be an absolute, disqualifying reason when considering taking their money.

Very strange to see the level of criticism here aimed at someone choosing to explore other paths. You're not a shortsighted fool for trying to do something else. Especially something that's directly, meaningfully helpful to the people around you.
by apelapan | 2025-06-04 06:16:51+00:00
Expensive cars usually have more power than cheap cars. You can enter a highway, safely overtake someone or climb a steep incline in a larger selection of gears. Also, fancy cars tend to have better automatic gearboxes that behave well in more situations, compounding the advantage.

Cheap fossil cars with shitty automatics can be quite stressful to drive. With a manual clutch and transmission you are in control, know how the car will behave and can relax. It might still be slow, but you know exactly how slow in every situation.
by salviati | 2025-06-04 06:17:18+00:00
> We realize test driven development doesn't work, right?

What do you mean with this? I'm a software engineer, and I use TDD quite often. Very often I write tests after coding features. But I see a huge value coming from tests.

Do you mean that they can't guarantee bug free code? I believe everyone knows that. Like washing your hands: it won't work, in the sense you will still get sick. But less. So I'd say it does work.
by MangoToupe | 2025-06-04 06:17:35+00:00
This entire conversation seems silly without a time frame. Over a long enough time with continually interacting orbits, of course mass will coalesce. I don't think "merge" means "one time interaction that fully disperses the mass", anyway.

If they merge in 7 billion years, you think over the eg next 7 billion there won't be kinetic collisions? I'm skeptical.
by chipx86 | 2025-06-04 06:18:07+00:00
Exactly that. They all do things so differently that you end up creating and maintaining a separate parser for every SCM's diff format, and sometimes doing a lot of normalization of content or modification to include information the format lacks that's needed to apply the patches. And those are just for the ones that actually have a diff format -- many don't.

We needed something for ourselves at the very least. Much of DiffX came from thinking about these pain points and from talking to other SCM vendors whose engineers have also given some thought to these problems.
by transpute | 2025-06-04 06:18:18+00:00
Jim Keller's Tenstorrent ($1B funding to date) is shipping $1K PCIe manycore accelerators, with open-but-immature software, https://www.theregister.com/2024/08/27/tenstorrent_ai_blackh...

> compute.. is handled by 140 of Tenstorrent's Tensix cores, each of which is composed of five "Baby RISC-V" cores, a pair of routers, a compute complex, and some L1 cache.. Tensix cores account for 700 of the 752 so-called baby RISC-V cores on board.. TT-Metalium low-level programming model.. kernels themselves are plain C++ with APIs.. Tenstorrent aims to support running any AI model on its accelerators using commonly used runtimes like PyTorch, ONNX, JAX, TensorFlow, and vLLM.

Legion from the Stanford research team that lead to CUDA, https://legion.stanford.edu/ & https://elliottslaughter.com/2024/02/legion-paper-history

> A novel mapping interface provides explicit programmer controlled placement of data in the memory hierarchy and assignment of tasks to processors in a way that is orthogonal to correctness, thereby enabling easy porting and tuning of Legion applications to new architectures.. Legion is developed as an open source project, with major contributions from LANL, NVIDIA Research, SLAC, and Stanford.
by tgma | 2025-06-04 06:19:42+00:00
Your comment is definitely true. However, if you study GC performance academic papers over the past three for four decades, they pretty much conclude GC overhead, amortized, can be on par with manual alloc/free[1], but usually the unwritten assumption is they have unbounded memory for that to be true. If you study how much memory in practice you need not to suffer a performance loss on an amortized basis, you'd arrive at 2-3x, so I'd claim it is fair to assume Java needs 2-3x as much memory as Swift/C++/Rust to run comfortably.

You can actually witness this to some degree on Android vs iPhone. iPhone comfortably runs with 4GB RAM and Android would be slow as dog.

[1]: I don't dispute the results, but I also like to note that as a researcher in Computer Science in that domain, you were probably looking to prove how great GC is, not the opposite.
by chipx86 | 2025-06-04 06:21:08+00:00
It is. However, first the tools need to be able to grab the necessary information from the diff to, say, locate that file or its metadata in a repository.

Git's diff format contains enough information to do this, but many don't. When this happens, tools like ours (a code review platform) is forced to modify the diff format or otherwise attach information to do these sorts of operations.

We've had to do this enough times, and work around enough inconsistencies and breakages in various SCM-specific diff format variants that we decided to address the problem head-on, pulling our experiences and those of some of the SCM vendors we work with to draft a solution to the problem.
by amonks | 2025-06-04 06:21:23+00:00
I'm not Simon, but I think reviewing code is both faster than writing code and more difficult than writing code.

Lots of difficult things don't take very much time: shooting a bullseye, lifting something heavy, winning a round of geoguessr, playing the guitar solo from Peg. We don't call these things difficult because they take a lot of time in the moment, but because they take a lot of time to master.

I think reading code is like that too. When I think about the best code readers/reviewers I've worked with, they are (1) also among the best and fastest code writers I know, and (2) still much faster at reviewing code than they are at writing it.
by kataklasm | 2025-06-04 06:22:00+00:00
In a similar vein, I really liked "Robot" by Adam Wiśniewski-Snerg, first published in 1973. It doesn't really mention AI itself, but it is about the relationship between humans and artificial life/intelligence. The central theme is the question of knowing if you're "real" in an artificial world. Not the easiest read and can be quite dark at times, but one of my favorite works of classical science fiction. Very underrated!
by devjab | 2025-06-04 06:25:53+00:00
I understand why you'd feel disillusioned if you went into the surveillance capitalism part of big tech in the USA. It's probably similar to what a lot of people will feel about the AI industry when it does to the office floor what robotic automation did the factory floor a few decades ago. I'm not sure I'm quite as optimistic about tech as you are, but I completely agree with your point on how tech is more than just silicon valley.

There is the medical tech that you mention, but there is also green energy tech, farming tech and so on. All which are areas that are improving the lives on the planet for a lot of people. Of course many of these industries are kind of hard to break into if you're a "software engineer" and not really used to working with machinery, but it's not like it's impossible and it's certainly an area where your stuff will stick around. Some of the earliest software I build for solar plant data loggers will probably live a lot longer than me.

I do think people should follow what they want to do though. I completely get wanting to try something different and I don't think the authors reasons are any worse than people who burn out because of all the pseudo-management-bullshit in our industry. You don't really see anyone questioning when someone becomes a woodworker because they're fed up with associate agile scrum it business partner managers and little boxes on a board.
by abotsis | 2025-06-04 06:25:55+00:00
Yea, it’s too easy. Maybe if it were a “guess the number” but in binary? Hints are just “too high” or “too low”?

…though now that I’m playing it in my head that’s too easy too. (Start at MSB and shift right if too high and add bits if too low)…

Maybe if you reduced the number of guesses to 5 that’d add enough chance to make it fun?
by chipx86 | 2025-06-04 06:26:01+00:00
`git format-patch` and `git am` are great! Not all SCMs have something like that (many don't even have a diff format with enough information to reliably look up a file or apply all of its changes).

Having the whole state of a series of commits up-front can help with tools like ours that need that information ideally in one place and need to do analysis across multiple commits.

We also wanted to avoid issues where, due to a bug or network error or whatever, a missing patch in a sequence could result in a broken set of changes to apply. This is obvious when you're patching locally, but less so when you're sending to a tool to process later. Having it up-front reduces the chances of problems and simplifies a lot of edge cases.
by Kiyo-Lynn | 2025-06-04 06:28:31+00:00
I once met a researcher who spent six months verifying the results of a published paper. In the end, all he received was a simple “thanks for pointing that out.” He said quietly, “Some work matters not because it’s seen, but because it keeps others from going wrong.”

I believe that if we’re not even willing to carefully confirm whether our predictions match reality, then no matter how impressive the technology looks, it’s only a fleeting illusion.
by tomhow | 2025-06-04 06:28:35+00:00
You can't comment like this on Hacker News. Please read and observe the guidelines, particularly these ones:

Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.

Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.

Please don't fulminate. Please don't sneer...

Eschew flamebait. Avoid generic tangents. Omit internet tropes.

Please don't use Hacker News for political or ideological battle. It tramples curiosity.

https://news.ycombinator.com/newsguidelines.html
by kfreds | 2025-06-04 06:28:45+00:00
The virtualization of I/O is fascinating, and VirtIO's progress from the Linux kernel to hardware implementations. My only wish is that Linux would support inter-VM shared memory as a VirtIO transport in addition to pci and mmio.

Thanks for the pKVM tip, and the connection between OpenTitan and Barrelfish.

Speaking of security and open-source hardware, shameless plug of stuff I work on:

- dev.tillitis.se (FPGA-based OSHW RoT)

- system-transparency.org (related to CC, TDX, SNP)

- sigsum.org
by microtonal | 2025-06-04 06:29:28+00:00
iOS sends data to metrics.apple.com, metrics.icloud.com, iadsdk.apple.com, etc. a lot. They are much better than Samsung (who send data to Samsung and other parties), but I am not convinced they are much better than Google devices. It's more who you prefer sending your data to.

In the end something like GrapheneOS is the only good choice. Has all the security features of Pixel (which is similar to iPhone) and the tracking of neither.
by titanomachy | 2025-06-04 06:30:34+00:00
I’ve heard sentiments like this from most of the people I know who work helping the disadvantaged populations of our society. These are genuinely altruistic people, but they still get tired. For example, an addictions doctor was venting to me last week about how half of their patients don’t show up for appointments, and can’t even be located by the social workers who are employed to keep track of them.
by motorest | 2025-06-04 06:30:43+00:00
> Bezos is literally a one-in-million entrepreneur.

That's besides the point. The critical aspect is that Amazon was tapping into a market that Wall Street analysis failed to even understand existed, even though it was there staring at them and poking them in the eye.

It's hard to even conceive how, in the middle of the dot-com boom, market analysis systematically failed to even identify there was a market for cloud infrastructure.

It's like during the gold rush failing to realize there's a market for pickaxes.

It's very easy for internet randos to dismiss Amazon's strategy as one-in-a-million bets and something no one would ever conceive. Except this was exactly the opposite. Amazon was sitting on top of a huge compute infrastructure, which they had to build themselves from scratch, and which the company was financing as a purely operational expense. Any business analyst worth it's name would ask "how can we turn this into a revenue stream?" If they looked outside the figurative window, they would see lines of CTOs of dotcom startups imploring everyone for renting any semblance of compute infrastructure to get their startup off the ground. You do not need to be a genius to put two and two together.
by chipx86 | 2025-06-04 06:31:20+00:00
The repository metadata absolutely should own the commit information.

Diff files are there to represent a delta state of the repository, a difference between a range of changes. Those may be one or more commits, or one more changes across individual files (not all SCMs manage state in terms of atomic commits). File changes, file attribute changes, SCM-specific metadata changes, and commit history information.

That delta state should be able to be applied to another tree in order to get the same end result. This is what diff files are ultimately there for.

Git diffs do this today, and they do it well (but they're pretty Git-specific). Many SCMs (and there are a lot of them) don't include a format on that level, or a format at all. Hence DiffX.
by jajko | 2025-06-04 06:31:23+00:00
The tech/fantasy parts are great and were novel back then. But the characters were shallow, story so-so and ended in big meh, and overal it feels like chinese propaganda re freedom and future.

Any non-chinese character is evil for example, only chinese will inherit the right for their future. Western culture moved from such properly bad cliches long time ago for the better.
by campervans | 2025-06-04 06:33:16+00:00
I use .md files to keep Cursor on track, the flow I use is something like...

Define a feature in detail (using trascription) -> Get o3 or Gemini 2.5 pro to break it down into very small testable tasks. -> review this -> then paste into a tasks.md file -> write and architecture.md file or similar for any additional context needed. -> then prompt Cursor to work through tasks.md step by step.

This keeps it on track, with the whole feature defined from the outset.

But eventually... it will try to ignore the dockerfile and setup up locally, create multiple .env files, write code with placeholders, ignore a files it's just created and written...

It's impossible to get it back on track - it gets into a debug loop of making things worse rather than getting back on track.