MurphyA/hacker-news huggingface dataset:
by averageRoyalty | 2025-06-03 22:47:45+00:00
I feel silly asking, but is this reality or hyperbole?:

> An agent can occupy itself for hours putzing with your tests in a VM and come back later with a PR.

> Kids today don’t just use agents; they use asynchronous agents. They wake up, free-associate 13 different things for their LLMs to work on, make coffee, fill out a TPS report, drive to the Mars Cheese Castle, and then check their notifications. They’ve got 13 PRs to review. Three get tossed and re-prompted. Five of them get the same feedback a junior dev gets. And five get merged.

I'm working better and harder with Roocode in Code mode (and somtimes Architect). I've only been doing it for a few weeks, and it reads to me like I'm already using an 'old approach'.
by munificent | 2025-06-03 22:49:02+00:00
I think Go should have shipped with generics from day one as well.

But you breezily claiming they made the same blunder as Java omits the fact that they didn't make the same blunder as Rust and Swift and end up with nightmarish compile times because of their type system.

Almost every language feature has difficult trade-offs. They considered iteration time a priority one feature and designed the language as such. It's very easy for someone looking at a language on paper to undervalue that feature but when you sit down and talk to users or watch them work, you realize that a fast feedback loop makes them more productive than almost any brilliant type system feature you can imagine.
by const_cast | 2025-06-03 22:51:17+00:00
I think these conversations are inherently tainted by our culture of widespread acceptance and subsidizing of motor vehicles. Cars are held to a much lower standard of behavior in just about every regard, and they're frequently the number 1 most prioritized from of transportation when we build, well, anything.

It's easy to say that cars obey laws but really they don't, that's part of the reason why cars are orders of magnitude more likely to kill you. That's why, despite cars being the golden child of transportation infrastructure, they're still the most dangerous. Because people don't obey laws. They speed, they follow too close, they roll through stop signs, they stop on crosswalks, they turn right as pedestrians are crossing, and on and on. And, when they do disobey laws, it's much more difficult for them to abort.
by acdha | 2025-06-03 22:51:27+00:00
I’d certainly plan for that if my job was physical security. It’s cheap by military standards and it’s not like we don’t have precedent with things like Russian deep-cover operatives. The commodification of the tech could make an adversary more confident in their ability to deny it if found, too, if everyone is using parts from China and open source software.

I think the key deterrent is that the U.S. has production capacity for the important systems and overwhelming capacity to strike back, so a rational foreign state isn’t going to think there’s a way they win by trying it. Terrorist groups might be a different story, so I’m really glad this wasn’t an option during Bush’s big adventure in Iraq and Afghanistan because however bad drone strikes are for military defense, they’re even worse for civilians.
by kelnos | 2025-06-03 22:51:56+00:00
~25 years ago I injured my right (dominant) hand and wasn't able to type with it for about 2.5 months. I figured the time was short enough that I would just use a regular keyboard, one handed, and live with the slowdown.

It was annoying, certainly, and while I did get faster typing only with my left hand, I of course never got close to full speed. But it was fine, I survived, and I don't think it would have been worth spending the money, as well as the time to learn a new keyboard setup.

Remember that a one-handed keyboard (or some other arrangement) isn't going to bring you back up to full speed immediately. It's probably going to take a few weeks to learn, and you might not even get back up to full speed at all.
by michaelt | 2025-06-03 22:52:10+00:00
> FWIW I tried the first couple of examples in ChatGPT 4o and couldn't replicate this.

I can replicate the flag examples from Figure 15 in the paper, if not the Adidas one from Figure 9: https://chatgpt.com/share/683f7c3a-b318-8011-9759-c495db2556... it even confirms its wrong answer when asked to check again.
by nine_k | 2025-06-03 22:52:59+00:00
IDK, Python was fine grabbing list comprehensions from Haskell, yield and coroutines from, say, Modula-2, the walrus operator from, say, C, large swaths from Smalltalk, etc. It does not matter if the languages are related; what matters is whether you can make a feature / approach fit the rest of the language.
by BenjiWiebe | 2025-06-03 22:52:59+00:00
Are you sure it wasn't Mercurochrome you're thinking of? It's a mercury compound that was very commonly used to disinfect cuts and scrapes.

