Go Dynamic Linking: Building a Plugin System

This challenge focuses on implementing dynamic linking in Go, a powerful feature that allows you to load and execute code from shared libraries at runtime. This is incredibly useful for creating extensible applications, plugins, or microservices that can be updated or extended without recompiling the main application.

Problem Description

Your task is to build a simple plugin system for a Go application. The main application will have a core set of functionalities and will be able to load additional functionalities from dynamically linked Go plugins.

What needs to be achieved:

1. Create a Plugin Interface: Define a Go interface that all plugins must implement. This interface will specify the methods that the main application can call on loaded plugins.
2. Develop a Sample Plugin: Create at least one Go program that implements the defined plugin interface and can be compiled into a shared library.
3. Implement Plugin Loading in the Main Application: Write the main Go application that can discover and load these shared library plugins at runtime.
4. Execute Plugin Functionality: The main application should be able to call methods on the loaded plugins to utilize their functionality.

Key Requirements:

• Interface Definition: The plugin interface should be defined in a package that is accessible to both the main application and the plugin projects.
• Plugin Compilation: Plugins must be compilable into shared libraries (.so on Linux/macOS, .dll on Windows).
• Runtime Loading: The main application must be able to load plugins from a specified directory without prior knowledge of their names or existence.
• Plugin Execution: The main application should be able to instantiate and call methods defined in the plugin interface.
• Error Handling: Robust error handling is required for file operations, plugin loading, and method invocation.

Expected Behavior:

The main application, when run, should:

1. Scan a designated directory for .so or .dll files.
2. Attempt to load each found file as a Go plugin.
3. If a file is successfully loaded as a plugin, the application should instantiate the plugin and execute a specific method (e.g., a Name() method to identify the plugin and an Execute() method to perform its action).
4. The output should clearly indicate which plugins were loaded and what actions they performed.

Important Edge Cases:

• Invalid Plugin Files: Handle files that are not valid Go plugins or are corrupted.
• Conflicting Plugin Interfaces: Consider how to handle situations where a plugin might not implement the required interface.
• Plugin Dependencies: While this challenge simplifies it, in a real-world scenario, plugins might have their own dependencies. For this challenge, assume plugins are self-contained or rely only on standard library packages.
• Concurrent Plugin Loading: For this challenge, sequential loading is sufficient.

Examples

Example 1: Simple Plugin

Let's say we have a plugin named greeter that prints "Hello from Greeter!".

• Main Application Output:

  Scanning for plugins in ./plugins...
  Loaded plugin: Greeter
  Greeter says: Hello from Greeter!
  

• Explanation: The main application finds greeter.so (or greeter.dll) in the plugins directory. It successfully loads it, identifies it as "Greeter", and then calls its Execute() method, which prints the greeting.

Example 2: Another Plugin

Imagine a plugin named calculator that adds two numbers.

• Input to Plugin (implicitly via method call): The Execute method of the calculator plugin might be called with arguments like (5, 3).
• Main Application Output:

  Scanning for plugins in ./plugins...
  Loaded plugin: Greeter
  Greeter says: Hello from Greeter!
  Loaded plugin: Calculator
  Calculator result: 8
  

• Explanation: Both greeter.so and calculator.so are found. The application loads both. The calculator plugin, when its Execute method is invoked with implicit arguments, returns the sum of 5 and 3, which is 8.

Example 3: Handling an Invalid File

If a non-plugin file (e.g., notes.txt) exists in the plugin directory.

• Input (presence of notes.txt in ./plugins):
• Main Application Output:

  Scanning for plugins in ./plugins...
  Failed to load plugin ./plugins/notes.txt: not a Go plugin or corrupted.
  Loaded plugin: Greeter
  Greeter says: Hello from Greeter!
  

• Explanation: The application attempts to load notes.txt but fails gracefully, logs the error, and continues to load valid plugins.

Constraints

• Plugins must be compiled as Go shared libraries.
• The main application must be written in Go.
• Plugins will be located in a subdirectory named plugins relative to the main application's executable.
• The number of plugins loaded will not exceed 10 for this challenge.
• Plugin loading and execution should not take longer than 5 seconds.

Notes

• The plugin package in Go's standard library is your primary tool for this challenge.
• Remember that plugins and the main application need to share the plugin interface definition. You might need to create a separate module for this.
• Think about how to pass data or configuration to plugins if their functionality requires it (though for this basic challenge, simple method calls are sufficient).
• You will need to compile your plugins into shared libraries. For example, go build -buildmode=plugin -o greeter.so greeter/main.go.