viz. wework could apply the "single-use low-priced shampoo sachet" model [0] to SaaS-style rent-seeking of long-lived infrastructure. Infra. that is guaranteed to be always under-utilised... even in boom markets, because nothing functions at 100% capacity.

Adobe, as another example of (software) infrastructure --- i.e. traditionally, lifetime licence and ownership desktop software --- figured out their own "shampoo sachet" pricing. viz. how to make and ship desktop software product but kill-switch them with metered SaaS subscriptions.

The monthly price is just high enough to make gobs of cash for Adobe, while causing the typically-feast-and-famine freelancer to take the capitalist shellacking because it's just convenient enough. They can align software spends with active projects, and avoid the anxiety of cracked software doing nefarious things to their computers and data.

But over a long enough time, they pay Adobe a (presumably) huge premium over up-front priced software. And they stay locked into a planned obsolescence cycle controlled by Adobe... "The new version of your beloved editing software will only work with the latest Windoze which means hardware upgrade and oh, you have to do it because well we are soon kill-switching the current version you are dependent on."

Wework like operators can do exactly similar shenanigans with access to commercial infrastructure. Crowd out competition by aggressive long-term leasing on their buy-side, and on their sell-side build daily-subscription-dependency (buying ease, google-ish facilities which feeds into cult-and-status-signalling games), and convert a percentage of that into routine-subscription-dependency. Meanwhile also run rent-seeking games inside the main rent-seeking game... now you have a captive wallets who will buy the add-ons and extras because it's easier than walking two blocks for some cheaper and better alternative (e.g. food, coffee, lovely meeting space etc.).

edit: add reference for "daily sachet pricing".

[0] Buying less, more often: An evaluation of sachet marketing strategy in an emerging market

https://www.researchgate.net/publication/233676293_Buying_le...

Worth changing the submit URL to this one?

Edit: never mind. Spoke too soon. Ingy is keeping gloathub/glojure fork and glojurelang/glojure source at parity.

> Where jank differs from Clojure JVM is that its host is C++ on top of an LLVM-based JIT. This allows jank to offer the same benefits of REPL-based development while being able to seamlessly reach into the native world and compete seriously with JVM's performance.

https://jank-lang.org/

Comments URL: https://news.ycombinator.com/item?id=48580277

Points: 32

# Comments: 0

[0] https://gloathub.org/blog/2026/06/16/gloat-q2-grant-halfway-...

> We are halfway through the Q2 2026 Clojurists Together funding cycle, so this is a good time to report what has been done for Gloat and Glojure.

...

> Since the start of the grant period, Gloat and Glojure have had over 20 releases, with Gloat moving from v0.1.26 to v0.1.50. The Glojure work was all being done on the long running fork gloathub/glojure, but I'm thrilled to announce that as of today, the work has been fully moved back to the upstream glojurelang/glojure and will continue to be maintained and released from there.

> My overall ambition for Gloat is to have Clojure be as full featured and prominent to Go programming as it is to Java. The industry is crazy about Go. Let's get it crazy about Clojure.

[1] https://www.clojuriststogether.org/projects/#Gloat:~:text=Ma...

> Make Gloat/Glojure binaries smaller and faster. Pass more of the Clojure Compatibility Test Suite. Create tutorial docs on: How to use Gloat to integrate Clojure into Go projects and How to use Gloat instead of GraalVM to (cross-)compile Clojure.

Here are my reasons, copied from my site's "Standing Invitation" [0].

> Email me just because (not just for work). Whatever feeds your curiosity; silly, fun, nerdy, serious.

> Why?

> 1. Do unto me what I have done unto others. I habitually cold-email anyone who moves me in some way (joy, insight, utility, mind shift…). I also love to receive such email!

> 2. There is too little unsolicited positive feedback in much of most of our lives. At some point in the fuzzy past, I decided enough was enough. At least someone somewhere ought to feel good sometime for no reason whatsoever. Since that realisation, I have cold-emailed people willy-nilly. See also: Saying Thank You [1], and Days Are Easily Made [2].

> 3. It's always been a delight; no regrets. You should try it too!

> So, let serendipity reign; write away!

[0] https://www.evalapply.org/about.html#standing-invitation

[1] https://blog.jim-nielsen.com/2022/saying-thank-you/

[2] https://www.autodidacts.io/how-to-make-someones-day/

Comments URL: https://news.ycombinator.com/item?id=48536167

Points: 33

# Comments: 0

cf. https://sqlite.org/withoutrowid.html

> The WITHOUT ROWID syntax is an optimization. It provides no new capabilities. Anything that can be done using a WITHOUT ROWID table can also be done in exactly the same way, and exactly the same syntax, using an ordinary rowid table. The only advantage of a WITHOUT ROWID table is that it can sometimes use less disk space and/or perform a little faster than an ordinary rowid table.

