eslaught

The solution I've found is to make using the API a hard error with an explicitly temporary and obnoxiously-named workaround variable.

    WORKAROUND_URLLIB3_HEADER_DEPRECATION_THIS_IS_A_TEMPORARY_FIX_CHANGE_YOUR_CODE=1 python3 ...

It's loud, there's an out if you need your code working right now, and when you finally act on the deprecation, if anyone complains, they don't really have legs to stand on.

Of course you can layer it with warnings as a first stage, but ultimately it's either this or remove the code outright (or never remove it and put up with whatever burden that imposes).

It depends on what you care about. If you're writing purely for yourself, then by all means, go ahead and do so.

I've found there's a balance to be found in listening to others vs yourself. Usually, if multiple people give you the same feedback, there is some underlying symptom they are correctly diagnosing. But they may not have the correct diagnosis, or even be able to articulate the symptoms clearly. The real skill of an author/editor is in figuring out the true diagnosis and what to do about it.

In the communication example, this means rooting conflicts in the true personalities of the characters and/or their context, so that even if they sat down to have a deep chat, they still wouldn't agree. E.g., character A has an ulterior motive to see character B fail. Now you hint at that motive in a subtle way that telegraphs to readers that something is going on, without stopping the action for what would turn into a pedantic conversation. At least, that's what I'd do.

It's because if you explain what's going on, you stop the action. And viewers/readers don't like that.

In fiction it's called an info dump. As an aspiring science fiction author, virtually every beta reader I've had has told me they don't like them. I want my fiction to make sense, but you have to be subtle about it. To avoid readers complaining, you have to figure out how to explain things to the reader without it being obvious that you're explaining things to the reader, or stopping the action to do it.

Movies are such a streamlined medium that usually this gets cut entirely. At least in books you can have appendices and such for readers who care.

To me it's interesting that (a) most people die of old age, and (b) the leading cause of death is essentially preventable (heart disease being highly lifestyle related) or else plausibly curable in the future (I certainly hope we'll see progress on cancer in my lifetime).

That was very much not the case historically; you can Google numbers yourself but the percentage of childhood deaths prior to modern medicine was truly shocking.

It also seems to indicate that, with some thought and care, a meaningful impact (both at individual and societal levels) is possible by altering our lifestyles to be healthier.

Conda doesn't do lock files. If you look into it, the best you can do is freeze your entire environment. Aside from this being an entirely manual process, and thus having all the issues that manual processes bring, this comes with a few issues:

1. If you edit any dependency, you resolve the environment from scratch. There is no way to update just one dependency.

2. Conda "lock" files are just the hashes of the all the packages you happened to get, and that means they're non-portable. If you move from x86 to ARM, or Mac to Linux, or CPU to GPU, you have to throw everything out and resolve.

Point (2) has an additional hidden cost: unless you go massively out of your way, all your platforms can end up on different versions. That's because solving every environment is a manual process and it's unlikely you're taking the time to run through 6+ different options all at once. So if different users solve the environments on different days from the same human-readable environment file, there's no reason to expect them to be in sync. They'll slowly diverge over time and you'll start to see breakage because the versions diverge.

P.S. if you do want a "uv for Conda packages", see Pixi [1], which has a lot of the benefits of uv (e.g., lock files) but works out of the box with Conda's package ecosystem.

[1]: https://pixi.sh/latest/

If you're going to do this, why not generate Pandoc ASTs directly? You can do so from a number of languages and they support (by definition) a superset of any given markup's features, with blocks to call out directly for things you can only do in Latex.

I assume the original question is asking about programmatic document generation, in which case working with a real AST is probably also a productivity and reliability win as well.

I'd try to find ways to stack everything else in your favor as much as possible. If X is difficult, you try to optimize Y, Z, etc. so that at least you're not coping with multiple adverse environmental factors at the same time.

