packetlost

Most times I've seen complaints about it, it boils down to "XML being yucky" and the extension component model being difficult to write clients for, which is true but not really a fault of the protocol, it's more of an inherent tradeoff of supporting opt-in extensions at all

I firmly disagree, they are not a continuum, they are binary properties of what they describe. Code can have concurrency primitives, but parallelism primitives must necessarily come from the environment the code executes in, whether it's multiple code streams on a multicore processor or process parallelism provided by an operating system. Programs that are parallel are necessarily also concurrent (if they must communicate between parallel executions), but the inverse is not necessarily true.

If this distinction wasn't important, Python's infamous GIL would not be an issue.

Frankly the software industry suffers heavily from a lack in standardized terminology. The precise definition of parallelism vs concurrency is one that I think is incredibly important. You are doing your peers a disservice by using them interchangeably, they are not.

Testing is not a replacement for use, but it can help exercise code to the extent that the author can predict how the software will be used. A significant source of test cases come from using code and finding defects. No amount of auditing or proactive testing replace real world use.

The only way to know if software does what is intended is to use it. IMO that's the real value of OSS: software that has been executed many times by many people in many different environments, which overall increases the trust in the correctness of the system(s).

Oh fully agree. I hate reading LLM generated text, just wanted to provide a counterpoint to GP.

While I generally agree, the difference is I can also hand an LLM my pile of code and documents which is... a lot more information dense than basically anything I could write. Sure, a one-off prompt in a chat window isn't very helpful.

> it has no hidden memory allocation or control flow

Rust had like 3 allocating types total. If you aren't working with extremely deeply nested 3rd party types it's trivial to identify when allocations happen. Hell you could throw a lint rule together in like 5 minutes to warn on it if you're really worried. Besides Drop (excluding async) is there even any hidden control flow?

> Im speculating here, but I believe its advantage over Rust for that specific application is that you have tighter control over exactly when memory is allocated and deallocated, and how data is laid out in it.

Rust has almost exactly the same semantics for controlling allocations and deallocations, it just prevents you from screwing it up and not freeing something or using the allocation after freeing it. You still have to pass around your reference in your call stack until you no longer need it.

> Rust wants to tie allocation lifetimes to scope in a very fine grained way that I would guess is beneficial the vast majority of the time, but does still make it harder to reason about when you’re about to stall out the CPU while the allocator does its thing.

It's really not substantially different. You allocate ahead of time or don't allocate at all. The only real difference is you might want to use an Option instead of an uninitialized pointer because it's semantically more correct and harder to screw up.

Well for one I wouldn't design it so both the LSP and the editor need a synchronized view of the underlying file.

Smoking

Algorithmic feeds make large "pile of all posts everywhere" social networks like Twitter and BlueSky viable IMO.

The mentioned "For You" feed for BlueSky appears to be a variation of LinkLonk's algorithm (by the same author), so how it works is partially known: https://linklonk.com/item/3292763817660940288

Bluesky has gotten considerably more tolerable by... adding an algorithmic feed ("For You"). It's developed by just some guy with the server running in his living room or something. I know people in this thread are down on algorithms, but a non-attention hacking algorithm is super, super nice because it helps cut out crap and show content in the niches I care about.

I was very happy to discover someone is building a phpBB-clone in ATProto (the thing that powers BlueSky): https://atmobb.app/

There's some hope that a small facet of forum culture can come back...

> They’re nondeterministic at a fine level, but can be “deterministic” at a more general level: e.g. you might know that one model will always return properly formatted json when asked. That might not be true of the replacement, even if it is in general “better” and cheaper.

This isn't true. Even Sol messes up JSON formatting for me on occasion.

Do not delude yourself into thinking these things are reliable. They are not.

It could be, but if it's a few lines of config in Anubis it would be easier and more likely to actually be done.

> Are you sure we shouldn't rather spend time getting better at, say, playing the piano?

Honesty, even if I could somehow make a decent living by doing that (you really can't), no I wouldn't.

I wonder if you could convince the Anubis author to implement x402 payments to bypass the PoW

You have it backwards, an intrusive linked list is a linked list that is embedded in another data structure. The classic example is a linked list whose elements live on the stack.

The article is wrong too, or at least using the term over-specifically.

It's not really tied to C++isms at all.

> which is the butt of every government inefficiency complaint

I always find DMV (or whatever your state's equivalent) inefficiency arguments to be hilarious. They're run extremely efficiently for the government. They suck use because of that (long wait times, most important stuff gets shipped by mail weeks later).

I'm personally pretty excited about Tangled (and ATProto in general), but I do have to caution that I've had some performance issues and some technical ones with hosting my own 'knot' and 'spindle' services

But it's an """ethical""" argument against it.

I'm happily in both depending on what it is. Even Sol / Fable cannot do some truly novel stuff and if you rely on it too heavily you get detached from the underlying systems to the point that it's both uncomfortable and detrimental.

I think you're misreading it (I did the first time as well). GP is saying "graph thinking" was not as common in 1996 as it is today, so is saying the opposite of it being a declining skill.

As someone working in this space: unless they're a very big player with resources to create custom hardware, afaik there's no way to actually prevent the GPU host from seeing the request content. There's no "secure enclave" that sits between a CPU and the GPU, the decrypted payload must necessarily hit system RAM, as would the output. They are, at best, running in TEE VMs which are also pretty horribly broken and don't provide the security that they say they do.

Tinfoil is almost certainly lying to you.

For those who didn't read, this is the identity of the mysterious "Ox Alpha" model

He sells outrage to ill informed people who don't know any better. There's real issues, but it's far more nuanced than Zitron seems willing to bring to his audience.

Datalog is awesome but I just don't think it's going to get mainstream adoption at this point.

Racket's lineage in Scheme is probably the reason it prefers lists over pretty much every other datastructure

I've also had a ton of luck getting agents to make focused, (mostly) well crafted commits using my home-grown git-based task manager: https://github.com/chiefnoah/tsk

It's very easy to be like: /tsk <big prompt> . Break down the problem into focused tasks using tsk, include all context necessary to complete a task in the tasks body, then prioritize them. Then begin working on them in priority order until complete.

Works 9/10 for me, though I often split up the instructions a bit so I have time to review the resulting tasks/design. tsk itself encourages creating single commits per task because it tracks the commit a task is closed on and the agents are pretty good about doing that.

It seems like a huge mixed bag. I have coworkers that has been able to "vibe" entire systems that somehow manage to work, but there's a lot of churn, weird bugs, and a huge reliance on <agent tools> to make any progress. Sometimes "good enough" is just that, sometimes it isn't.