alembic_fumes (u/alembic_fumes)

alembic_fumes commented on OpenAI to begin testing ads on ChatGPT in the U.S. cnbc.com/2026/01/16/open-... · Posted by u/koolba

simianwords · a month ago

> Advertising and marketing kills humanity

No it doesn't. Please stope the hyperbole. Its literally just advertisements and people have the agency to choose to buy products.

alembic_fumes · a month ago

I invite you to ponder the question: would a worldwide ban of all advertising have a greater or smaller impact on environment-destroying activity than banning of all air travel?

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

alembic_fumes commented on Stop Forwarding Errors, Start Designing Them fast.github.io/blog/stop-... · Posted by u/andylokandy

bheadmaster · a month ago

Many Rust programmers despise Go's "if err != nil" pattern, but that pattern actually forces you to think about errors and "design" them to give meaningful messages, either by wrapping them (if the underlying error is expected to provide userful information), or by creating a one from scratch.

It may be easier to just add the "?" operator everywhere (and we are lazy and will mostly do what is easier), but it often leads to problem explained in the article.

alembic_fumes · a month ago

Hard disagree. Most of the Go code that I've ever worked with has been littered with one or another variant of the following:

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

That error construct exclusively works for the poor human who has to debug the system, looking at its logs. No call stacks and, crucially, no automatic handling.

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.

alembic_fumes commented on Maybe comments should explain 'what' (2017) hillelwayne.com/post/what... · Posted by u/zahrevsky

jbreckmckye · a month ago

There's probably a better example. The point is sometimes the What needs explanation, and finding a better What isn't practical.

I have slightly unorthodox opinions about short variables. I used to hate them. Then I posted a question on one of the PL design forums - it might have been Reddit r/programminglanguages - why is there are history of single letter names for type variables? ie T, U, etc for generics. The answer I got back, was, sometimes you want code to focus on structure rather than identities. That stuck with me, because it helped me understand why so much C code (including Linux) code uses similar naming practices. Names can lie, and sometimes expressing the structure is the absolute critical thing.

alembic_fumes · a month ago

Back when I programmed in Haskell, I also had a similar question about the extremely terse variable names that pop up everywhere. I'd wonder, why is this "x" and "xs" instead of "item" and "items" or "businessName" and "businessNames" or whatever. Eventually I found this (paraphrased) answer that made it all click:

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 { ... }

Examples of incorrect naming:

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

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

All this said, I do agree with your original take on the comments. I much prefer having human-readable explanations inline with anyhow non-trivial code. If nothing else, they really make it easier to correctly fix the code if a bug is found much later.

alembic_fumes commented on Parental controls aren't for parents beasthacker.com/til/paren... · Posted by u/beasthacker

alembic_fumes · a month ago

This pervasive desire to block, protect, monitor, and control your children's online activities through nebulous supervision tools seems like a particularly American solution to a particularly American problem. Much like how little Timmy simply can't go out to play without a GPS anklet and an air tag behind each ear, so too can't he go online without a supervised account on a supervised device on a supervised connection.

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?

alembic_fumes commented on We Need to Die willllliam.com/blog/why-w... · Posted by u/ericzawo

alembic_fumes · 2 months ago

This comment section is for some reason filled with truly incredulous takes, with many seemingly all too willingly embracing the inevitability of personal oblivion awaiting us at the end of our lives. I wonder what solace it brings to entertain the paradox of dying as a way to bring life meaning, and where it ranks between whatever the local pastor or suburb's heroin dealer are peddling.

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.

alembic_fumes commented on Cancellations in async Rust sunshowers.io/posts/cance... · Posted by u/todsacerdoti

sunshowers · 4 months ago

You're absolutely right! The problem is that this has introduced many bugs in our experience at Oxide. If you've already fully internalized the idea that futures are passive and can be cancelled at any await point, the talk is just a bunch of details.

alembic_fumes · 4 months ago

I see. Do you suppose that the origin of these bugs is more about the difficulty of reasoning about the execution of deep async stacks, or does it come down to the developers holding an incorrect mental model of the Rust futures in their minds?

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.

alembic_fumes commented on Cancellations in async Rust sunshowers.io/posts/cance... · Posted by u/todsacerdoti

alembic_fumes · 4 months ago

I'm not understanding what the supposed problem with these futures getting cancelled is. Since futures are not tasks, as the post itself acknowledges, does it not logically follow that one should not expect futures to complete if the future is not driven to completion, for one reason or another? What else could even be expected to happen?

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?