Co-founder of Wordpress would rewrite it today in Go

[Martin Angers]

Title says it all, but thought it would be nice to share on this mailing list.

http://www.reddit.com/r/IAmA/comments/1jg781/i_am_matt_mullenweg_cofounder_of_wordpress_18_of/cbed1jk

[Jesse McNelis]

On Fri, Aug 2, 2013 at 11:41 AM, Martin Angers <martin....@gmail.com> wrote:

Title says it all, but thought it would be nice to share on this mailing list.

http://www.reddit.com/r/IAmA/comments/1jg781/i_am_matt_mullenweg_cofounder_of_wordpress_18_of/cbed1jk

Anyone that has started anything in PHP is always looking to rewrite it.

But, isn't one of the important things about wordpress the ability to have terrible plugins created by terrible programmers?

Go doesn't really support plugins and it's a bit too strict for terrible programmers.

--
=====================
http://jessta.id.au

[Dave Cheney]

I may be putting words in the authors mouth, but being able to distribute an application like Wordpress, and upgrade it, as a single binary image would have to be a factor in this statement. 

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Sean Russell]

On Thursday, August 1, 2013 10:19:39 PM UTC-4, Jesse McNelis wrote:

Go doesn't really support plugins and it's a bit too strict for terrible programmers.

I've been thinking a lot about plugins and Go.  There are a couple of ways to achieve this that might be made easier with a library to help with the gluing.

I think the most interesting one is the most obvious: plug-ins run as their own processes.  In every plugin system, there's a registration mechanism; in this case, the registration would be over a socket.  Something like Skynet could help, but a more focused implementation that is less flexible than Skynet could reduce the function call overhead. It'll be interesting to see how this performs.  A little glue could make using a plug-in framework easier: a service daemon to re/start plugins, a standard capability registration utility library, something like netchan to handle the function calls, etc.

The other common approach, where plugins are part of the application -- they register through some internal API, and you put your plugin in a directory and recompile the whole thing -- works pretty well.  There are cases where it is harder to make work properly (e.g., an IRC bot, where you would like to reload plugins without having to have the bot reconnect after being restarted, or an IDE where it is undesireable to have to restart the entire IDE after installing a new plugin), but it's fine for request servers when you use something like goagain.

You're right in your statement that Go doesn't support plugins; most people think a core aspect of plugins is hot code loading at run time.  The main thing that's stopped me from writing a library is that I believe making a good plugin system is not as trivial as it sounds, and I'd rather collaborate with somebody who's been waist-deep supporting the application-side of a plugin system to know what it needs to support.  Somebody from the Eclipse (or other IDE system), for example; I think those are the most demanding plugin systems.

Sorry for veering off-topic a bit. To circle back around, Wordpress would do fine with a "recompile entire application to get new plugins" model, using goagain to keep the service up.  No magic necessary; just some deep thinking about the plugin API.

--- SER

[Brian Ketelsen]

Skynet (lite) would be perfect for this.  In its next incarnation Skynet will have something like etcd built in to the sky daemons (the watchers and controllers of the cluster).  Each plugin could register with the daemon, and the main Wordpress executable(s) would know they exist because they've registered.  Then they could use standard skynet RPC calls (which are loosely wrapped Go RPC calls encoded in BSON) to call the "plugins".

Makes me think we should extract some of these bits out.

Brian 

[Bruno Albuquerque]

FYI, I wrote this (pretty simple) static module support library that works with the recompilation example you gave. It is definitelly not as powerful as having dynamically loaded modules, but it at least makes it easier for someone to write plugin code for some system.

https://github.com/brunoga/go-modules

For example, I use this on another (incomplete) project: https://github.com/brunoga/go-pipeliner

if you look at the modules/* directories you will see how the "plugins"are written. They are completelly self-contained and can removed (and newer ones can be added) without breakig the program and without any change being necessary anywhere else in the code.

    

--

[wkharold]

Whenever the plugin topic comes up I feel compelled to "plug" the Styx (everything is a file) architecture and direct people to the go9p code (https://code.google.com/p/go9p); per your comment plugins become a separate processes that export a file system interface that a service mounts (publicly or privately) and interacts with using standard file operations. Someday I will do a worked example; for now see https://code.google.com/p/gocpu for an illustration of how someone who knows (far better than I) what they're doing can do with go9p.

[Christian Neumann]

Am 02.08.2013 13:25, schrieb Sean Russell:
> I think the most interesting one is the most obvious: plug-ins run as their
> own processes. In every plugin system, there's a registration mechanism;
> in this case, the registration would be over a socket. Something like

> Skynet <https://github.com/skynetservices/skynet> could help, but a more

> focused implementation that is less flexible than Skynet could reduce the
> function call overhead. It'll be interesting to see how this performs. A
> little glue could make using a plug-in framework easier: a service daemon
> to re/start plugins, a standard capability registration utility library,
> something like netchan to handle the function calls, etc.

The content management system I�m working on (monsti.org) uses an
approach like this to implement plugins. There is a master daemon that
starts other modules/processes which communicate via RPC using a common
API. It's still experimental, but it works so far for me. For security
reasons, I prefer the independent processes solution, especially if you
have to trust unknown plugin code. You could for example run plugins as
a user who only has access to the RPC sockets used for communication and
you could also restrict API access on module level.

Christian

[Sean Russell]

On Friday, August 2, 2013 1:49:10 PM UTC-4, Brian Ketelsen wrote: 

Skynet (lite) would be perfect for this.  In its next incarnation Skynet will have something like etcd built in to the sky daemons (the watchers and

 
Skynet lite?  Where?  When?  What's light about it?

I'd love to have something that can be started from within another application, rather than having to run separate processes. 

Makes me think we should extract some of these bits out.

Agreed.

--- SER

[Brian Ketelsen]

On Friday, August 2, 2013 9:02:15 PM UTC-4, Sean Russell wrote:

On Friday, August 2, 2013 1:49:10 PM UTC-4, Brian Ketelsen wrote: 

Skynet (lite) would be perfect for this.  In its next incarnation Skynet will have something like etcd built in to the sky daemons (the watchers and

 
Skynet lite?  Where?  When?  What's light about it?

It doesn't exist, at least not until we think through extracting and simplifying what Skynet is now.

 

I'd love to have something that can be started from within another application, rather than having to run separate processes. 

Makes me think we should extract some of these bits out.

Agreed.

--- SER

We should probably move this out to https://groups.google.com/forum/#!forum/skynet-dev the Skynet mailing list.

Brian