print is typically just outputting a string to the console. In most cases this is StdOut aka the console. The information printed is controlled by the application and there is little or no filtering.

loging is similar to print except there is some formatting like a timestamp, PID, and logging level (error, warning, tracce, etc). Logging is also sent to StdErr instead of StdOut. Many logging libraries allow the application to filter the logging levels at startup so that development might have full logging and production might have limited logging.

myapp 2>&1 >/var/log/mylog

One issue with log filtering is that the filtering itself can effect the performance of the app. Also when debugging production issues (debugging prod usually looks a lot like dev debugging)… filtering the logs limits the debugging context. It’s also going to have varying effects on performance like certain messages are still executed robbing performance but not actually rendered. This has the inverse effect too.

myapp 2>/dev/null >/var/log/mylog

One side effect of loging is that if the logs are captured by systemd or multilog they are then nested with timestamps. This makes the parsing of the logs even more difficult. Frankly logging with timestamps is sort of meaningless in that when debugging typical apps (non-long running) it’s the sequential order of operations not the timestamp. And in long running tests they tend to model production or you can redirect the output to multilog.

So the answer, going forward, use print/StdOut for printing application response stuff and print/StdErr for logging.