在朱莉娅平行。 function和限制
在他们的arXiv论文中 ，朱莉娅的原作者提到了以下内容：
2.14 Parallelism。 并行执行由标准库中的Julia实现的基于消息的多处理系统提供。 语言devise通过提供对称协程来支持这样的库的实现，对称协程也可以被认为是协作调度的线程。 此function允许在库中隐藏asynchronous通信，而不需要用户设置callback。 Julia目前不支持本地线程，这是一个限制，但是具有避免同步使用共享内存的复杂性的优点。
这是什么意思，说朱莉娅不支持本地线程 ？ 什么是本地线程？
其他解释型语言如Python或R是否支持这种并行性？ 朱莉娅独自一人在这？
“本地线程”是独立的执行上下文，由操作系统内核pipe理，访问共享内存空间，并可能在不同的内核上同时执行。 将其与单独的进程进行比较，这些进程可以在多个核上同时执行，但具有单独的内存空间。 确保进程交互很好很容易，因为它们只能通过内核相互通信。 确保线程不以不可预知的错误方式进行交互是非常困难的，因为它们可以以不受限制的方式读取和写入同一个内存。
R的情况相当简单： R不是multithreading的 。 Python有点复杂：Python确实支持线程化，但是由于全局解释器locking（GIL） ，Python代码的实际并发执行是不可能的。 其他stream行的开源dynamic语言在本地线程方面处于各种混合状态（Ruby： no / kinda / yes ？; Node.js： no ），但是总的来说，答案是否定的，它们不支持完全并行的本地线程，所以朱莉娅并不孤单。
当我们向Julia添加共享内存并行性时， 就像我们计划的那样 – 不pipe是使用本地线程还是使用共享内存的多进程 – 都将是真正的并发性，并且不会有GIL阻止同时执行Julia代码。 然而，这是一个非常棘手的function添加到一种语言，正如其他非常stream行的，成熟的dynamic语言不存在或有限的支持certificate。 添加一个共享内存并发模型在技术上是困难的，但真正的问题是devise一个编程模型，这将允许程序员以有效的方式高效地使用硬件并发。 这个问题一般没有解决，是一个非常活跃的研究和实验领域 – 没有“黄金标准”来复制。 我们可以添加POSIX线程支持，但是这种编程模型一般认为是危险的，难以置信地难以正确有效地使用。 Go有一个很好的并发性故事，但它是为编写高度并发的服务器而devise的，而不是为了同时处理大数据而devise的，因此，简单地复制Go的模型对于Julia来说是个好主意。
