I wasn't thinking about high language per se. but more from an engine point
of view, specifically use of "Goroutines"
"But, most of the modern programming languages(like Java, Python etc.) are from
the ’90s single threaded environment. Most of those programming languages
supports multi-threading. But the real problem comes with concurrent execution,
threading-locking, race conditions and deadlocks. Those things make it hard to
create a multi-threading application on those languages.
{snip]
On the other hand, Go was released in 2009 when multi-core processors were
already available. That’s why Go is built with keeping concurrency in mind. Go
has goroutines instead of threads. They consume almost 2KB memory from the
heap. So, you can spin millions of goroutines at any time.
How Goroutines work? Reffrance:
http://golangtutorials.blogspot.in/2011/06/goroutines.html
Other benefits are :
Goroutines have growable segmented stacks. That means they will use more
memory only when needed.
Goroutines have a faster startup time than threads.
Goroutines come with built-in primitives to communicate safely between
themselves (channels).
Goroutines allow you to avoid having to resort to mutex locking when
sharing data structures.
Also, goroutines and OS threads do not have 1:1 mapping. A single goroutine
can run on multiple threads. Goroutines are multiplexed into small number of OS
threads.
=========
And from the reference a "Goroutine" may be not language specific and maybe (I
don't know much about the engine) I am dreaming about the rabbit in the moon,
but, for Mark's "idea machine" there is this:
" Effectively for us goroutines hides many of the internal machine complexities
in achieving parallelism. This also means that the language designers could
implement changes to how goroutines scale on the machine taking advantage of
hardware and CPU improvements."
Brahmanathaswami
On 6/10/18, 5:01 AM, "use-livecode on behalf of Tom Glod via use-livecode"
<use-livecode-boun...@lists.runrev.com on behalf of
use-livecode@lists.runrev.com> wrote:
LC and Go have entirely different target markets....but since you can
easily make 1 application talk to another application using sockets .....
or open process...... the LC and Go make a wonderful partnership if you
need to build UI ...but also do High Performance Computing.
The 2 can make a great couple indeed. But neither can replace the other.
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
