F# vs Clojure

код на F#(dotnet core 3.1.100 LTS)

open System

[<EntryPoint>]
let main argv =
    let r = seq {0L .. (1000000L - 1L)} |> Seq.reduce (+) 
    printfn "Result is %d" r
    exit 0

код на Clojure (OpenJDK Runtime Environment GraalVM CE 19.3.0.2)

(ns c1.core
  (:gen-class))

(defn -main
  "I don't do a whole lot ... yet."
  [& args]
  (time
  (let [r (reduce + (range 0 1000000))]
  (println (str "Result is " r)))))

Результат оказался следующим:
F#:
  time ./f1
Result is 1783293664

real    0m0,691s
user    0m0,226s
sys    0m0,056s

Clojure:
time java -jar /home/noname/Documents/c1/target/uberjar/c1-0.1.0-SNAPSHOT-standalone.jar
Result is 499999500000
"Elapsed time: 1365.29806 msecs"

real    0m27,731s
user    0m6,690s
sys    0m0,792s





Как видим, неприятным последствием использования jvm является очень медленная загрузка самой программы. редукция также отстает от кода на коре. Еще одна неприятность - кложура упала во время выполнения когда я по ошибке написал (take 100) вместо (range 0 100). Такова природа диманических языков. Вместо типизации требуется обязательно тестирование кода. Взамен кложа корректно расширила тип до 64 выдав сразу правильный результат. Фшарп ожидаем вывел int32 и вызвал переполнение буфера выдав неверный результат. подставив литерал L в выражение seq {} я дал компилятору подсказку и второй запуск работал корректно.
Вечный вопрос повис в воздухе - сложный, но эффективный синтактсис против однородного АСТ-подобного кода на CommonLisp-диалекте. Относительно производительности такого кода в будущем думаю волноваться не стоит, т.к. дело лишь в архитектуре - достаточно построить лисп-машину и думаю скорость выполнения и старта таких программ существенно возрастет. Что касается проверки типов на этапе сборки тут нужно смотреть в чем кардинально отличается парадигма коры и жвм, фшарпа и кложи.