Implementing Hot Reload in a Go Web Application

Hot reload is a crucial feature for developer productivity, allowing code changes to be reflected in a running application without requiring a full restart. This challenge asks you to implement a basic hot reload mechanism for a simple Go web application, enabling developers to see changes instantly during development. This will significantly speed up the development cycle and improve the overall coding experience.

Problem Description

You are tasked with creating a Go web application that automatically reloads when changes are detected in its source code. The application should serve a simple "Hello, World!" message on the root path ("/"). The hot reload functionality should monitor a specified directory (e.g., the current working directory) for changes to Go files (.go). When a change is detected, the application should gracefully restart itself, ensuring minimal disruption to the user (though a brief flicker is acceptable for this exercise).

Key Requirements:

• File System Monitoring: The application must continuously monitor the specified directory for file modifications.
• Automatic Restart: Upon detecting a change, the application must restart itself. This includes stopping the existing server and starting a new one.
• Simple Web Server: The application should serve a basic "Hello, World!" message on the root path ("/").
• Configuration: The directory to monitor should be configurable (e.g., via a command-line argument or environment variable).
• Graceful Handling: The application should handle errors gracefully, logging any issues encountered during monitoring or restarting.

Expected Behavior:

1. The application starts a web server.
2. The application begins monitoring the configured directory for changes to .go files.
3. When a .go file is modified, the application logs a message indicating a change was detected.
4. The application stops the existing web server.
5. The application restarts the web server, serving the updated code.
6. The application continues to monitor for changes.

Edge Cases to Consider:

• Error Handling: What happens if the file system monitoring fails? What happens if the application fails to restart?
• Large Directories: How does the application perform when monitoring a directory with a large number of files? (Performance is not a primary concern for this exercise, but consider potential bottlenecks).
• File Creation/Deletion: How does the application handle the creation and deletion of files within the monitored directory?
• Concurrency: Ensure the file monitoring and web server operations are handled safely in a concurrent environment.

Examples

Example 1:

Input: Directory to monitor: "." (current directory), File: main.go contains "Hello, World!"
Output: Web server starts, serving "Hello, World!" on /
Explanation: The application starts, monitors the current directory, and serves the initial content.

Example 2:

Input: Directory to monitor: ".", File: main.go modified to contain "Hello, Go!"
Output: Application logs "Change detected!", stops the server, restarts the server, serving "Hello, Go!" on /
Explanation: A change is detected, the server restarts, and the updated content is served.

Example 3: (Edge Case)

Input: Directory to monitor: ".", File: non_go_file.txt modified
Output: No action taken. The application continues to monitor for .go file changes.
Explanation: The application only monitors .go files and ignores other file types.

Constraints

• Directory Size: The monitored directory can contain up to 1000 files.
• File Size: Individual Go files can be up to 1MB in size.
• Restart Time: The restart time should be reasonably quick (under 1 second is preferred, but not strictly required).
• Error Handling: The application must log errors to standard error.
• Dependencies: You are allowed to use standard library packages and the github.com/fsnotify/fsnotify package for file system monitoring. No other external dependencies are permitted.

Notes

• Consider using goroutines to handle file system monitoring and web server operations concurrently.
• The fsnotify package provides a convenient way to monitor file system events.
• Think about how to gracefully stop the existing web server before restarting it. A simple os.Exit(0) is acceptable for this exercise, but more robust shutdown mechanisms are possible.
• Focus on the core functionality of hot reload. Error handling and advanced features (e.g., code compilation) can be simplified for this challenge.
• The "Hello, World!" web server can be implemented using the standard net/http package.