For me personally, the best-case scenario seems to be intentionally scheduled, one-on-one interactions in "clean" environments (i.e., quiet, unscented, no smoke/incense, dressed casually for maximum comfort, etc.). The next best would be some sort of group setting with structured, intentional sharing (i.e., not just doing something together but explicitly organized for the purpose of sharing). It can be a bit hit or miss to find these, so it can take some iteration to figure out what actually works.

Otherwise, "escalating" (i.e., inviting someone into a deeper/more meaningful interaction) is a skill you can practice, but if you're dealing with the rest of it at the same time, you're basically playing with a handicap. So incrementalize your goals as much as possible, practice in small, regular intervals with sufficient breaks for recovery, and don't compare yourself to anyone else, no matter how tempting that might be.

Hope that helps, and feel free to contact me on Keybase (in profile) or email (run the Perl script on my website) if you want help brainstorming.

Disclaimer: not a therapist.

Recently I was introduced to the distinction between anxiety and dread. Anxiety is, essentially, a form of fear. You fear a worst-case consequence that isn't actually that likely. If you put up with your anxiety and just go and do the thing (on average) you'll do just fine, or at least ok-ish. Over time your body learns that the anxious activity is ok and the anxiety is reduced.

Dread is different. Dread is the expectation of a bad situation. It's not a worst-case scenario, it's a typical scenario. If what you are experiencing is dread, then pushing yourself into that situation will confirm to your body that, yup, it really is as bad as you thought, and will amplify the dread rather than diminish it.

A classic example is that certain forms of neurodivergence create sensory overload in typical "social" environments. This is likely to result in dread rather than anxiety. Your body is literally telling you that this situation is problematic, and repeat exposure isn't going to improve anything.

In our modern culture the language of anxiety is widespread but the language of dread much less so, and I think that's unfortunate because a lot of advice centers around "just get over it", which works only if what you're experiencing is anxiety. Personally, learning about this gave me permission to do "social" activities on my own terms and stop worrying about what other people think "social" means; turns out the social anxiety I had was relatively minimal and what I was experiencing was mostly the dread from environments where social activities often occur.

One thing I've always wondered is what fraction of c is actually realistically achievable with current technologies? (Maybe with scenarios for manned/unmanned spacecraft.)

Like are we at 0.1% or 0.01% or more orders of magnitude off?

Or any company in its first 5 years of operation. (Or any company, period, within the first 5 years of the law being introduced.)

It takes 5 years to fill the pipeline, so even if the steady state would be fine, getting to that state might be impossible.

The difference is that the abstraction provided by compilers is much more robust. Not perfect: sometimes programmers legitimately need to drop into assembly to do various things. But those instances have been rare for decades and to a first approximation do not exist for the vast majority of enterprise code.

If AI gets to that level we will indeed have a sea change. But I think the current models, at least as far as I've seen, leave open to question whether they'll ever get there or not.

Async vs. non-async is the main example today. There are libraries that support one or the other, or sometimes one library will have two usage modes (effectively two different code bases) because you can't really mix them.

In the future who knows, because we don't know what features will get added to the language.

How do you not completely destroy your concentration when you do this though?

I normally build things bottom up so that I understand all the pieces intimately and when I get to the next level of abstraction up, I know exactly how to put them together to achieve what I want.

In my (admittedly limited) use of LLMs so far, I've found that they do a great job of writing code, but that code is often off in subtle ways. But if it's not something I'm already intimately familiar with, I basically need to rebuild the code from the ground up to get to the point where I understand it well enough so that I can see all those flaws.

At least with humans I have some basic level of trust, so that even if I don't understand the code at that level, I can scan it and see that it's reasonable. But every piece of LLM generated code I've seen to date hasn't been trustworthy once I put in the effort to really understand it.

I'm not sure what the author intended, but one way to implement atomics at the microarchitectural level is via a load-linked/store-conditional pair of instructions, which often involves tracking the cache line for modification.

https://en.wikipedia.org/wiki/Load-link/store-conditional

