I think it's the fact that NMS has a lot of systems, but they are just separate, and they have a lot of limitations. Ships are separate from bases which are separate from freighters. They sometimes interact if it's explicitly coded, but nothing is allowed to be emergent.

In Minecraft I can put 100 nether portals in my basement if I feel like it, and I can set up a sheep farm in hell. I can pour water into my base and have a mini pool with fish. I can make copper golems that move items, and that opens a whole can of worms.

In NMS, it feels like I have no freedom to experiment at all. For that reason, it's been pretty hard to get into. Everything feels so baked in place. The only thing that really scratched that itch of mine was making big farming factories. But I was not interested after that.

I think these people are real and predate AI. I think it comes down to a fundamental psychology in how the two browsers are marketed online. Firefox users would say "Firefox is better than Chrome." Chrome users would say "Chrome is good." Firefox is touted as a better browser on the principle of the freedom it gives its users, and paradoxically, that draws heavy scrutiny.

I don't think I am doing a Goomba fallacy here. People that claim to care about privacy and browser freedom will express disgust with Mozilla then, in the same breath, say they are opting into Chrome out of spite, which is 100x worse.

As opposed to other languages where you don't build real apps? I don't think anyone was arguing you can't make real apps in CL

LSPs vs LLM Autocomplete are a different story, but I can just turn that off.

Now I am living in a world where "ChatGPT" was being used in every day conversation so I can't underestimate people

The average person does not know the term "open source" to begin with, and is 100% not going to run an open source weight model on their computer. If they are, they will call them "free" models. I think the distinction is only going to enter the periphery of nerds.

I can assure you that's not the case on here. The people working in truly low latency environments are not commenting on GC threads to begin with because it's a non-starter for them. For whatever reason, there is just a chunk of people that eat a lot of FUD around GCs who are working in the exact domains they thrive in.

Is it just because it's easy to substitute code in on the fly? Doesn't that describe any interpreted language?

You mean don't return :users/id when that's what was passed in? That makes sense, but I don't think I ran into issues with it.

> The :fat-key isn't doing anything here

For me it is. The absence of it means only one of the resolvers is run regardless of data order.

> This is very explicit and about equivalent to your original thought of "why not just have explicit imperative function calls"

I've been playing with this more today. My big thing is I want some good guidelines for writing resolvers to begin with so query time is not an exercise in auditing the whole codebase. Here are some guidelines I played around with, let me know what you think.

- When a resolver gets an entity and related data (like `get-user-with-customer`), try to pack related entities into their own nested collections. I.E. don't return `[:users/email :customer/name]`, return [:users/email {:users/customer [name]}`. This makes it less ambiguous, as putting the customer information flat with the other user data can complicate queries later on. Like if you select a user and their last order, what does `:customer/name` refer to? The customer of the user or the customer of the order?

- If a resolver is really expecting to operate on a users customer id, make that explicit in the input with `{:users/customer [id]}`.

- If you want a resolver to stay "open" and not specify where its inputs come from (just takes `:customer/id`), you can make bridges between that resolver and the entity resolvers that translate to the right keys (A bridge that turns `{:users/customer_id}` into `:get-billing-method/customer_id)

- Careful seeding multiple entities. If you feed your query the params `{:users/id 16230 :admins/id 9}`, it's not clear what the requested data is applying to (is `:roles-and-permissions` applying to the admin or the regular user?)

When I say cached result I misspoke, I mean Pathom, rather than running the one resolver that gets everything, will first see the resolver that gets only the user and grab that. Then it will consider :user/email satisfied and look for other resolvers. It seems to not look for the resolver that solves all the requested data, and instead goes first come first serve.

> In the first case, the situation looks largely the same. I mean you can either uses the same nested inputs strategy but have a special key that triggers the fat-query resolver. Something like :employed-user-id.

> The other alternative is using nested outputs. You have the resolver returned a keyed bundle. Something like {:fat-request [:users/email :company/phone_number]}. The downstream resolver then consumers a :fat-request and unpacks it using nested inputs.

> You can make resolverZZ output some dummy key :zz-was-run. If you request :zz-was-run then I think it should also take the branch? (or maybe it runs both branches)

I think that these tricks can work sometimes, but you might be surprised what odd behavior can come up if you rely on this. In your pathom query, the order of your requested data matters.

    (pco/defresolver get-user [{:users/keys [id]}]
      {::pco/output [:users/id :users/email :users/customer_id :users/budget]}
      (println "get-user triggered")
      (-> (jdbc/execute-one! ds ["SELECT * FROM users WHERE id = ?" id])))
    
    (pco/defresolver get-customer [{:customers/keys [id]}]
      {::pco/output [:customers/id :customers/billing_number :customers/phone_number]}
      (println "get-customer triggered")
      (-> (jdbc/execute-one! ds ["SELECT * FROM customers WHERE id = ?" id])))

    (pco/defresolver get-user-with-customer [{:users/keys [id]}]
      {::pco/output [:users/id :users/email :users/customer_id :fat-key
                     :customers/id :customers/billing_number :customers/phone_number]}
      (println "get-user-with-customer triggered")
      (let [user (jdbc/execute-one! ds ["SELECT * FROM users WHERE id = ?" id])
            customer (jdbc/execute-one! ds ["SELECT * FROM customers WHERE id = ?" (:users/customer_id user)])]
        (merge user {:customers/id (:customers/id customer)
                     :customers/billing_number (:customers/billing_number customer)
                     :customers/phone_number (:customers/phone_number customer)
                     :fat-key true})))

    (def user-customer-bridge
  (pbir/alias-resolver :users/customer_id :customers/id))
    
    ;; ---- test1
    (p.eql/process env
                   {:users/id 1000}
                   [:fat-key
                    :customers/phone_number
                    :users/email]) 
    
    ;; ---- get-user-with-customer triggered
 

    ;; ---- test2 
    (p.eql/process env
                   {:users/id 1000}
                   [:customers/phone_number
                    :fat-key
                    :users/email])
    
    ;; ---- get-user triggered, 
    ;; ---- get-user-with-customer triggered