It was prepared from mercuric acetate and sodium dibromofluorescein.

Goulard's extract, containing lead subacetate, was used on cuts too, but from what I can tell it wasn't nearly as widespread/famous as Mercurochrome.
by Animats | 2025-06-03 22:53:16+00:00
Right. This is a UNIX/Linux book. It's not how IBM mainframe OSs work, or how QNX works, or how L4 works, or even how the Windows kernel works.

There's nothing wrong with that, but they should say so up front.

They wrote "From the user’s perspective, disk reads are usually considered non-blocking because they typically complete quickly." Although if all storage is on solid state disk, you might only lose 40us or so per read.
by madcaptenor | 2025-06-03 22:53:34+00:00
As a native Philadelphian, I immediately see why you need a good resolution here - at 0.1 degrees resolution you very well could have assigned my birthplace to New Jersey. If I'm not mistaken New York and Philadelphia are the largest cities where you might have a problem. Chicago's on a state line but the Illinois-Indiana border is straight.
by tialaramex | 2025-06-03 22:54:11+00:00
Sure, maybe you can get money to have some businesses try out rewriting their line-of-business software in the same language versus in a different language and get some results.

My expectation is that if you put the work in you can get actual hard numbers, which will promptly be ignored by every future person asking the same "question" with the same implied answer.

If the "just rewrite it and it'll be better" people were as right as they often seem to believe they are, a big mystery is JWZ's "Cascade of Attention-Deficit Teenagers" phenomenon. In this scenario the same software is rewritten, over, and over, and over, yet it doesn't get faster and doesn't even fix many serious bugs.
by cogman10 | 2025-06-03 22:54:43+00:00
Ok, I'm pretty skeptical that they actually did optimize what they could. In fact, reading between the lines it sounds like they barely tried at all.

For example, they mention G1GC as being better than what was originally there but not good enough. Yet the problems they mention, prolonged GC pauses, indicates that G1GC was not the right collector for them. Instead, they should have been using ZGC.

The call out of G1GC as being "new" is also pretty odd as it was added to the JVM in Java 9, released in 2016. Meaning, they are talking about a 9 year old collector as if it were brand new. Did they JUST update to java 11?

And if they are complaining about startup time, then why no mention of AppCDS usage? Or more extreme, CRaC? What about doing an AOT compile with Graal?

The only mention they have is the garbage collector, which is simply just one aspect of the JVM.

And, not for nothing, the JVM has made pretty humongous strides in startup time and GC performance throughout the versions. Theres pretty large performance wins going from 11->17 and 17->21.

I'm sorry, but this really reads as Apple marketing looking for a reason to tout swift as being super great.
by skywhopper | 2025-06-03 22:54:50+00:00
The thing is, it’s not actually a major problem. It’s the thing that gets the most complaints for sure, and rubs folks from other languages the wrong way often. But it’s an intentional design that is aware of its tradeoffs. As a 10 year Go veteran, I strongly prefer Go’s approach to most other languages. Implicit control flow is a nightmare that is best avoided, imo.

It’s okay for Go to be different than other languages. For folks who can’t stand it, there are lots of other options. As it is, Go is massively successful and most active Go programmers don’t mind the error handling situation. The complaints are mostly from folks who didn’t choose it themselves or don’t even actually use it.

The fact that this is the biggest complaint about Go proves to me the language is pretty darn incredible.
by danShumway | 2025-06-03 22:55:07+00:00
So as an example of what this could look like that would be convincing to me. I started out pretty firmly believing that Rust was a fad.

Then Mozilla and Google did things with it that I did not think were possible for them to do. Not "they wrote a bunch of code with it", stuff like "they eliminated an entire class of bugs from a section of their codebase."

Then I watched a bunch of essentially hobby developers write kernel drivers for brand new architecture, and watched them turn brand new Macbooks into one of the best-in-class ways to run Linux. I do not believe they could have done that with their resources at that speed, using C or C++.

