The base form isn't too useful by itself, but I expect if one would "seed" the LLM with a prompt about focusing specifically on a particular class of errors, it might be possible to find violations by seeing where the code completely deviates from what an LLM would have written.

Never got around to doing anything with this, but I expect a prototype should take no more than a day with some agent-assisted coding ;) Tell me how it went if you try!

Comments URL: https://news.ycombinator.com/item?id=49498506

Points: 17

# Comments: 0

The foundational idea of prediction markets is that this payment comes from the market itself. If you have a market full of suckers, the experts with real knowledge are incentivized to participate in the market to profit from the gap between what the market forecasts and their own expert forecast. This in turn will drive the market's prediction to be more accurate by incorporating the expert knowledge in directly form of the their "bets". In effect the market says put up or shut up to everyone who thinks they know better the market.

Viewed like this, prediction markets aren't much different from stock markets that also work by the premise of (active) investors claiming to know better than the market. It all follows from the efficient-market hypothesis.

All this said, I find the trend of prediction markets being used to predict what are effectively mostly random outcomes seems a bit strange. But on the other hand, the mere existence of such markets does provide financial incentive to come up with new, better ways to predict these outcomes. This itself would be very useful, at least as long as the subject is more akin to predicting the weather than the movements of a football.

Ultimately, I'm still an optimist when it comes to prediction markets.

Oh no, the terrible dystopia where anyone can benefit from anyone else's good ideas without restrictions! And without any gatekeepers, licensing agreements, copyright, and not even a lawyer in sight!

If this is the dark future that AI use brings for us, I say bring it. Even if it means that somebody gets filthy rich in the process, while making the rest of the humanity better off.

I've been using Nix, both the package manager and the operating system, for years by now. I agree with all of the author's points, it really does deliver, the declarative nature is superb, and there's this constant sense of "hey my stuff is not breaking by itself" when working on it. And it's that declarative, rollback-able, file-based foundation, that makes it the perfect operating system for telling a coding agent to go to town on.

Would I trust Claude to switch my audio stack from Pulseaudio to Pipewire on Ubuntu? Would I trust Codex to install Hyprland on Fedora so I can test out the session? No, in fact I would not trust any agent to do any of those things on any other operating system. But I would trust even goddamn Grok to do that on NixOS, because I can 1) audit the changes before anything is done, and 2) rollback, rollforward, roll-whatever-the-way-I-want-even-on-the-floor-if-I-want-to because of the years of built up confidence proving that IT JUST WORKS.

I concede that this is turning into an unhinged loveletter to Nix, but really, it's the only operating system that lets one operate with this level of confidence. And I know most people don't care about that, since most people don't usually bother to tweak their OSes or switch out window managers, but as someone that does that, I'm never going back to mutable distros. This security is my table-stakes now, and the others aren't willing to pay up.

So for the developers out there on the lookout for their "Year of the Linux Desktop 2026" -distribution, if you're already using AI assistants, give NixOS a try. Maybe start with this in an empty Git repository: "Hey Claude, I wanna try NixOS. Make me a Flake-based starter config using Gnome that I can demo in a virtual machine. If nix isn't yet installed, install it via determinate-systems installer. Include a "vm" target in the flake for building the image, and a small bash script that builds and launches the VM using whatever virtualization is available on my platform."

For a long time I've been wanting to write an essay about this exact topic. Once you start paying attention, it's everywhere: the automatic upselling attempts at self-service kiosks, the automatic pre-filled tipping inputs in the card payment terminals, and some horribly long forms that require extremely pedantic input filled just correctly, that no human would bother on paper.

I've come to think of this as a kind of automated tyranny. Few real humans would have the heart to keep trying to upsell with such persistence when most of their customers reject the sale. And very few humans would dare to ask every single human to tip a pre-filled amount of 10% or even up in such a bold manner. But because "the machine does it", there's no alternative but to accept it, or to boycott the machines.

My condolences to the author for having to witness their children live through such an experience. It sounds like hell.

I would still have a full head of hair if this had been the case since the beginning. Nonetheless I am glad that we got here in the end.

I pity the senior engineer, demoted from a helmsman into a human breakwater, tasked to stand steady against an ever-swelling sea of AI slop.

