evnc

I'm increasingly of the opinion that "basically a data warehouse, but incrementally maintained materialized views under the hood as an implementation detail" (e.g. Materialize, Feldera, anything based on Differential Dataflow / DBSP) is a good point in the design space. I get that they're more complicated than batch, and for many orgs the low latency isn't necessary for pure analytics/dashboards.

I wonder if there's a place for such architecture in the operational path, not just analytics. If you squint, "this microservice reads data from this operational DB and passes it to this other microservice / puts it in a cache / sends it in response to a request" looks sort of like an "ad hoc, informally specified, bug-ridden, slow"[0] implementation of incremental view maintenance (in that a cache, or a service's data model in memory, is a sort of "materialized view" over the source data). I've seen some success in replacing a tangle of imperative-languages-and-network-requests with a declarative, incrementally maintained model in SQL, if the read latency can be kept under control.

I'm curious about the "some amount of streaming influence moving back into the batch systems, particularly as object storage gives us the ability to run stateful workloads with less operational headache" part. could you expand on that?

[and yes, I do find these sort of problems interesting! :)]

[0] https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

I’m not opposed to this but, curious, what do we gain from such reconceptualization?

Oh, okay, I get the value prop now. Thank you. They should hire you to write their marketing copy, you did a better job than the landing page.

Tana is basically a programming environment disguised as a text editor (in this way, it follows in the grand tradition of emacs you could say)

doh, good point. will fix this, I acknowledge I sort of handwaved the example. thanks for the correction!

one more, for completeness:

  SELECT 'black' AS outline_color
  FROM elements parent
  JOIN elements child ON parent.id = child.parent_id
  WHERE parent.data_theme = 'light'
    AND child.data_theme = 'dark'
    AND child.focused = true

there's a lot of ways to express the same thing! it's interesting to notice the connections between them, I think, and their strengths and weaknesses, e.g. I probably wouldn't want to write my whole design system in SQL, but since it's relational queries over the elements structure and properties, you could.

yeah I mean, to be clear, I'm less proposing "What if we add even more syntax and semantics to CSS" and more "what if we steal ideas from CSS, notice their similarity to logic / relational query languages, and use them to build something new". I probably could have articulated some of this better.

eg this example:

  [data-theme="dark"] [data-theme="light"] :focus {
      outline-color: black;
  }

means, in English/pseudocode, roughly: "If you have an element X with attribute data-theme="dark", and X has a child Y with attribute data-theme="light", and Y is focused, then the outline-color of Y is black".

so we could write this also as, e.g.:

  outline-color(Y, black) if 
    data-theme(X, "dark") and
    parent(X, Y) and
    data-theme(Y, "light") and
    focused(Y)

that's Datalog, except I went ahead and replaced :- with "if" and "," with "and".

if we want even more syntax sugar, we could do:

  Y.outline_color := black if
    X.data-theme == dark and
    Y.parent == X and
    Y.data-theme == dark and
    Y.focused

imagine `X.attr == val` <==> `attr(X, val)` as a kind of UFCS for Datalog to make it palatable to Regular Programmers, right

the declaration and scope of these variables is implicit here; if you want something even more ALGOL-family, we could write

  forall Y {
    Y.outline_color := black if 
       Y.data_theme == "dark" and
       Y.focused and
       Y.parent.data_theme == "light"
  }

here we've explicitly introduced Y, and made one of our joins implicit, and it looks even more like Regular Programming now, except the Datalog engine (or equivalent) is kind of running all these loops for you, every time one of their dependencies changes, in an efficient way ...

oh this is fun

> we copy and reapply patterns in different contexts and that might enable unexpected things

yeah, that's exactly what I am trying to do here. Mostly it doesn't go anywhere, but it's interesting for the hacker spirit within me :)

tbh, this started as a connection of two disparate ideas ("hey, this thing looks like this other thing"), and then just kind of explores it in different directions.

I think the conclusion (which I may not have made clear enough) is less like "These are limitations of modern CSS which ought to be fixed" and more "Maybe a CSS-like syntax could be added to a Datalog-like system and that would be helpful for making it more accessible to more engineers, navigating tree-shaped data, etc"

thanks for the feedback, anyway!

oh this is neat! Feels like exactly the sort of thing I was gesturing towards. Thanks :)

sure! You can email me at notches_hoses_58@icloud.com (throwaway email), and we could go from there?

I broadly agree with you, so I want to pick your brain a bit:

What would your ideal RDBMS / tooling look like, that facilitates 6nf effectively? Do you think it's more a limitation of the query/storage engine, or the query language (SQL), or the user interface? Do you think founding on Datalog (or similar), which kinda lends itself to "narrow" relations, instead of SQL which kinda lends itself to "wide" relations, would help here?

(I ask as one of my personal hobby-horses is trying to design better query languages and tooling, and 6nf/datalog maintains a kinda special place in my heart)

Someone has done a ray tracer in DuckDB, so essentially, yes: https://simonwillison.net/2025/Apr/22/duckdb-wasm-doom/

Interesting. Does that mean if you want to say, make an asynchronous http request, you do something like “fire_event(HttpRequestEvent(…))” which returns immediately, and somewhere else define a handler like “on_event(HttpResponseEvent, function (event) { … })” ? So you kind of have to manually break your function up into a state machine composed of event handlers? How do you associate a given HttpResponseEvent with a specific HttpRequestEvent?

I assume they're doing "Structured Generation" or "Guided generation", which has been possible for a while if you control the LLM itself e.g. running an OSS model, e.g. [0][1]. It's cool to see a major API provider offer it, though.

