To supplement the points raised by others, I never assume that someone asking
me about "concurrency" understands the following:
https://blog.golang.org/concurrency-is-not-parallelism
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Thanks. Good answer.
kilon.alios wrote
> It all comes down to what you mean by "efficient". Obviously if you want
> top performance on multiple cores you dont use any of those languages
> including Pharo. Thats prettty much the sole reason why C++ is still a
> relevant language.
>
> Now if you w
It all comes down to what you mean by "efficient". Obviously if you want
top performance on multiple cores you dont use any of those languages
including Pharo. Thats prettty much the sole reason why C++ is still a
relevant language.
Now if you want ok performance you could use those languages.
Ho
On 23-10-17 16:16, horrido wrote:
Yes, but isn't there an important class of concurrent software where
lightweight threads work on shared state? Isn't that the reason for
"goroutines" in Go, and STM in Clojure, and actors in Scala?
There are lots of different concurrency and performance problem
That's the GemStone model. It works well for our customers.
On Oct 23, 2017 07:03, "stephan" wrote:
> On 23-10-17 15:27, horrido wrote:
>
>> Do I just say that if you need concurrency, Pharo is the wrong choice?
>> After
>> all, no programming language can be good at everything. You must always
Yes, but isn't there an important class of concurrent software where
lightweight threads work on shared state? Isn't that the reason for
"goroutines" in Go, and STM in Clojure, and actors in Scala?
Stephan Eggermont-3 wrote
> On 23-10-17 15:27, horrido wrote:
>> Do I just say that if you need co
On 23-10-17 15:27, horrido wrote:
Do I just say that if you need concurrency, Pharo is the wrong choice? After
all, no programming language can be good at everything. You must always
choose the right tool for the job.
No, you tell them to use many images and/or vms. We can effectively use
stat