I would argue for "greater", and from that it rather naturally follows that advertisement and marketing indeed kills humanity.

  value, err := doFallibleOperation()
  if err != nil {
    return nil, fmt.Errorf("fallible operation failed - %w", err)
  }

At least with Rust's enums it is possible to make errors automatically actionable. If one skips that part and opts for anyhow because it's too much work, that's really a user problem.

I like the author's idea of "designing" errors by exposing their actionability in the interface a lot. I'm not overall sold on whether that should be the primary categorization, but at least including a docstring to each enum variant about what can be done about the matter sounds like a nice way to improve most code a little bit.

The specificity or abstractness of a (variable) name relates to the values that it can hold. So when you have a very abstract function whose inputs can be of almost any type, naming those inputs in an overly-specific manner is an exact inverse of the failure of giving an overly generic to name highly constrained parameter.

Examples of correct naming:

  func firstWord(s string) string { ... }

  func bidShortcodePrefix(businessId string) string { ... }

  func firstWord(strWithOptionalSpaces string) string { ... }

  func bidShortcodePrefix(s string) string { ... }

Take an earnest interest in your child's activities, both online and offline. Guide them how to behave in strange, even weird and scary situations with strangers. Be the reliable adult in their life to whom they can tell when they encounter something unpleasant, online or offline. Under the guidance of a parent your children will be safer than behind any amount of protective layers that these so called child-safety apps provide, and they will also know how to help their friends to navigate risk and avoid danger.

Or put another way, if your child must eventually swim in the sea, would rather that they know how to swim, or strap a fifth flotation device onto their back?

I suspect our education system is at fault. Too many children in the modern western society grow up completely isolated from philosophical thinking and the teachings of both ancient as contemporary philosophers. As a consequence they never get exposure to the various deep, tragic, hilarious, and most-of-all diverse ways that we as humans have tried to build meaning into our fleeting lives, triumphant or struggling.

To me, this quote from the article best showcases the status quo:

> And here's what I've been circling around: I think the only reason any of this is true is because of death. Without that horizon, we could defer everything indefinitely.

If you agree with that, I cannot stop you. But maybe I can shake you just a little with a different, more individualistic viewpoint:

Whatever life you have, in whatever circumstances, is the one and only life that you do have. The way it has been is the only way that it can ever be, but the future is whatever you make of it, and it cannot be anything else.

Whatever you experience in life, is all that there is to experience. If you yourself don't climb a mountain, you will never know what climbing that mountain is like. And if you hear a tree fall in a forest but then forget about it, it no longer has made a sound.

Nobody else can do this experiencing for you: much like you didn't directly experience your parents' lives, your children won't directly experience yours. But as long as you yourself are alive, you get to experience your parents and children through the only single way that you can: through yourself.

And so to accept death for yourself is to accept the end of all experience that has ever been. It is to accept death not only yourself, but also for your parents, children, all the climbed mountains and sounds of fallen trees, and all life and the universe itself. For once the one singular entity in the entire universe that has been capable of experiencing is gone, it's as if nothing had ever existed.

So try to stick around and keep experiencing? There really isn't, and hasn't ever been, anything else.

Post-mortem survivalists may disagree.

I am asking because I've noticed that many developers with previous experience from "task-based" languages (specifically the JS/TS world) tend to grasp the basics of Rust async quickly enough, but then run into expectation-misalignment related problems similar to the examples that you used in your post. That in turn has made want to understand whether it is the Rust futures that are themselves difficult or strange, or whether it's a case of the Rust futures appearing simple and familiar, even though they are completely different in very subtle ways. I suppose that it's a combination of both.

The examples presented for "cancel unsafe" futures seem to me like the root of the problem is some sort of misalignment of expectations to the reality:

Example 1: one future cancelled on error in the other

let res = tokio::try_join!( do_stuff_async(), more_async_work(), );

Example 2: data not written out on cancellation

let buffer: &[u8] = /* ... */; writer.write_all(buffer)?;

Both of these cases are claimed to not be cancel-safe, because the work gets interrupted and so not driven to completion. But again, what else is supposed to happen? If you want the work to finish regardless of the async context being cancelled, then don't put it in the same async context but spawn a task instead.

I feel like I must be missing something obvious that keeps me from understanding the author's issue here. I thought work getting dropped on cancellation is exactly how futures are supposed to work. What's the nuance that I'm missing?