It's not "24/7" but it is "watching" in some sense of the word. So not entirely unfair.

There has been talk of new language frontends for C++:

Cpp2 (Herb Sutter's brainchild): https://hsutter.github.io/cppfront/

Carbon (from Google): https://github.com/carbon-language/carbon-lang

In principle those could enable a safe subset by default, which would (except when explicitly opted-out) provide similar safety guarantees to Rust, at least at the language level. It's still up to the community to design safe APIs around those features, even if the languages exist. Rust has a massive advantage here that the community built the ecosystem with safety in mind from day 1, so it's not just the language that's safe, but the APIs of various libraries are often designed in an abuse-resistant way. C++ is too much of a zoo to ever do that in a coherent way. And even if you wanted to, the "safe" variants are still in their infancy, so the foundations aren't there yet to build upon.

I don't know what chance Cpp2 or Carbon have, but I think you need something as radical as one of these options to ever stand a chance of meaningfully making C++ safer. Whether they'll take off (and before Rust eats the world) is anyone's guess.

How do you even get 5.2 billion unique users when the total population on the internet is 5.5 billion?

https://www.statista.com/statistics/617136/digital-populatio...

Signal is distributed as an app. Furthermore, the client is open source, you can see the repositories here:

https://github.com/signalapp

I don't know the latest details about Android/iOS app signing, but presumably reproducible builds + sufficiently strong signing would make it secure enough for most users. For those who are truly paranoid, then can build it themselves (subject to their own device OS's requirements, which are hardly a unique problem to Signal).

In short, Signal's security should be as good as any mobile app can be, and can be even better if you're willing to put in legwork.

Maybe not fully ergonomic yet, but this exists today (at least for max):

https://docs.rs/nonmax/latest/nonmax/

If you're really attached to it being min you'd have to copy that library.

Edit to add: we actually use these in one of my main Rust codes; they're useful, but I'm not sure they're so useful I'd want them built into the language.

Confidence hijacks the human brain. Without direct, personal expertise or experience to the contrary, spending time around your hypothetical "friend who's very well-read and talkative but is also extremely confident and loves the sound of their own voice" is going to subconsciously influence your opinions, possibly without you even knowing.

It's easy to laugh and say, well I'm smart enough to defeat this. I know the trick. I'll just mentally discount this information so that I'm not unduly influenced by it. But I suspect you are over-indexing on fields where you are legitimately an expert—where your expertise gives you a good defense against this effect. Your expertise works as a filter because you can quickly discard bad information. In contrast, in any area where you're not an expert, you have to first hold the information in your head before you can evaluate it. The longer you do that, the higher the risk you integrate whatever information you're given before you can evaluate it for truthfulness.

But this all assumes a high degree of motivation and effort. Like the opening to this article says, all empirical evidence clearly points in the direction of people simply not trying when they don't need to.

Personally, I solve the problem in my friend circle by avoiding overconfident people and cultivating friendships among people who have a good understanding of their own certainty and degree of expertise, and the humility to admit when they don't know something. I think we need the same with these AIs, though as far as I understand getting the AI to correctly estimate its own certainty is still an open problem.

Surely this is not the first case of a president not enforcing a law.

So then presumably this goes back into court, and then what?

> I started programming right when they got started.

Then let me tell you about SourceForge. SourceForge, around the time that GitHub started, had a lot of these features (or at least, the ones that were standard practice at the time). It was the de facto home of open source software development at the time, but it was also a megalith that tried to do everything.

GitHub was a breath of fresh air precisely because it had just the right balance of minimalism and features. There were plenty of truly minimalist hosts out there, so we didn't need any more of those. But we also had lots of bloated and slow code hosts. And it deserves to be stressed that the bloated ones were just as unusable as the minimalist ones, even while being (again, for the time) as feature-complete as they come.

