non lazy.clj

(def urls {:vg "https://www.vg.no", :ap "https://www.ap.no", :db "https://www.db.no"} )

(defn my-get-request [[k url]]
  [k (future (http/get url))])

(->> urls
     (map my-get-request)
     (reduce (fn [acc [k v]]
               (assoc acc k (deref v))) {}))

Looks like map does the same thing as for, and returns a lazy seq, so you still need a doall to avoid chunked realization of the futures.

(defn my-get-request [x] [x (future (do (Thread/sleep 1000) x))])

(time (->> (range 0 100) (map my-get-request) (reduce (fn [m [k v]] (assoc m k (deref v))) {})))
; => "Elapsed time: 4010.6218 msecs"

(time (->> (range 0 100) (map my-get-request) doall (reduce (fn [m [k v]] (assoc m k (deref v))) {})))
; => "Elapsed time: 1025.489758 msecs"

I know that map is as lazy as for, but the thing is that reduce is not. It would be interesting if you could add some timings to this.

Yeah! I see where the problem comes from now :)

(defn my-get [i]
  [i (future (:status (http/get "https://www.vg.no")))])

(->> (range 100)
     (map my-get)
     (reduce (fn [acc [k v]]
               (let [t (System/currentTimeMillis)
                     v' (deref v)]
                 (println "Spent " (- (System/currentTimeMillis) t) "ms dreffing" k)
                 (assoc acc k 'v))) {}))

You'll see time spent on every 32nd element, indicating that the thing is not done as we'd like.

(defn my-get [i]
  [i (future (:status (http/get "https://www.vg.no")))])

(defn transmogrify [acc [k v]]
  (let [t (System/currentTimeMillis)
        v' (deref v)]
    (println "Spent " (- (System/currentTimeMillis) t) "ms dreffing" k)
    (assoc acc k v')))

(->> (range 100)
     (reduce (fn [acc i] (conj acc (my-get i))) [])
     (reduce transmogrify {}))

does the thing :)