在stackoverflow上看到一個關於Julia語言特性的討論 ，感覺很有意識，這裏簡單翻譯一下，如果有興趣可以看下原文：
https://stackoverflow.com/questions/28078089/is-julia-dynamically-typed/28096079#28096079。問題的回答者是Julia語言的作者，包括 ：StefanKarpinski 、tholy、Chris Rackauckas
提問者爲：Lyndon White，一位機器學習與自然語言 教授
問題內容如下：
很多博客和手冊都說Julia是動態輸入的。但從我對手冊的閱讀來看，它聽起來更像是用類型推斷靜態輸入的，就像F#。
（1）Julia是用類型推斷靜態輸入的嗎？
（2）它是動態類型的嗎？
（3）假設它是動態類型的，看起來手冊不太可能是錯誤的。
（4）Julia 有沒有涉及類型推斷？
回答內容：
StefanKarpinski ：
蒂姆·霍利的回答是很正確的，但我要詳細說明一下。首先，讓我們定義一些術語——你可能不同意我的定義，但至少你會知道我在說什麼。在我看來，靜態語言和動態語言的主要區別在於：在靜態語言中，表達式有類型；在動態語言中，值有類型。
在靜態語言中，有確定程序中每個表達式類型的規則。表達式的類型決定程序的行爲。不允許爲每個表達式確定一致類型的程序被認爲是不正確的，不會編譯。在存在多態性的情況下，表達式的類型可能不是單一的具體類型：參數多態性可以被認爲是讓同一代碼描述由類型參數索引的整個具體類型算法家族的一種方式；子類型多態性可以被認爲是在靜態語言中引入了有限數量的動態行爲。
另一方面，動態語言沒有將類型分配給表達式的規則：類型是通過數據在程序執行時流經程序的方式隱含的。一般來說，表達式可能會產生任何類型的值。正因爲如此，類型理論家有時將動態語言描述爲“unityped”——也就是說，從靜態的角度來看，“type”本質上是表達式的屬性，動態語言中的所有表達式都具有Any類型。當然，這是將類型的靜態概念（它只對表達式有意義）應用於一種語言，在這種語言中，類型的概念只對值有意義。
Julia完全處於動態陣營中：類型是值的屬性，而不是表達式的屬性。代碼的結果類型取決於執行時值如何流經它；語言不包括在執行表達式之前將類型分配給表達式的任何規則。然而，與許多動態語言不同，Julia有一種相當複雜的語言來討論類型，您可以用類型來註釋表達式。例如，x：：T是一個斷言，表示x是T類型的值；如果爲true，則x：：T計算爲x的值，否則將引發錯誤，表達式不返回值。方法簽名中的類型註釋有稍微不同的含義：而不是斷言現有值的類型，它們指示只有當相應的參數是所指示的類型時，該方法才適用。無論是哪種情況，下面的代碼都可以安全地假設x的值是T類型的。
[旁白：在某些類型爲“漸進”或“可選”的語言中，類型註釋將語言從動態模式切換到靜態模式：沒有類型註釋的方法是動態的；帶有類型註釋的方法是靜態的。在靜態代碼中，有爲所有表達式分配類型的規則，代碼必須滿足這些規則。這不是Julia的工作方式——帶有類型註釋的代碼仍然是動態的，並且與沒有類型註釋的代碼具有相同的語義。]
F#、OCaml或Haskell等語言中的類型推斷是如何確定表達式類型的一部分。如果編譯器無法推斷任何表達式的類型，則說明程序已損壞，無法編譯。這些語言都使用某種形式的Hindley-Milner類型推斷，這是一種非常聰明的方法，可以從代碼的結構中派生表達式的類型，而不必寫出顯式類型（將其與動態語言進行比較，動態語言的類型是通過執行代碼來隱含的）。很多時候根本不需要類型註釋，這與在C++、C語言和Java語言中可能需要的冗長類型聲明相比是非常令人愉快的。然而，這與Julia和Python這樣的動態語言有很大的不同，後者不需要類型註釋，因爲表達式不需要預先確定的類型是完全可以接受的。在Hindley Milner語言中，您可能不必編寫與C++或Java一樣多的類型，但是每個表達式都有編譯器可以計算的預定類型。
Julia的編譯器進行類型推斷，但它有很大的不同：不是每個表達式都有一個可推斷的類型。編譯器分析代碼以嘗試預測表達式的類型，並使用該信息生成更有效的機器代碼。但是，如果它不能確定表達式的類型，那就沒什麼大不了的：編譯器只是使用運行時類型信息發出泛型代碼，這些代碼無論如何都可以工作。在Julia中，類型推斷在很大程度上只是一種優化——不管有沒有類型推斷，代碼的工作方式都是一樣的——但是如果類型推斷成功，它的運行速度會快得多。
