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.
Summarization—especially of private context—is definitely one of the main exceptions to LLM writing being useless. However, it's still preferable to turn your private context into shared context and then give pointers to that, rather than having an LLM attempt to summarize it.
> 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.
But here I feel like we’re at risk of heading down the same old doom spiral that plagues any conversation about programming languages when people try to treat it as a competition: getting pedantic about what’s technically possible in a language. It’s much more interesting to talk about how a language wants to be used.
So, in the case of Zig, every function that wants to be able to allocate or deallocate heap memory needs an explicit reference to an allocator. That means that you can tell whether a function might allocate memory from its signature. It also means that changing a function so that it can allocate is explicitly a breaking change.
That’s a really interesting design decision. And the reasons why someone would or would not want something like that baked directly into the language are so much more interesting than bickering about how technically with proper discipline you can have that kind of control in any non-GC language.
> That means that you can tell whether a function might allocate memory from its signature.
In practice that's not the case, as many objects own a reference to their allocator. It's still explicit, but it might be hidden in the signature, especially if you have some sort of interface that can take an allocating and a nonallocating data structure alike.
Not original commenter but the reality with zig is a little in between being simply convention vs. a language requirement. Is it a language requirement? no.
However, there's no global allocator in zig. You simply cannot call the language's equivalent of malloc() because it doesn't exist - at least not as a global symbol. That leaves you with three choices:
1) Define a global allocator; is a valid choice and would make a zig program more like C, C++ or Rust in terms of not having to think about scope-level allocation patterns
2) Pass an allocator into that scope (this is the community convention)
3) Create/instantiate an allocator itself inside that scope
(1) would be valid, though may not be idiomatic; global allocator like malloc becomes an opt-in
(2) Expensive and inefficient for most scopes, though not all.
(3) cheap, idiomatic but potential for noise/boilerplate
> However, there's no global allocator in zig. You simply cannot call the language's equivalent of malloc() because it doesn't exist - at least not as a global symbol.
I mean std.heap.page_allocator is global, and there's only the one, and you can call it from wherever (just as you can malloc). Same with std.heap. c_allocator, which is... malloc! you can also create your own global allocator.
Don't do this in libraries ofc or the ghost of Andrew Kelly will haunt you in hour sleep.
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.
The reason that algorithmic feeds were introduced was essentially that Zynga and various heavy posters were killing Facebook (but mostly Zynga).
Back near the dawn of time, FB's feed was chronological, and that meant that Every.Single.Farmville.Notification showed up in your feed (and there were a lot of Farmville notifications).
This was actually causing real problems for Facebook, and they introduced an algorithmic feed to fix it. Back then, it was actually relatively simple, and mostly just ranked posts based on how connected you were to the person on Facebook.
Obviously things have changed since then, and algorithmic feeds have had a host of weird impacts, but a ranked feed is not necessarily bad in and of itself.
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
I get a LOT of untagged NSFW and political posts in my For You. I'm guessing it's influenced by the likes of people I follow. I don't know WHO to unfollow... and I don't really want to unfollow anyone.
I kinda wish I could influence my For You with rules:
> 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.
Is nobody using structured outputs? They use constrained decoding at the generation stage to ensure the probability of tokens that would break the format are set to 0. I kinda figured everyone was doing this at this point.
Most serious providers are now supporting structured outputs in a reasonable way for all model configs. But for example on ollama structured outputs are still incompatible with tool calling and with reasoning
If you use a large enough volume, you will know this isn't fully reliable. You might get json, and it might not match what the model actually sent because the last layer cut it up to match what you want. At the end, not json, or json but not really matching what the model wanted, it's sort of the same issue: when you use them you HAVE to assume they can have a brain fart. That's fine, just code around it.
We use structured output and To my knowledge it has never failed (millions of data points). There seem to be two classes of people: those doing productive work with LLMs, and those who only get replies insulting their mothers…
Point is if humans need to struggle with something to build neural pathways, character etc. then getting better at playing an instrument is as good at that as anything, even if it has very little economic utility (I thought that part was obvious). Programming might soon have equally little utility.
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.
GP points out that what the article calls "intrusive linked list" is a regular linked list. Wikipedia for instance gives the canonical linked list example of a struct with one embedded integer and a next link and of course does not call it "intrusive linked list".
"Intrusive" got popular with C++ intrusive pointers, and that is where the article gets is misinformation from.
And of coursed the web jockeys downvote the correct objection since they have no clue about data structures, history, logic or basic reading skills.
>"Intrusive" got popular with C++ intrusive pointers
It got popular with C++'s attempts at type safety. In particular, std::list lets you accomplish the machinery without macros, and allowing for polymorphism (heterogeneous lists of derived instances) without weird type casts and overallocation tricks, but at the cost of another level of indirection.
reply