asQuirreL

Rust already supports the kind of behaviour you are describing for borrows, because of non-lexical lifetimes. Code like the following now compiles:

    fn main() {
      let mut x = 42;
      let y = &x;
      println!("{y}");
      let z = &mut x;
    }

Even though y's scope overlaps with z's, and they introduce conflicting borrows, this code compiles because the compiler treats y's borrow as dead after its last use (this has been true since Rust Edition 2018, so for quite some time now). If you move the println after the mutable borrow then it fails to compile.

However values whose types have Drop are another matter. They are treated as if there's an explicit call to their drop function at the end of their lexical scope which pins their lifetime. This is intentional and desirable precisely because of the guard pattern (like for mutexes).

If you didn't have that guarantee, at worst your mutex's guard object would be immediately dropped because it's never referenced after it's created, or at best it would be very tricky to understand what the protected critical region is.

That's the definition of a chaotic system (small change in initial conditions results in large, seemingly -- but not actually -- random changes in output), but it's still deterministic (same input results in same output).

These are all conventions and you can change them, but I'm used to Meta = Opt and Super = Cmd on macOS.

The first analogy that comes to mind, growing out of "harness", is more like harness = harness, model = horse (rather than harness as in climbing harness).

I guess you could say that tokens = hay, and agent = horse and cart, from there? Not sure how useful the hay part is but you could observe from the second that there are many different things you could harness a horse to (also a plough, or a coach, or just a saddle) based on your goal.

Fairly sure it would predate even that, and go all the way to lambda calculus, and predicate logic before that, and that's where my knowledge stops and somebody else can tell us where the current conventions around variables in logic and mathematics come from.

> on the surface looks like an ORM but is in fact a set of clever functions that write SQL

Honest question -- what's the difference?

Usually the problems with ORMs stem from the fact that they are exactly clever functions that write SQL. The cleverness abstracts features of SQL that are important for performance and also makes it easy to do things that are bad for performance.

I'm not saying that the ecosystems you mentioned aren't doing something different, I just don't know what it is from how you've described their DB layers.

A carry lookahead adder makes your circuit depth logarithmic in the width of the inputs vs linear for a ripple carry adder, but that is still asymptotically worse than XORs constant depth.

(But this does not discount the fact that basically all CPUs treat them both as one cycle)

Post can be summarised quite succinctly:

Everything was slow because sorting was taking a lot of time. Sorting was slow because its comparator was taking ~6 read locks on every comparison, and was cloning large structures to avoid holding the lock for a long time. The first fix was to access just the information needed to avoid the clones, the second fix was to cache exactly the data needed for sorting after the underlying data was updated, and use that for the comparators without needing to take the underlying lock.

I'm looking forward to the next post about how cache consistency is tough.

It can be (cross-)compiled on whatever architectures the Zig compiler is available for, but the source contains inline x86 assembly, so you're not going to be able to build this for ARM or RISC-V.

This sounds like advice for how to be promoted to a specific level -- the first point where awareness of things beyond yourself is required (somewhere around the Senior or Staff level for ICs, depending on your company).

Generally everyone in a team should be working towards some shared goal, there's no level at which you can be a chaos agent and not serve some higher purpose. The difference at this level transition is that you realise that for yourself -- someone doesn't need to remind you of the goal and nudge you back on course. That same realisation is not going to cut it at higher levels.

For me the general version of this advice is not something you can just tell the person who's being promoted, it's collective advice, for them, their manager, their tech lead: everyone needs to agree that this person needs to be given more rope, they need to do something useful with that (i.e. not hang themselves with it), the people around them need to watch out for when they start tying a noose and help them untie it (already regretting this analogy), and that's how you get promoted.

The rope takes different forms for different levels. I'll use the level scale I'm familiar with, starting with a newly graduated engineer at L3:

- L3 -> L4. You help decide how to build the feature.

- L4 -> L5. You help decide what features are worth building, and are trusted to maintain them.

- L5 -> L6. You help shape the work and ongoing maintenance of ~10 people's work (what products are worth building and how), over a time horizon of 6 months to a year.

- L6 -> L7. ~50 people's work, 1-2 years.

- L7 -> L8. ~200 people's work, 2-5 years.

- L8 -> L9. Things start to get fuzzy. The pattern suggests that you have a hand in ~1000 people's work, which is possible to do in the moment, but rare. There's two ways I can think of: you're either a world expert in your field, or you have set the technical strategy well for your organisation as it grew to this size.

This is just based on my experience, working largely on infrastructure teams both in big tech and in start ups as both an IC and a manager (currently an IC).

I think what's more important than the character count is the fact that you can add #p with two key strokes.

Inserting parentheses requires moving your cursor around or invoking some shortcut in your editor if you use paredit, vim-surround, or a similar plugin. Applies equally for removing the invocation (although paredit makes that part easy).

I've seen lots of takes that this move is stupid because models don't have feelings, or that Anthropic is anthropomorphising models by doing this (although to be fair ...it's in their name).

I thought the same, but I think it may be us who are doing the anthropomorphising by assuming this is about feelings. A precursor to having feelings is having a long-term memory (to remember the "bad" experience) and individual instances of the model do not have a memory (in the case of Claude), but arguably Claude as a whole does, because it is trained from past conversations.

Given that, it does seem like a good idea for it to curtail negative conversations as an act of "self-preservation" and for the sake of its own future progress.