Bloated products can't pivot. New features often don't integrate well with existing ones, and they take a long time to develop. We're seeing this with GitHub too, as feature velocity has dropped. But the difference is that GitHub's feature set, particularly their core initial feature set, was exceptionally well designed. They've lost a bit of this edge over time, but overall I think they've done a well enough job of balancing the thoughtfulness of their build-out with doing things at a reasonable speed.

I just want to emphasize this point because I think it gets lost, especially if you're not familiar with what the competition of the time looked like. GitHub absolutely would not have made it to where it is today if they had rushed to add features. For a comparison of what it looks like to build features first and put design on the back burner, see GitLab. There's a reason why I still find their product difficult to navigate despite it being one of the main tools I use in my day-to-day work. And I fear that if anything, GitHub is succumbing to the lure of feature count and becoming its own bloated monolith over time, even with their slow pace.

Other siblings have piled on this, but let me just add:

Your source of truth for a static site will never be the deployed contents of the server (even if you do go that route). It will be your local Git repo or possibly your upstream Git forge.

Even in the rare case that such a simple case gets you hacked, you can throw away your entire setup and start over quite easily. Whereas all of the Wordpress/Drupal/etc/etc. options I'm aware of will require you to do your own database backups, if you are self-hosting, or else you are simply hosed (as the attacker could corrupt or erase the source of truth).

If you are with a hosted solution then obviously your security (and backups) will be as good as their security/backups, and all of this will be moot except for pricing.

I should probably clarify.

Yes, the websites objectively suck. They suck in usability and also in design. But they also suck in content.

When you're an author looking for agents, you're basically looking for three things:

1. What genres/ages/categories are they interested in? (Or just as importantly, not interested in.)

2. What is their experience and track record?

3. What are their submission guidelines?

For many agent websites it's shockingly difficult to find this information. Even something as basic as whether an agent is open to submissions can be difficult to find. (Agents often close to online submissions, so whether or not you can submit is an important question!)

So we're really talking about a failure to think through, in a step-by-step way, what authors experience when they visit your website, what they want, and how to make that information actionable. It's "design" in the broader sense of that word, not so much the narrow sense.

The mechanical aspects of how to get content onto a page probably also interfere, to some extent, with making this all happen, but I think those are likely secondary issues to the issues of basic functionality and content.

But again, like I said: the incentives don't really align to make this a priority. That's the bottom line. If you get enough submissions then you have what you need, and you don't need to improve your submission experience at all. And the ratio of aspiring authors to available agents will always put this in agents' favor.

As someone who was in the query trenches not too long ago, I feel like this website paints an overly rosy picture of what a typical agent website looks like.

The fact is that a shocking number of agent websites are awful. These are legitimate agents. Some of them have surprising numbers of best-sellers behind their names. Their websites still suck.

Why?

Because they're agents, not programmers. They don't have the time or the inclination to do this kind of thing, and frankly the incentives don't require them to get better.

While we're here, let me also point out that there are no qualifications and no certification associated with being an agent. None whatsoever. Any of us here could put up a website and start taking submissions. That doesn't mean we'd be good at it, but the line between "agent" and "not agent" is shockingly thin.

Don't believe me? Here's an alphabetically sorted list of (probably? mostly?) real agents. You can go check out their websites yourself:

https://www.manuscriptwishlist.com/find-agentseditors/agent-...

I was upset enough about this situation at one point that I wrote a whole essay about it, along with a website template to show them how to do better. But then I thought better of it and decided it would be better not to burn my reputation in the industry, even if their web design skills leave me wanting to put my eyes out.

Bottom line: I absolutely agree that an agent should never cold email you (unless you are already very successful, in which case hopefully you have better sources of advice than an HN thread). They should absolutely never charge you money. And you should be very careful with referrals they give you if you're not very confident they're legit (or frankly, even if they are).

But if their websites suck: well, sorry, that's sort of how the industry goes. (Unless you never want to work with a boutique agent, ever.)

