Re: [go-nuts] Re: sharing "go runtime VM" for many go application

I'm was only considering the case where a plugin could access the memory of something it wasn't supposed to. On Tue, 29 Nov 2016, 20:35 Konstantin Khomoutov < flatw...@users.sourceforge.net> wrote: > On Tue, 29 Nov 2016 01:14:40 -0800 (PST) > Dave Cheney wrote: > > > > All the

[go-nuts] Re: sharing "go runtime VM" for many go application

> All the plugins will be sharing the same memory with no control stopping one > from accessing the memory and resources of another. Furthermore you wont' be > able to unload or reload an "application" (plugin). This may not be correct. Assuming that they plugin does not use the unsafe

[go-nuts] Re: sharing "go runtime VM" for many go application

Thanks for you reply -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit

[go-nuts] Re: sharing "go runtime VM" for many go application

Go is not a virtual machine language, it's compiled to native machine code, like a C program. Each Go program does have a runtime package which provides the garbage collector to manage the programs heap, and Go programs do follow a pattern of over allocating with the expectation that the

[go-nuts] Re: sharing "go runtime VM" for many go application

thanks Dave, i am thinking about server less architecture with golang. i feel that "sharing languange runtime/VM" will be next technology than the container/kubernetes era. already aws offering lambda service for serverless architecture. i know that nodejs is running in sandbox mode with event