Yeah. "Glorified autocomplete" might be all the human brain is too. "Glorified autocomplete" can do an amazing number of things, including perhaps pass the Turing test and perhaps ... "think".

"Glorified autocomplete" is meant to describe the _underlying mechanism_, but unfortunately it also sounds like one of the things LLMs are actually used for, so it gives the mistaken impression that the claim is all they are good for is a component inside an editor application.

All my life, when I would think back to what mill towns went through when they all closed (something I did not live through), all my naive outsider brain could arrive at was, "Yeah, but those were just grunge jobs, humans were freed up to do better stuff."

And perhaps the same thing is now happening to me. It feels different, but maybe the same thing is true.

How do you know it feels different? It may have felt exactly the same to them.

Is the high barrier to entry essential though? Is there something about the nix domain that would mean any solution would have as high a barrier to entry? Or is it something they could have simplified greatly, and just never did? (Asking as an outsider, I've always been curious about this).

I went into Nix thinking I would understand the whole thing and then distill a very simplified version, but as it turns out, a significant amount of the complexity is basically required for it to work like it’s supposed to, given how builds and runtimes and dependencies across various languages work, which is unfortunate

Some parts could be smoother.

Here's a rough sketch: the Nix expression language is really configuration oriented; it's a "JSON + functions" kind of language. You write Nix to describe how a package is built; the ideal case being "./configure && make && make install" as such. The resulting packages are put in a Nix store. (Almost) every dependency is put in the Nix store; so your program links against libraries in the Nix store, or runs other sources from the Nix store.

- Nix is "just" declarations of those instructions which output into directories and everything gets symlinked. But, it can take time to build an intuition for how to do things.

- There's some fundamental friction where most Linux systems assume shared libraries are available globally in a typical place on Linux. -- e.g. Python's "wheels" come with precompiled dependencies which assume shared libraries are available in a global place. Nix doesn't provide that.

- "Why not just provide globals?" For one, by having everything not be global, you can have multiple versions available at the same time.

- Since Nix is quite 'strict' by default about everything coming from the Nix store, it practically means 'paying' for all the difficulties up front. (There's a trade-off where you could write packages in a less strict manner; this is great for iterating, but bad for maintainability).

- Since Nix is strict about symlinking all dependencies, often if upstream software does things in a "quick and dirty manner" (e.g. hardcodes "/bin/bash", hardcodes paths for binaries to run, etc.) then it can be difficult to describe how to package that software with Nix. -- Fundamentally, you're taking something which works loosely, and bringing it into a stricter system.

- Upthread the comment mentions "flakes". Flakes provide both dependency management (i.e. being able to declare other Nix codebases you'll use), as well as a standard entrypoint into a Nix codebase. -- Without flakes, the UX is a bit cumbersome..

- The majority of packages which people use come from "Nixpkgs" package repository. This has a lot of organic complexity to it, coming from multiple contributors, with competing ideas for achieving results.

- With Nix being a "json + functions" language.. not sure I'm articulating this right, but it means that practically a large codebase is built as a single 'expression' (i.e. soft boundaries between bits of code).. and the tooling for troubleshooting problems is ... not very good.

- The Nix expression language is functional and lazy. This can be rough for people who don't have this background.

- Since Nix adds a layer of abstraction, it means you might need to have both a broad and a deep understanding to get something working (e.g. understanding how to drive Python or Linux in non-conventional ways). -- A kind of "do everything properly" which more conventional systems don't require.

So ... some aspects could be easier. But I think there's a fundamental friction to it.

Surprised it is not "Super Intelligence of America"

I'm just surprised he didn't rename it to American Intelligence.

That's Lake Super Intelligence to you.

(Like Superior Intelligence, I believe?)

Too late to edit: Lake Superior Intelligence (duh).

There is a Gulf of Super Intelligence.

That tension is doing real work.

That quiet tension you feel is a valid signal.

Here's the part no one is talking about.

This is worth stating explicitly.

I still remember how hard I was struck by the scene in The Orville, where someone from another planet hears a Dolly Parton song playing and asks who it is. He goes on to say, "She speaks with the might of a hundred soldiers!"

She did. She is one of our species' great poets.

That was a really great cameo.

But do we really need a paradigm shift in how we express the concept of a paradigm shift? It's not like the meaning of the words expired.

But inference costs scale per task whereas platform services like postgres typically amortize across tasks. If you are selling tasks done by inference, then compute is part of your COGS and it scales per task.

Much more so, I would agree. A bit like how mainframe batch jobs might have once been charged back based on "cycles" used for a job or other tracked metrics.