📖 Scenario: Imagine you are building a simple messaging system where one part of your program sends messages and another part receives them. You want to understand how Go channels can block your program until the message is received.
🎯 Goal: You will create a Go program that uses a channel to send and receive a message. You will see how sending and receiving on a channel can block the program until the other side is ready.
📋 What You'll Learn
Create a channel of type string called messages
Send a message "Hello, Go!" into the messages channel
Receive the message from the messages channel into a variable called msg
Print the received message using fmt.Println
💡 Why This Matters
🌍 Real World
Channels are used in Go to communicate safely between different parts of a program running at the same time, like workers sending tasks or results.
💼 Career
Understanding blocking behavior with channels is essential for writing efficient and correct concurrent programs in Go, a skill valued in backend development and systems programming.
Progress0 / 4 steps
1
Create a channel called messages
Create a channel called messages that can hold string values using make(chan string).
Go
Hint
Use make(chan string) to create a channel for strings.
2
Send a message into the messages channel
Send the string "Hello, Go!" into the messages channel using messages <- "Hello, Go!".
Go
Hint
Sending on a channel blocks unless there is a receiver. Use a goroutine to send the message.
3
Receive the message from the messages channel
Receive the message from the messages channel into a variable called msg using msg := <-messages.
Go
Hint
Receiving from a channel blocks until a message is sent. Use msg := <-messages.
4
Print the received message
Print the variable msg using fmt.Println(msg) to display the received message.
Go
Hint
Use fmt.Println(msg) to print the message.
Practice
(1/5)
1. What does blocking mean in Go programming?
easy
A. Running multiple tasks at the same time
B. Waiting for an operation to finish before moving on
C. Ignoring errors in the program
D. Skipping a function call
Solution
Step 1: Understand the meaning of blocking
Blocking means the program waits for something to finish before continuing.
Step 2: Match the definition to options
Waiting for an operation to finish before moving on correctly describes waiting for an operation to finish before moving on.
Final Answer:
Waiting for an operation to finish before moving on -> Option B
Quick Check:
Blocking = Waiting [OK]
Hint: Blocking means waiting, not running or skipping [OK]
Common Mistakes:
Confusing blocking with concurrency
Thinking blocking means ignoring errors
Assuming blocking skips code
2. Which of the following Go code snippets correctly shows a blocking receive on a channel?
easy
A. value := <-ch
B. go func() { <-ch }()
C. ch <- value
D. select { case ch <- value: }
Solution
Step 1: Identify blocking receive syntax
Receiving from a channel blocks until a value is available, done by value := <-ch.
Step 2: Check other options
go func() { <-ch }() launches a goroutine, so receive is not blocking main code. ch <- value sends, not receives. select { case ch <- value: } sends in select, not receive.
Final Answer:
value := <-ch -> Option A
Quick Check:
Blocking receive = value := <-ch [OK]
Hint: Blocking receive uses '<-ch' without goroutine [OK]
Common Mistakes:
Confusing send and receive syntax
Thinking goroutine makes receive blocking
Using select for receive incorrectly
3. What will be the output of this Go program?
package main
import "fmt"
func main() {
ch := make(chan int)
go func() {
ch <- 42
}()
fmt.Println(<-ch)
}
medium
A. 42
B. 0
C. Compilation error
D. Deadlock runtime error
Solution
Step 1: Analyze channel creation and goroutine
A channel ch is created and a goroutine sends 42 into it.
Step 2: Understand blocking receive
Main goroutine waits on <-ch until value 42 is sent, then prints it.
Final Answer:
42 -> Option A
Quick Check:
Send and receive synchronize, output = 42 [OK]
Hint: Send in goroutine, receive blocks until value arrives [OK]
Common Mistakes:
Expecting deadlock without goroutine
Thinking channel defaults to zero value
Confusing send and receive order
4. Identify the problem in this Go code and fix it:
package main
func main() {
ch := make(chan int)
ch <- 10
val := <-ch
println(val)
}
medium
A. Compilation error due to missing import; fix by adding fmt package
B. Runtime panic due to nil channel; fix by initializing channel
C. No problem; code runs and prints 10
D. Deadlock because send blocks without receiver; fix by using a goroutine for send
Solution
Step 1: Understand channel blocking behavior
Sending on an unbuffered channel blocks until a receiver is ready.
Step 2: Analyze code flow
Send happens before receive, but no goroutine to receive yet, causing deadlock.
Step 3: Fix by sending in a goroutine
Wrap send in go func() { ch <- 10 }() to allow receive to proceed.
Final Answer:
Deadlock because send blocks without receiver; fix by using a goroutine for send -> Option D
Quick Check:
Send blocks without receiver = deadlock [OK]
Hint: Send blocks if no receiver; use goroutine to avoid deadlock [OK]
Common Mistakes:
Ignoring deadlock and expecting output
Adding imports unnecessarily
Thinking channel is nil
5. You want to receive from two channels ch1 and ch2 but only proceed when both have sent a value. Which approach correctly uses blocking behavior to achieve this?
hard
A. Use a buffered channel to store values from both channels
B. Use a select statement with both channels in one case
C. Receive from ch1 and ch2 sequentially: val1 := <-ch1; val2 := <-ch2
D. Receive from only one channel and ignore the other
Solution
Step 1: Understand blocking on multiple channels
Receiving sequentially from both channels blocks until each sends a value.
Step 2: Evaluate options
Select cannot wait for both simultaneously in one case. Ignoring one channel misses data. Buffered channel does not guarantee both received.
Final Answer:
Receive from ch1 and ch2 sequentially: val1 := <-ch1; val2 := <-ch2 -> Option C
Quick Check:
Sequential receive blocks until both values arrive [OK]
Hint: Receive from each channel one by one to wait for both [OK]
Common Mistakes:
Using select to wait for both at once
Ignoring one channel's value
Assuming buffered channel solves blocking
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.