The basic idea is: at each auto-regressive step (each token generation), instead of letting the model generate a probability distribution over "all tokens in the entire vocab it's ever seen" (the default), only allow the model to generate a probability distribution over "this specific set of tokens I provide". And that set can change from one sampling set to the next, according to a given grammar. E.g. if you're using a JSON grammar, and you've just generated a `{`, you can provide the model a choice of only which tokens are valid JSON immediately after a `{`, etc.

[0] https://github.com/dottxt-ai/outlines [1] https://github.com/guidance-ai/guidance

Always enjoy Derek Lowe's writing.

n=1 here, though I've heard others say the same -- but I (fairly healthy 30s male, vaccinated) found Paxlovid massively reduced symptom intensity for me. Within a day my symptoms went from "top 5 fevers I've ever experienced, normal function significantly impaired" to "feels like a cold; can reasonably handle myself around the house and even take a software engineering interview".

I most likely would not have got a severe infection and probably would not have got Long Covid, given my age / health / vaccine status, even if I hadn't taken it; but nonetheless I'm glad I was able to get it. Definitely worth it for the weird taste (hard candy helps).

Trying to make the same transition right now. I’ve got almost 10 years experience with python and data engineering and I’ve been reading tutorials and playing with projects on the side.

I think I’ve got a grasp of the fundamentals and the ability to learn fast on the job, but every MLE job listing I see wants “4+ years of experience training and deploying models in a production environment” or something (even non-Senior roles!). I’m not sure how to break into it, to acquire a MLE job to get the experience to acquire an MLE job. Does anyone have any advice?

I'm a bit of a noob here, but if

a) a linear SSM (a form of RNN?) is equivalent to Attention without the scaling and softmax; and

b) Attention is "all you need" and the thing that made Transformers radically outperform all the previous architectures like LSTMs that used to dominate NLP;

does that imply c) the scaling and softmax parts of the attention equation, in particular, is the magic touch that makes Transformers work so well?

Doesn’t this effect happen with EVs generally, not just Teslas? (I don’t particularly mean to defend Tesla here, but I wonder if this might be misleading)

Hey, this is neat! Thanks for sharing. I may be interested in collaborating with you on this when I have some free time.

When I see an embedded DSL passed around as strings like this I can't help but think "this could be its own programming language"

Then it could have syntax highlighting, auto complete, and so on. The type system for such a language could possibly include verifying shapes at compile time.

What would a language comprised of .ein source files for manipulating tensors, which compiles down to the same low level ops, look like?

They're commoditizing their complement [0][1], inasmuch as LLMs are a complement of social media and advertising (which I think they are).

They've made it harder for competitors like Google or TikTok to compete with Meta on the basis of "we have a super secret proprietary AI that no one else has that's leagues better than anything else". If everyone has access to a high quality AI (perhaps not the world's best, but competitive), then no one -- including their competitors -- has a competitive advantage from having exclusive access to high quality AI.

[0]: https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/

[1]: https://gwern.net/complement

Reminds me of Heynote, posted to HN recently[0].

In general I think this approach of "super easy capture into an append-only log" is great, especially if it can be paired with features to enable editing/re-discovery/search/synthesizing old ideas together, which exist in a separate view/mode from the "just get something down as fast as possible" mode. Working on something like this, but just in nights/weekends free time with other obligations, so it's been slow going.

[0] https://news.ycombinator.com/item?id=38733968

From the title alone, I initially thought this would be about meditation.

Yeah, it's a balance. I love being able to help, and I am generally in favor of asking questions early, but not ones of the form "hey so I ran this code and it errored. Help?"

"... did you read the stack trace? Did you look at the code referenced by the stack trace?"

This is where I've learned responding with "Sure! What have you tried so far?" is relevant.

This is an interesting point, because they are kinda infinite spaces but they also impose a structure on the space, which I would assert is a part of why they are so successful, in contrast to the "infinite structureless blank paper" that the OP is talking about.

The trick is getting the amount of structure just right, not too much to be too restrictive and not so little that users are lost in the way the person you're replying to describes.

This is fair -- the newest token can attend perfectly to the oldest token, within the context window.

but also, on a broader scale, if a transformer model is presented with a long input that does not fit in its context (e.g.: you are building a chatbot, and you have a very long chat history), it must "compress" or "forget" some of that information (e.g.: repeatedly summarizing historical messages, dropping them and appending the summary at the beginning of the input).

Mamba/RWKV/other "recurrent" architectures, can theoretically operate on unbounded input lengths; they "forget" information from earlier tokens over time, but is that not comparable to what a transformer must do with input lengths greater than their context window?

I love this! Simple and solid execution. I've been wanting to build something similar for some time now, might fork and play around with it. Thank you for open sourcing it!

I've started using Obsidian with a new note for each day and separating "blocks" with a Markdown horizontal rule (`---`) to achieve something similar, but this is much cleaner.

The strength of such an approach is making capture extremely easy -- new block, start writing, no thinking about where this goes and how to fit it into pre-existing structure. I find that if I'm trying to do that, then by the time I find where my idea goes, I've lost the idea.

The downside, of course, is finding things again. The ability to tag or title a block and search by tag or title would be great. More ambitiously, it would be cool to experiment with incorporating LLMs and embeddings to automatically tag, summarize, categorize, cluster etc. your blocks.

There's a lot of different directions one could take this, but I'll echo the sentiment of others to refrain from adding too many features and losing the original appeal of simplicity. :)

Also: How do you handle performance when the buffer gets very large?

What kind of tokens/sec do you get?

Have you looked into quantization? At 8-bit quantization, a 7B model requires ~7GB of RAM (plus a bit of overhead); at 4-bit, it would require around 3.5GB and fit entirely into the RAM you have. Quality of generation does degrade a bit the smaller you quantize, but not as much as you may think.