And at that point, you kind of begrudgingly say, "okay, I don't know if I like this, but fine, heck you, whatever. I guess it might genuinely redefine some parts of software development, you win."

So this is not impossible. You can convince devs like me that your tools are real and they work.

And frankly, there are a billion problems in modern computing that are high impact - stuff like Gnome accessibility, competitive browser engines, FOSS UX, collaboration tools. Entire demographics who have serious problems that could be solved by software if there was enough expertise and time and there were resources to solve them. Often, the issue at play is that there is no intersection between people who are very well acquainted with those communities and understand their needs, and people who have experience writing software.

In theory, LLMs help solve this. In theory. If you're a good programmer, and suddenly you have a tool that makes you 4x as productive as a developer: you could have a very serious impact on a lot of communities right now. I have not seen it happen. Not in the enterprise world, but also not in the FOSS world, not in communities with lower technical resources, not in the public sector. And again, I can be convinced by this, I have dismissed tools that I later switched opinions on because I saw the impact and I couldn't ignore the impact: Rust, NodeJS, Flatpak, etc, etc.

The problem is people have been telling me that Coding Assistants (and now Coding Agents) are one of those tools for multiple years now, and I'm still waiting to see the impact. I'm not waiting to see how many companies pick them up, I'm not waiting to see the job market. I'm waiting to see if this means that real stuff starts getting written at a higher quality significantly faster, and I don't see it.

I see a lot of individual devs showing me hobby projects, and a lot of AI startups, and... frankly, not much else.
by recursive | 2025-06-03 22:55:32+00:00
I'm not sure there's a clear difference.

When using a wacom tablet, using the pencil tool in photoshop is very similar to using a pencil. You're "instructing" the pencil tool to move by moving the pencil controller with respect to the tablet.

I know AI slop art when I see it, and I have no interest it making or "consuming" it. But I don't think I could construct a robust definition that would stand up to adversarial scrutiny.
by munificent | 2025-06-03 22:55:41+00:00
I think the two big things for Go are:

1. Minimalism.

Go has always had an ethos of extreme minimalism and have deliberately cultivated an ecosystem and userbase that also places a premium on that. Whereas, say, the Perl ecosystem would be delighted to have the language add one or seven knew ways of solving the same problem, the Go userbase doesn't want that. They want one way to do things and highly value consistency, idiomatic code, and not having to make unnecessary implementation choices when programming.

In every programming language, there is a cost to adding features, but that cost is relatively higher in Go.

2. Concurrency.

Concurrency, channels, and goroutines are central to the design of the language. While I'm sure you can combine exception handling with CSP-based concurrency, I wouldn't guarantee that the resulting language is easy to use correctly. What happens when an uncaught exception unwinds the entire stack of a goroutine? How does that affect other goroutines that it spawned or that spawned it? What does it do to goroutines that are waiting on channels that expect to hear from it?

There may be a good design there, but it may also be that it's just really really hard to reason about programs that heavily use CSP-style concurrency and exceptions for error handling.

The Go designers cared more about concurrency than error handling, so they chose a simpler error handling model that doesn't interfere with goroutines as much. (I understand that panics complicate this story. I'm not a Go expert. This is just what I've inferred from the outside.)
by tzs | 2025-06-03 22:55:56+00:00
Probably. Airliners are pressurized to around 0.8 atm when at cruising altitude. The atmospheric pressure around 0.26 atm, so there is a pressure difference of around 0.54 atm. That will cause a considerable outward force on the cabin which would result in a lot of tension.

If you didn't pressurize the cabin than the cabin would be at around 0.26 atm, which is the same as the outside air, and so there would not be that large outward force, and so much less tension.

But the plane should be fine with that, because that's also the situation in the plane at low altitude.
by potatolicious | 2025-06-03 22:56:15+00:00
You can, and in situations where the computation is unavoidably long that's what you'd do. But if you can do a bit of work to guarantee the computation is fast then it removes a potential failure mode from the system - a particularly nasty one at that.

If you forget to dump the key (or if the deletion is not clean) then you've got an absolute whopper of a privacy breach.

