在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中，类型推断在很大程度上只是一种优化——不管有没有类型推断，代码的工作方式都是一样的——但是如果类型推断成功，它的运行速度会快得多。