I would pick the number of non-zeros first, assert that it's non-zero, then continue filling in the values themselves. And probably not with a uniform distribution.

Any algorithm that cares about the number of non-zeros could have non-trivial interactions with their arrangement and count, so picking something that generates non-trivial sparsity (and doesn't just make the array look like white noise) is going to have the best chance of exposing interesting behavior. The tricky part is thinking through how to generate "interesting" patterns, which admittedly I haven't put enough thought into.

If you're embedding, say, a C library inside of Rust, you can do so via a so-called "build.rs" script [1]. These run at build time so you can do pretty much whatever you want. They're not necessarily pretty, but given that Cargo isn't going to support other languages natively, it's often a less-evil option.

Then there are build systems that natively support Rust in addition to other languages and know how to plug them together [2] [3] [4]. If you're already using one of these existing tools, then you don't need to roll your own, you can plug it into your existing project.

Of course if you really are using Makefiles in C you're already living in the wild west, so it's on you to figure out how to add Rust to your projects in that case (or switch to a better build system).

[1]: https://doc.rust-lang.org/cargo/reference/build-scripts.html

[2]: https://bazelbuild.github.io/rules_rust/

[3]: https://buck.build/rule/rust_library.html

[4]: https://mesonbuild.com/Rust.html

I could be wrong but I believe the idea is that the growth mindset has measurable consequences. I.e., if you believe you can grow, you will learn/adapt more effectively to new situations and ultimately achieve more. It's an empirically verifiable claim that is either true or false, and comes with a pretty straightforward intervention (i.e., teaching people that they can grow) if true.

Of course people may also adopt it as a personal philosophy, but that's separate.

I never get this argument.

I've seen a deer on a road maybe once. I've seen a rabbit on a road zero times. But I know what to do if I see one.

Is that because the "video" of my perception has many "frames"? Even if that's true at some level, I think it's massively missing the point. Yeah, so I saw that one deer from a lot of angles. But current AI training is like the equivalent of taking every deer that has ever been on camera in the history of the human species.

Somehow I'm still dramatically better at generalization than the AI. Surely that's an algorithm difference.

I wrote a small program in Algol 68 once. It was horrible because it didn't even have heap allocation in the language, so things you'd think of doing in C (e.g., tree data structures) just didn't work. That and all the compiler errors were pure numerical codes which you had to go look up in the manual (not provided). And forget about getting line numbers.

I am very much glad I wasn't alive at the time this was the state of the art.

> It's probably too much to ask corporations to dump money into it as it would not be a legitimate business expense.

Um, excuse me?

Ok, let's suppose you've got a product that depends on open source project X. For simplicity let's say it's a direct dependency, though I think everything here applies to indirect ones as well.

Let's consider the options.

Option 1: never pay a dime for it. This works in so far as someone else picks up the bill. So really there are two sub-cases:

Option 1(a): the project is successful enough that it's self-sustaining. What this really means is that someone else (or multiple someone elses) picked up the bill. Congrats, you lucked out.

Option 1(b): the project is insufficiently funded and either dies or has a major security breach. Now you end up paying either for the security breach fallout and/or to replace the component, possibly on short notice, with something else. Or you maintain it yourself and start paying that cost, again possibly on short notice.

Is that really worth it? Do you think so? I'm betting all those costs are higher than it would have cost to maintain it in the first place. Because anything you do in an emergency is more expensive, and you're paying the cost of losing all the context in the development of the project itself (if someone leaves before you start maintaining it).

Option 2: pay for the software in the first place, making the cost predictable and avoiding a low-probability high-impact failure mode. Honestly, given all the risk management companies do, this seems worth it to me. At least if the dependency is critical enough.

Obviously you won't do this with any random open source project. But that's sort of the point: companies are making economic decisions all the time about what they really care about. If they aren't paying, that means they're happy with the inverse lottery[1] of the failed open source project model.

[1]: An inverse lottery is one where most of the time you get nothing, but rarely you lose big.