Also worth noting that you can't dump the key until the computation is complete, so you'd need to persist the key in some way which opens up another failure surface. Again, if it can't be avoided that's one thing, but if it can you'd rather not have the key persist at all.
by tuhlatte | 2025-06-03 22:56:25+00:00
Now I'm confused -- you're claiming you meant "good enough code" when your previous definition was such that even mathematical proofs could be "terrible"? That doesn't make sense to me. In software engineering, "good enough" has reasonably clear criteria: passes tests, performs adequately, follows conventions, etc. While these are imperfect proxies, they're sufficient for most real-world applications, and crucially -- measurable. And my claim is that they will be more than adequate to get LLMs to produce good code.

And again, diffusion models aren't relevant here. The original comment was about LLMs producing buggy code -- not RL's general limitations in other domains. Diffusion models' tensors aren't written by hand.
by rwiggins | 2025-06-03 22:57:06+00:00
> how clear and useful it is. Perhaps, but do you really need all that?

Do I need clear and useful things? Maybe not. Would I like to have them anyway? Yes.

Years ago, I configured a Java project's logging framework to automatically exclude all the "uninteresting" frames in stack traces. It was beautiful. Every stack trace showed just the path taken through our application. And we could see the stack of "caused-by" exceptions, and common frames (across exceptions) were automatically cut out, too.

Granted, I'm pretty sure logback's complexity is anathema to Go. But my goodness, it had some nice features...

And then you just throw the stack trace in IntelliJ's "analyze stacktrace" box and you get clickable links to each line in every relevant file... I can dream.

> the wrapping is very greppable when done well

Yeah, that's my other problem with it. _When done well._ Every time I write an `if err != nil {}` block, I need to decide whether to return the error as is (`return err`) or decorate it with further context (`return fmt.Errorf("stuff broke: %w", err)`). (Or use `%v` if I don't want to wrap. Yet another little nuance I find myself needing to explain to junior devs over and over. And don't get me started about putting that in the `fmt` package.)

So anyway, I've seen monstrosities of errors where there were 6+ "statement: statement: statement: statement: statement: final error" that felt like a dark comedy. I've also seen very high-level errors where I dearly wished for some intermediate context, but instead just had "failed to do a thing: EOF".

That all being said, stack traces are really expensive. So, you end up with some "fun" optimizations: https://stackoverflow.com/questions/58696093/when-does-jvm-s...
by const_cast | 2025-06-03 22:57:06+00:00
Ham-fisting statistics to support some model of eugenics and racially perfect societies is an old tale.

We need to be very careful with statistics, because rarely does one or even a dozen cover the whole picture. For example, in the US we can see that black individuals are more likely to commit crime. We could easily run with that and draw some unfavorable conclusions.

But, they're also much more likely to be impoverished, more likely to live in communities with low infrastructure funding, more likely to live in communities with drugs, more likely to have much poorer access to education, and more likely to face barriers to employment.
by jyounker | 2025-06-03 22:57:54+00:00
I wish the author would go back and read the Poppendieks' books on Lean Software Development. The Popppendieks make the following points:

* Software development is design rather than manufacturing.

* Software manufacturing is CI/CD.

* The Toyota Production System (TPS) starts with an idea for a product, and not with building the product.

* Design is a core part of the TPS.

* Building the assembly line is part of TPS.

Sadly the essay argues against Lean Software Development by arguing that it says exactly the opposite.
by armincerf | 2025-06-03 22:58:04+00:00
Artis Works | Full-Time | Backend Engineer | Remote | £75k-95k

Artis Works leads financial innovation by empowering trading firms, brokerages, and institutions with advanced technology. Our flagship product is responsible for taking high frequency tick data from the market, and combining it with user supplied data and custom formulas to produce insights for traders. We surface high quality, low latency historical and live data across 4 continents.

See more about the product at https://artis.works

Position Overview:

We're looking for a motivated backend engineer to join our dynamic team. You'll design, build, and launch essential cloud services from the ground up, significantly impacting our products and success.

Requirements:

Experienced or interested in Rust, or proficient in JVM-based languages (especially Clojure).