As of now, I am doing the following in my (Bitemporal data system) experiment (When will it see the light of day? Nobody knows.).

All data are globally uniquely identified by a UUIDv7. However all tables have `rowid` integer primary key asc (which is just an alias for SQLite's autoincrement int id). The `rowid` is the basis for joins, and is the foreign key reference. This lets me offload some useful disambiguation work to the DB as well as have it enforce global (across data systems) record uniqueness guarantees, while retaining local (within process) query efficiency by retaining the ability to use integer rowids.

While the idealised insert performance in your bench is indeed mind-boggling, the DB Schema isn't doing anything CPU-intensive during inserts (checks, constraints, triggers etc.). My schema / query pattern yields comparatively meagre throughput, but I am happy with the ballpark it has landed in, given all the work I'm making SQLite do for me on each `assert!` and `redact!`.

cf. my dirty-but-useful-enough bench, with production-like record content:

A poor man's napkin-mathy, append-only SQLite write/read benchmark

https://gist.github.com/adityaathalye/3c8195dc70626b33c23867...

Summary:

  ;; Okay, I think I can live with this...

  ;; - "facts" table: 12M+ records
  ;;     - single process writes to it
  ;;     - ~ 400 transactions/second
  ;;     - append-only table, enforced via SQLite "before" triggers
  ;; - "now" table: 
  ;;     - updates on every assert/redact on "facts" table, via triggers
  ;;     - currently at "limit case": for each read it is empty, or very small, because writes do back-to-back assert/redact of the same fact
  ;;     - gets reads from two reader threads (evenly split)
  ;;     - ~41,000 reads/second
  ;; - all reads are concurrent with writes (poor man's futures)

Thanks to its oh so convenient automatic integer rowIDs, I believe one can amortise some of the other overheads of UUIDv7s for "in-between" queries, viz. indices, joins, ctes, virtual tables etc., with appropriate schema / query design.

I read this post more as an illustration of the *value* of UUIDv7 as primary key, over integer primary keys, in lieu of minimal loss of read/write performance, and marginally more data on disk bloat.

SQLite's automatic integer rowID primary key is a no-brainer, when the SQLite application is local-only, such as application storage format (mobile and desktop). Or is never intended to grow beyond a single server instance. Basically, where each SQLite file is private to a singular instance of the application.

However, if there is even an outside chance of needing to cooperate across application instances, e.g. the minimal limit case of a personal knowledge base that should seamlessly sync across a person's devices, as well as a hosted service, then a high-quality sequential random ID starts to make a lot more sense. (No-brainer arbitrary table merges / splits / remerges, de-duplication, etc.)

Random ID primary key is a bad idea period, whether it be the UU kind or the SQ kind, or any other kind. As far as my DB knowledge goes, this class of ID destroys all tree-algorithms, and we are stuck with the fact that there is no practically better way, than an appropriate tree-structure, to group and organise a meaningful amount of data, efficiently and effectively.

Different brains, different strokes, but I think the book format is not wrong, the teaching and learning expectations are.

Comments URL: https://news.ycombinator.com/item?id=47944031

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47907666

Points: 2

# Comments: 0

Many nonprinting characters imply some directive; line break (hard-wrap the text here, but this is not a paragraph), page break (let the rest of the page be blank, start the next paragraph overleaf), EOL (file over, bye bye), nonbreaking space (keep these two words together, always, till death do them part).

This is out-of-band information spliced in-band (with the text corpus), which a computer program can "see", but a person can't.

But that is the "fear" side of the enterprise sales equation... The "greed" side of it is for the buyer to make the long / short hedge.

The exec who gets the value of the working product can potentially come out shining, when their peers will be furiously backpedalling next year. And this consummate exec can do it by name-associating with their "main bet" which is optically great for the immediate term but totally out of their control (because big corp vendor will drag its feet like every SAP integration failure they've seen), and feeling a sense of agency by running an off-books skunkworks project that actually works and saves the day.

A fine needle to thread for the upstart, but better than standing outside the game.

Comments URL: https://news.ycombinator.com/item?id=47885668

Points: 103

# Comments: 60

Well, I think of every Large Language Model as if it were a spectacularly faceted diamond.

More on these lines in a recent-ish "thinking in public" attempt by yours truly, lay programmer, to interpret what an LLM-machine might be.

Riff: LLMs are Software Diamonds

https://www.evalapply.org/posts/llms-are-diamonds/

Comments URL: https://news.ycombinator.com/item?id=47851913

Points: 2

# Comments: 0