p*****2
发帖数: 21240 | 1
我随便说几点吧。
1. Dynamic， 极高的productivity, 这也是为什么Nathan他们2，3个人可以把一个
Storm做出来
2. 85%的FP，而Scala是50%的FP
3. 自带STM, 而Scala是库
4. Async, 实现了goroutine (学Go的）
5. 不但可以跑在JVM上，还可以跑在node上和browser上，一个语言可以通吃最流行的
几个平台
6. Cascalog跟Hadoop绝配
7. Storm就不用说了，native language
8. Macro, 使得其他语言的meta programming成为了小儿科，更不要说Scala了
9. 比Scala要容易学习很多 |
|
|
N*******t
发帖数: 66 | 3 They are very different: Go is a system language, Dao is an embeddable
scripting language. Dao supports many more features that Go does. Most Go
features are available in Dao (interface, deferred block, panic, goroutine/
tasklet, channel etc.). Go's support for concurrency is more efficient in
some aspects such as passing values through channels. But Dao's support for
concurrency is a bit more user friendly (also quite efficient). |
|
n****1
发帖数: 1136 | 4 没错， actor是object
但我的point是：
只有actor才值得用object的概念来建模. 其他的"object"不过是普通的encapsulated
data struct罢了。
拥有"独立人格"的东西最难建模与分析了，因为数学上是non deterministic, 甚至某
些actor可能等价于一个turing machine. 所以从程序复杂度的角度， 也应该尽量减少
actor的数量。 AKA, 不要抱着万物皆活物的思想写程序。
还有，这个actor和FP一毛钱关系也没有. 你也提醒过我， golang也用类似于actor的
goroutine, 而把thread api废掉了. |
|
n****1
发帖数: 1136 | 5 我提的这个与FP完全无关， 就拿c++做例子， 我希望C++里面的class只有data member
, 没有method member. 这样就可以完全从线程的角度, imperative style来看问题(其
实等价于用了opaque struct的C).
或者像golang这样， 完全隐藏多线程， 只有goroutine, 这样就可以完全从actor的角
度看问题。 同时考虑actor和线程是非常痛苦的。
＠domini
你就这点理解能力么？ 凡是反OO的就是FP么？ 我这帖子啥时候提FP了？
我是说OOP语言里的多线程应该由runtime来实现， 而不该直接把kernel thread api暴
露给程序员， 我啥时候说不用多线程了？
话说我还真认为imperative常常比OO的逻辑更清晰， 没有OO概念，PHP照样流行,c也能
写出整个linux 内核， 而java代码往往是滥用模式，又臭又长。 |
|
z****e
发帖数: 54598 | 6 王垠的结语：
程序语言与政治
很多人都曾经妄想着所谓的“社会主义”和“共产主义”能拯救全人类，就像很多程序
员都妄想着某一种最近流行的语言能够把他们从繁琐的编程工作里拯救出来一样。几十
年前，所谓的“革命者”为了这些很酷很炫的名词，试图把从前的一切文化都焚毁掉。
腐朽的资本主义！吃人的旧社会！这就像现在很多 Scala/Clojure/Go 的狂热分子对
Java 之类的语言充满了敌意，一提到这些语言心里就是火。腐朽的 Java，不思进取的
Lisp，Scala/Clojure/Go 就是你们的掘墓人！然而他们没有发现，那些他们试图完全
抛弃的语言里面其实有科学合理之处。他们没有看到这些东西之所以存在于那些语言里
，是经过了历史的经验教训。这些教训如果不被理解和吸取，当遇到同样的问题，这些
新语言就会一样的堕落掉。
有些程序员妄想着 Clojure 和 Go 所谓的 “纯函数式数据结构”，“transactional
memory”，“goroutine”等酷毙帅呆的新概念能够一劳永逸的解决并发计算的重重困
难，妄想着 Scala 能够让面向对象和函数式编程完美的结合。可是他们没有看到... 阅读全帖 |
|
d*******r
发帖数: 3299 | 7 "
有些程序员妄想着 Clojure 和 Go 所谓的 “纯函数式数据结构”，“transactional
memory”，“goroutine”等酷毙帅呆的新概念能够一劳永逸的解决并发计算的重重困
难，妄想着 Scala 能够让面向对象和函数式编程完美的结合。可是他们没有看到的是
人心的险恶，他们就像那些革命者和红卫兵一样，被别有企图的人利用了。
在经过深入的研究之后，你会发现这些炫名词其实并不能解决并发计算的关键问题。并
行计算之所
以困难，是因为物理决定了信息通道的性质。信息只能是单向的，顺序的通过这些信道
，而信道的通过速率是有限的。不管你用多么炫的新方式让信息通过它，都不会改变这
个事实。
"
上面这个“信息流动”没看懂，求大牛解释 |
|
p*****2
发帖数: 21240 | 8
根据好虫以前的说法，Java并没有实现所有的异步库。所以在你没有异步库的情况下不
能进入event loop，只能上线程。不上线程，event loop就阻塞了。这就跟Clojure实
现了Go的goroutine, channel一个道理。 |
|
p*****2
发帖数: 21240 | 9
跟Scala的AKKA，Clojure，Erlang比怎么样呢？
从我的理解主要是异步自动化了，这个貌似其他语言都没有。goroutine, chann这些东
西到没有明显优势。
异步自动化倒是不错，但是如果只是唯一的优势的话，加上那么多问题，我很难想像为
什么要用它。因为其他语言的异步虽然没有这么方便，但是也不是不能做。 |
|
p*****2
发帖数: 21240 | 10
go对于node的优势是goroutine之间可以很容易的通信。Node进程之间通信比较麻烦。
同个进程容易，但是又不能利用multi core。 |
|
n****1
发帖数: 1136 | 11 golang根本就没有线程api, 没有mutex,没有线程间同步, 完全是后台自动把goroutine
变为多线程.
你说的"多线程思维"指的是啥? |
|
g*****g
发帖数: 34805 | 12 这当然是优势，但如果没有那么多多线程东西要写，这个优势就不明显。我就这意思。
goroutine |
|
c*******0
发帖数: 5247 | 13 go有mutex，而且某些情况下也鼓励使用mutex
goroutine |
|
s******c
发帖数: 1920 | 14 我用golang写过很原始的分布式系统project。几点感受关于golang适合并发的说法：
1, 基本上golang的语言特性比如chan之类的，会引导你从开始就使用event driven的
model，非常自然。
2, goroutine比thread更轻量，轻松做到单机上千的并发。 |
|
n****1
发帖数: 1136 | 15 Thread显然是最简单直观的，只不过是运行效率差罢了，所以go有goroutine，haskell
里有forkIO,都是thread方式的api,callback级别的运行效率。
node要想摆脱callbk的恶名，必须脱胎换骨：把一个promise/future/generator/
whatever的东西彻底标准化，然后deprecate所有带callbk的api，强制放弃维护。否则
江山易改，禀性难移。 |
|
a*****e
发帖数: 1700 | 16 我的原意是比 thread concurrency，因为 goroutine 基本上和 haskell lightweight
thread 的实现是一样的，但是 go 的 GC 在拖后腿。后来意识到你说的可能是 I/O
concurrency，这个最后都是指向 kernel async I/O 的能力，所以我给了一篇paper谈
这个。 |
|
|
|
p*****2
发帖数: 21240 | 19 来自主题: Programming版 - 关于Go 就是goroutine gochannel 这套东西 |
|
w***g
发帖数: 5958 | 20 就是再也不怕goodbug和zhaoce他们鼓吹java和IDE了，啊哈哈！
我就是C++/python/scala/javascript，前后台通吃，没java啥事。其实以后python也
可以不要了。
我现在怀疑actor的并发性能可以和goroutine一拼，网上由一个benchmark但是只给了
latency，没有throughput数据。等我过两天找时间跑一下。 |
|
j********x
发帖数: 2330 | 21 严格说goroutine而不是线程
我没研究过区别
不过以官方术语为准
误。 |
|
p*****2
发帖数: 21240 | 22 goroutine 是share线程的
看来你对go了解还不如我多 |
|
c*******0
发帖数: 5247 | 23 LOL, 你的自我感觉也太好了。
go这种语言，学一周就可以说懂了。但要说到理解和用好，不用是感觉不到的。特别是
Go的concurrency pattern，goroutine和channel只是元语，要在大型系统里面用好要
花功力的。只知道打嘴炮的人，还觉得自己理解深刻，也就是Go能给人这种感觉了 |
|
g*****g
发帖数: 34805 | 24 今天学了学Go，很失望。就是个GC版的C呀。Scala太复杂，Go则太简单。不支持
Generics, Exception, Inheritance. 理论上不影响使用，实际上难以吸引C/C++以外
的程序员改投门第呀。Goroutine, small footprint都是亮点，但对于大多数商业应用
，除了商业逻辑复杂其余部分都很routine的，意义不大。还有，既然要吸引C/C++程序
员，为啥要把变量方法定义弄得很pascal我不理解。
我看这俩要想取代Java，都是没有希望了。相对来说，Go前景还好一点，可以取代一部
分C/C++的系统编程，顺带也抢一点Python的市场。这货可以用来写infrastructure，
不是用来写企业应用的。 |
|
t**r
发帖数: 3428 | 25 语义虽然简单直白，但是有的时候行为并不是那么可测。
还需要时间 |
|
c*******0
发帖数: 5247 | 26 举个例子？除了顺序需要注意一下以外，其他都很直白啊 |
|
|
p*****2
发帖数: 21240 | 28 event 和 thread 就是gochannel和goroutine吧？ |
|
w***g
发帖数: 5958 | 29 goroutine是一种用户态的thread。gochannel跟命令行的管道或者message queue啥的
差不多，用来进行thread通信的。 |
|
p*****2
发帖数: 21240 | 30 其实goroutine channel 并不底层 |
|
|
p*****2
发帖数: 21240 | 32 offline分析 不是太care性能
大牛能谈谈你们的架构吗
我奇怪像go这样的 貌似cpu intensive的任务也不给力 goroutine不能阻塞cpu
所以我觉得web上还是io heavy的占大多数 |
|
p*****2
发帖数: 21240 | 33 goroutine是轻量thread，要配合async使用，可以达到更好的concurrency |
|
p*****2
发帖数: 21240 | 34 真的不夸张，需要操心的事情太多
不过goroutine和channel感觉还是挺爽的
go的语言feature太少，coding上也很难优化了。
就看为了go的并发，值不值得这么累了。
当然，确实go适合团队，coding真的很难有第二种写法，想换种写法总是碰到障碍。 |
|
c****f
发帖数: 1102 | 35 go的pointer只有真正pointer一半功能 其实根本不复杂
interface这个概念纯粹是为了做duck type搞出来的 如果你从oo转过来 就当它是个大
类的method就好了
只有interface需要做type assertion 因为可以接受任何type会导致代码出错
其实go只有几个概念要学
goroutine channel 和interface
其他都和C差不多
看你从什么类型的语言转了 |
|
x*****z
发帖数: 787 | 36 为什么我认为 Python 3 没有前途？
py2 发展了很多年，现在是一个非常成熟的状态。基本上所有的特性都已经被开拓得差
不多了。所以现在 PyPI 上提供的各种库和及命令行工具，IPython、Requests、
gevent、django 等等……基本可以认为是现有 python 语法和虚拟机下能做到的巅峰
水准。
换句话说，在不引入新的语法工具的情况下，python universe 的战斗力不会再有实质
性的提升了。(语法工具的例子比如jit、goroutine、static analysis 等等)
py3 并没有引入新的生产工具，反而人为地破坏了现有生态圈的兼容性，导致了长达数
年的时间 python universe 没有任何的进步。而在 python 停滞的这段时间，很多其
他编程语言也在进化，都没有闲着。
作为胶水语言，python 或许曾经拥有了地球上最强的生产力，但这个地位能维持多久
呢？Ruby 或者 Scala 甚至 CoffeeScript 都具备和 Python 实现一样编程接口的能力
，同时又有自己独到的工具可以实现 Python 做... 阅读全帖 |
|
d****n
发帖数: 1637 | 37 Goroutine stacks
Until 1.2: Stacks were segmented.
1.3: Stacks were contiguous unless executing C code (runtime).
1.4: Stacks made contiguous by restricting C to system stack.
1.5: Stacks made contiguous by eliminating C.
These were each huge steps, made quickly (led by khr@).
http://talks.golang.org/2015/gogo.slide#8
资源最大的被利用了。 |
|
h*i
发帖数: 3446 | 38 作为一个用户，我不管底层是如何实现的，只要我用起来一样就行了。
具体说到实现的话，Clojure好像是把CSP转换成一个finte state machine来实现async
的。从用户角度，这种实现好像也没有什么损害。
好像没有人benchmark过goroutine和core.async两者的效率区别。可能也没有意义，两
个语言的使用场合完全不同。go是底层系统语言，与C/C++啥的竞争，Clojure是高层的
用来写应用的语言，根本不与C/C++的竞争。
async |
|
g*******o
发帖数: 156 | 39 core.async必须要求driver(db or other io) nonblocking。
从程序来看和goroutine是一致了，但是如果你用的driver是blocking的，那效率差了
很多。 |
|
|
g*******o
发帖数: 156 | 41 goroutine所有的driver都是fiber/micro-thread切换，所以从语言层和效率上看都是
async.
core.async如果使用blocking driver，就需要做thread切换，语言层是async，但是效
率远不行（context switch)。
如果说错了请指正阿：） |
|
l**********n
发帖数: 8443 | 42 scala和python都有yield. scala的yield和python的yield有区别吗？ |
|
e***i
发帖数: 231 | 43 scala的yield相当于map或flatmap，产生类型跟从for comprehension的第一个
python的yield给一个generator，类似linkedlist的iterator，不占内存，用到才产生
和读取 |
|
|
d******e
发帖数: 2265 | 45 python的 yield花样很多。
你可以yield n
也可以
n = （yield）
还可以yield from a_list
本质上还是coroutine.
scala的yield不太了解只会用。 |
|
|
p*****2
发帖数: 21240 | 47
scala不是。scala没有yield就是foreach，加了yield就是map，语法糖而已 |
|
l**********n
发帖数: 8443 | 48 how about scala Stream? |
|
|
d******e
发帖数: 2265 | 50 python:
. This object has a __iter__ method which will continue after this yield
statement.
So the call stack gets transformed into a heap object. |
|
