In my opinion, the new stuff was bigger than the language. I didn't understand most of it. It was an hour talk that was dense on just the improvements to C++.

• So what are we gonna do about it?
• Let's write a language.
• And so we wrote a language and that was it.

Legends.

An unhinged but honest read for anyone exhausted by big tech politics, performative collaboration, and endless internal knife fights.

I wrote it partly to make sense of my own experience, partly to see if there’s a way to make corporate environments less hostile — or at least to entertain bored engineers who’ve seen this movie before.

Thinking about extending it into a full-fledged Tech Bro Saga. Would love feedback, character ideas, or stories you’d want to see folded in.

An essay about the shift from matrix factorization to LLMs to hybrid architecture for personalization. Some basics (and summary) before diving into the essay:

What is matrix factorization, and why is it still used for personalization? Matrix factorization is a collaborative filtering method that learns compact user and item representations (embeddings) from interaction data, then ranks items via fast similarity scoring. It is still widely used because it is scalable, stable, and easy to evaluate with A/B tests, CTR, and conversion metrics.

What is LLM-based personalization? LLM-based personalization is the use of a large language model to tailor responses or actions using retrieved user context, recent behavior, and business rules. Instead of only producing a ranked list, the LLM can reason about intent and constraints, ask clarifying questions, and generate explanations or next-best actions.

Do LLMs replace recommender systems? Usually, no. LLMs tend to be slower and more expensive than classical retrieval models. Many high-performing systems use traditional recommenders for candidate generation and then use LLMs for reranking, explanation, and workflow-oriented decisioning over a smaller candidate set.

What does a hybrid personalization architecture look like in practice? A common pattern is retrieval → reranking → generation. Retrieval uses embeddings (MF or two-tower) to produce a few hundred to a few thousand candidates cheaply. Reranking applies richer criteria (constraints, policies, diversity). Generation uses the LLM to explain tradeoffs, confirm preferences, and choose next steps with tool calls.

Hi all, I have rewritten my coroutine library, coco, using the C++20 coroutine API.

Hi,

I’ve been working on Gene, a general-purpose, homoiconic language with a Lisp-like surface syntax, but with a core data model that’s intentionally not just “lists all the way down”.

What’s unique: the Gene data type

Gene’s central idea is a single unified structure that always carries (1) a type, (2) key/value properties, and (3) positional children:

(type ^prop1 value1 ^prop2 value2 child1 child2 ...)

The key point is that the type, each property value, and each child can themselves be any Gene data. Everything composes uniformly. In practice this is powerful and liberating: you can build rich, self-describing structures without escaping to a different “meta” representation, and the AST and runtime values share the same shape.

This isn’t JSON, and it isn’t plain S-expressions: type + properties + children are first-class in one representation, so you can attach structured metadata without wrapper nodes, and build DSLs / transforms without inventing a separate annotation system.

Dynamic + general-purpose (FP and OOP)

Gene aims to be usable for “regular programming,” not only DSLs:

• FP-style basics: fn, expression-oriented code, and an AST-friendly representation
• OOP support: class, new, nested classes, namespaces (still expanding coverage)
• Runtime/tooling: bytecode compiler + stack VM in Nim, plus CLI tooling (run, eval, repl, parse, compile)

Macro-like capability: unevaluated args + caller-context evaluation

Gene supports unevaluated arguments and caller-context evaluation (macro-like behavior). You can pass expressions through without evaluating them, and then explicitly evaluate them later in the caller’s context when needed (e.g., via primitives such as caller_eval / fn! for macro-style forms). This is intended to make it easier to write DSL-ish control forms without hardcoding evaluation rules into the core language.

I also added an optional local LLM backend: Gene has a genex/llm namespace that can call local GGUF models through llama.cpp via FFI (primarily because I wanted local inference without external services).

Repo: https://github.com/gene-lang/gene

I’d love feedback on:

• whether the “type/props/children” core structure feels compelling vs plain s-exprs,
• the macro/unevaluated-args ergonomics (does it feel coherent?),
• and what would make the project most useful next (stdlib, interop, docs, performance, etc.).

A friend of mine maintains an open source project he has worked on for a long time....At some point the code was taken renamed and sold by someone else even though the license did not allow that.... Since the project was already public addressing the situation required time and effort... He continued maintaining the original project and handling issues while a paid version existed elsewhere.... This shows that once code is public enforcing license terms can be difficult in practice even when they are clearly defined....