Person + Container
Go is departure—movement away from current location toward elsewhere. Unlike "come" which moves toward observer, "go" moves away from reference point. The directionality matters for API design: outbound requests go to external services, responses come back. Go implies intention—the destination may be unknown but direction is deliberate. Navigation systems use go for forward movement, whether the route is known or exploratory. The critical property of go is leaving the current state. Whatever comes next happens after departure. Go commits to transition even when destination is uncertain.
Go emphasizes leaving rather than arriving. The focus is on exit from current state, not entry to next state. This makes go appropriate for transitions where destination is distant or uncertain.
Exit operations similarly emphasize departure. Logout goes away from authenticated state. Unsubscribe goes away from mailing list. Cancel goes away from pending operation. The key is leaving, not where you land after leaving.
Design clarity requires distinguishing departure-focused operations from arrival-focused operations. Go/leave operations need confirmation that departure occurred. Come/enter operations need confirmation of successful arrival. The verification point differs based on directional emphasis.
Saying "go" implies commitment to departure. Once gone, returning requires separate action. Go is not tentative exploration but definite movement away.
Commit operations show this irreversible quality. Database commits finalize transactions—going from pending to permanent state. Deploy operations commit code to production—going from development to live state. The commitment means cannot simply undo; reversal requires deliberate counter-operation.
Distinguishing reversible exploration from irreversible commitment helps users understand operation permanence. Browse operations are reversible. Purchase operations commit. The interface should signal which type of go is occurring.
You can go without knowing exact destination. Go west, go forward, go until something interesting appears. The direction is clear even when endpoint is unknown.
Exploratory searches follow this pattern. Browse without specific target. Navigate until interesting content appears. The going itself is purposeful even without predetermined destination.
Systems supporting open-ended exploration need different patterns than goal-directed navigation. Goal-directed provides shortest path to known destination. Exploration provides interesting paths through unknown territory. The go-without-knowing pattern enables discovery.
Multiple entities can go simultaneously from different starting points. The departures are independent. Each goes according to own schedule and route.
Distributed systems have concurrent departures. Multiple clients make requests simultaneously. Each request goes to service independently. The service handles concurrent arrivals from different concurrent departures.
Managing concurrency requires handling independent go operations that may interact. Race conditions occur when concurrent operations affect shared state. Coordination mechanisms—locks, queues, transactions—sequence or isolate concurrent departures.
Some go operations pass thresholds after which they cannot be cancelled. The commitment becomes irreversible partway through going.
Two-phase commit demonstrates this pattern. Prepare phase is reversible—can abort. Commit phase passes point of no return—must complete. The threshold between phases determines when operation becomes irreversible.
Identifying points of no return helps users understand when they can safely cancel. Before threshold, cancellation is clean. After threshold, cancellation is impossible or requires cleanup. Clear signaling prevents users attempting to cancel irrevocable operations.
Network protocols often use GO as connection initiation. HTTP GET goes to resource. DNS queries go to nameserver. The go starts the protocol exchange.
Request-response patterns depend on go for initiation. Client goes to server with request. Server processes and responds. The go begins the interaction cycle. Without initial go, no exchange occurs.
Protocol design requires deciding who initiates. Client-initiated protocols wait for client go. Server-initiated protocols push without client request. The initiation pattern affects protocol characteristics—latency, complexity, resource usage.
One departure can trigger others. Service A goes offline, causing dependent service B to go into degraded mode, causing client applications to go into error state.
Cascade failures follow departure chain. Initial failure departs from normal operation. Dependent systems detect abnormality and depart from normal operation themselves. The cascade propagates through dependency graph.
Preventing cascades requires isolation. Circuit breakers prevent dependent systems from going into failure when dependencies go offline. Graceful degradation allows partial operation when full operation is unavailable. The isolation contains departures rather than allowing unchecked propagation.
Some go operations happen on schedule. Batch jobs go at midnight. Deployments go on release dates. Scheduled departures are planned, not responsive to immediate triggers.
Cron jobs exemplify scheduled going. They depart from idle state and execute according to schedule. The schedule determines when going happens, independent of other system activity.
Scheduling coordination matters when multiple scheduled departures interact. Database backup go operations should not coincide with high-traffic periods. Deployment go operations should not overlap with other critical changes. The schedule should prevent harmful concurrent departures.
Going can prioritize speed or safety. Fast going accepts risks for quick departure. Safe going verifies conditions before departing.
Deployment strategies show this trade-off. Blue-green deployment goes safely—verify new version before switching traffic. Canary deployment goes carefully—test with small percentage before full rollout. Direct deployment goes fast—push changes immediately.
The appropriate strategy depends on failure cost and recovery time. Critical systems justify safe going. Non-critical systems can go fast. The risk tolerance determines how carefully the go operation proceeds.
Every go operation needs exit path—the route out of current state. Blocked exit paths prevent departure even when go is triggered.
Deadlocks block go operations. Processes cannot go forward because required resources are unavailable. The go request exists but cannot execute. The blocked state persists until resources become available or operation times out.
Ensuring viable exit paths prevents stuck states. Resource management must guarantee progress. Timeout mechanisms force go operations to complete or fail rather than blocking indefinitely. The exit path engineering prevents hung departures.