Skilled in building real-time data processing and multi-threaded, latency-sensitive systems.

Familiar with stream processing (Kafka, Pulsar, Flink) and distributed systems.

Capable of building secure, scalable, and reliable systems with attention to monitoring and graceful failure.

Experienced with relational, non-relational, and time-series databases.

Familiarity with cloud infrastructure, especially AWS, is a strong advantage.

To apply send an email with a cover letter and/or CV/Resume to careers@artis.works
by csallen | 2025-06-03 22:58:04+00:00
I think what you're leaving is that what you're applying to people also applies to LLMs. There are many people you can trust to do certain things but can't trust to do others. Learning those ropes requires working with those people repeatedly, across a variety of domains. And you can save yourself some time by generalizing people into groups, and picking the highest-level group you can in any situation, e.g. "I can typically trust MIT grads on X", "I can typically trust most Americans on Y", "I can typically trust all humans on Z."

The same is true of LLMs, but you just haven't had a lifetime of repeatedly working with LLMs to be able to internalize what you can and can't trust them with.

Personally, I've learned more than enough about LLMs and their limitations that I wouldn't try to use them to do something like make an exhaustive list of papers on a subject, or a list of all toothpastes without a specific ingredient, etc. At least not in their raw state.

The first thought that comes to mind is that a custom LLM-based research agent equipped with tools for both web search and web crawl would be good for this, or (at minimum) one of the generic Deep Research agents that's been built. Of course the average person isn't going to think this way, but I've built multiple deep research agents myself, and have a much higher understanding of the LLMs' strengths and limitations than the average person.

So I disagree with your opening statement: "That's all well and good for this particular example. But in general, the verification can often be so much work it nullifies the advantage of the LLM in the first place."

I don't think this is a "general problem" of LLMs, at least not for anyone who has a solid understanding of what they're good at. Rather, it's a problem that comes down to understanding the tools well, which is no different than understanding the people we work with well.

P.S. If you want to make a bunch of snide assumptions and insults about my character and me not operating in good faith, be my guest. But in return I ask you to consider whether or not doing so adds anything productive to an otherwise interesting conversation.
by cogman10 | 2025-06-03 22:58:17+00:00
I'm honestly very skeptical that Apple actually did everything they could to make Java startup fast and the GC perform well under load.

G1GC is a fine collector, but if pause time is really important they should have used ZGC.

And if startup is a problem, recent versions of Java have introduced AppCDS which has gotten quite good throughout the releases.

And if that wasn't good enough, Graal has for a long time offered AOT compilation which gives you both fast startup and lower memory utilization.

None of these things are particularly hard to add into a build pipeline or deployment, they simply require Apple to use the latest version of Java.
by dwaltrip | 2025-06-03 22:58:27+00:00
Object: pizza pie

_ _|=|__________ / \ / \ /__________________\ | ________ ___ | | | | | || | | | | || | | | | || | | | | || | | | | || | | | | || | |______| |___|| |_________________| ( ) ( ) ( ) ( ) ( ) ( )

A flying house?? Very curious!
by const_cast | 2025-06-03 22:59:04+00:00
Which seems kind of okay, except when you consider that we pay significantly more per-capita for healthcare as opposed to Canada. Yes, that includes if you take into account taxes, and it's not even close.

Sure, we're not the absolute worst, but we are the most expensive. And, for that, we get close to the worst results. Clearly, our healthcare system is broken in a variety of complex ways.
by dcow | 2025-06-03 22:59:07+00:00
Making specific categories of work obsolete is not evil by any existing moral code I know. On top of that, history shows that humans are no less employed over the generations as we’ve automated more things. You entire comment is rooted in fear, uncertainty, and doubt. I have the opposite mindset. I love the fact that we have trained models on large corpuses of human culture. It’s beautiful and amazing. Nobody has the right to dictate how the culture they generate shall be consumed, not me, not you, and not Warhol, not Doctorow, not Lessig. Human created art always has been and will continue to be valuable. The fact that copyright is a really poor way to monetize art is not an argument that AI is evil. I support all my favorite creators on Patreon, not by buying copies of their work.