Exercise 3: Why Java Cold Starts More Than Go, and How SnapStart Helps — Possible Solution
====================================================================

A cold start's own real duration comes largely from how much work is
needed to get a language's own runtime ready to execute code, on top
of Lambda's own environment provisioning.

Go compiles directly to a native static binary -- there is no
separate virtual machine or runtime that needs to start up first; the
compiled binary itself is essentially ready to run the moment the
execution environment exists, keeping real startup overhead minimal.

Java, by contrast, runs inside a JVM (Java Virtual Machine), which
must itself be started, class files loaded, and various runtime
initialization completed before the actual function code can begin
executing -- real, additional work that a natively-compiled language
like Go simply doesn't need to do at all. This extra initialization
is exactly why Java functions tend to show longer, more noticeable
cold starts.

SnapStart addresses this directly: rather than repeating this full
JVM initialization from scratch on every cold start, it resumes
execution from a pre-initialized snapshot taken after that
initialization has already happened once -- skipping the repeated,
expensive startup work on each new cold invocation.

ANSWER: Java suffers more from cold starts than Go because it must
initialize a full JVM runtime before running any function code, while
Go's natively compiled binary needs no such separate runtime startup
at all. SnapStart specifically reduces this gap for Java by resuming
from an already-initialized snapshot instead of repeating the JVM's
own full startup process on every cold start.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly locates the root cause of the cold-start difference in
each language's own real runtime architecture (compiled binary vs. VM
initialization), rather than treating it as an unexplained fact about
"Java being slower," and explains SnapStart's own real mechanism
(resuming from a snapshot) rather than just naming it as a fix.