Table of Contents

• Table of Contents

• Goodbye “Core Types”

• Safer Nil-Pointer Handling

• DWARF v5 Debug Info by Default

• testing/synctest is Stable

• Experimental encoding/json/v2

• Tooling Improvements

• Runtime Improvements

• Flight Recorder API

• Platform Updates

• Key Takeaways

• Sources

Let’s walk through the highlights.

Goodbye “Core Types”

Core types were introduced in Go 1.18, where, according to the documentation, “a core type is an abstract construct that was introduced for expediency and to simplify dealing with generic operands”. For example, we have:

• If a type is not a type parameter, its core type is simply its underlying type.

• If the type is a type parameter, its core type exists only if all types in its type set share the same underlying type. In such cases, that common underlying type becomes the core type. Otherwise, no core type exists.

In Go 1.25, the team removed the notion of core types from the spec and instead defined each feature with explicit rules for generics, simplifying the language while keeping everything fully backward-compatible. For example, operations like addition on a generic type are now described directly in terms of type sets, without needing to reference core types.

Safer Nil-Pointer Handling

A bug introduced in Go 1.21 sometimes prevented nil pointer panics from triggering. That’s now fixed. If you dereference a nil, it will reliably panic. Previously, the behavior was:

package main

import (
    "fmt"
    "os"
)

func main() {
    // Try to open a file that doesn't exist.
    // os.Open returns a nil file handle and a non-nil error.
    f, err := os.Open("does-not-exist.txt") // f is nil, err is non-nil
    fmt.Println("err:", err) // Prints the error

    // Buggy behavior explanation:
    // The program uses f.Name() before checking the error.
    // Since f is nil, this call panics at runtime.
    // Older Go versions (1.21–1.24) sometimes let this run,
    fmt.Println("name:", f.Name())
}

In Go 1.21–1.24, a compiler bug sometimes suppressed the panic in the code above and made it look like your program was "fine." In Go 1.25, it will no longer run successfully. With the fixed behavior, we have:

package main

import (
    "fmt"
    "os"
)

func main() {
    // Try to open a file that doesn't exist.
    // os.Open returns a nil file handle and a non-nil error.
    f, err := os.Open("does-not-exist.txt") 
    fmt.Println("err:", err) // Prints an error

    // This now reliably panics, since f is nil and you’re dereferencing it.
    fmt.Println("name:", f.Name())
}

The key difference is that it now throws a panic, making the behavior more predictable.

DWARF v5 Debug Info by Default

DWARF is a standardized format for storing debugging information inside compiled binaries.
Think of it as a map that tells debuggers (like gdb, dlv for Go, or IDEs like VS Code/GoLand) how your compiled program relates back to your source code.

Go 1.25 now uses DWARF v5 for debug information. The result is smaller binaries and faster linking. If you need older tooling compatibility, you can disable it with GOEXPERIMENT=nodwarf5.

# Normal build (DWARF v5 enabled automatically):
go build ./...

# If you have tooling that doesn’t support DWARF v5, you can disable it:
GOEXPERIMENT=nodwarf5 go build ./...

testing/synctest is Stable

Testing concurrent code just got easier. The new testing/synctest package lets you run concurrency tests in a controlled environment where goroutines and time are deterministic.

// Run with: go test
package counter

import (
    "testing"
    "testing/synctest"
)

// Counter is a simple struct holding an integer.
// It has methods to increment the count and retrieve the value.
type Counter struct{ n int }

func (c *Counter) Inc() { c.n++ } // Increase counter by 1
func (c *Counter) N() int { return c.n } // Return the current count

func TestCounter_Inc_Deterministic(t *testing.T) {
    // synctest.New creates a special deterministic test environment ("bubble").
    // Inside this bubble, goroutines are scheduled in a controlled way,
    // so the test result is always predictable (no race conditions).
    st := synctest.New()
    defer st.Done() // Cleanup: always close the test bubble at the end.

    c := &Counter{}
    const workers = 10

    // Start 10 goroutines inside the synctest bubble.
    // Each goroutine calls c.Inc(), incrementing the counter.
    for i := 0; i < workers; i++ {
        st.Go(func() { c.Inc() })
    }

    // Run the bubble until all goroutines are finished.
    // This ensures deterministic completion of the test.
    st.Run()

    // Verify the result: counter should equal number of goroutines (10).
    // If not, fail the test with a clear message.
    if got, want := c.N(), workers; got != want {
        t.Fatalf("got %d, want %d", got, want)
    }
}

With the new testing/synctest, tests ensure a deterministic, flake-free run, so the counter always ends up at 10.

Experimental encoding/json/v2

A brand-new JSON engine is available under the GOEXPERIMENT=jsonv2 flag. It’s faster, more efficient, and includes a streaming-friendly jsontext package. Even better, the old encoding/json can piggyback on the new engine—so you get performance boosts without breaking old code.

Tooling Improvements

• go vet now catches common mistakes like incorrect sync.WaitGroup.Add usage and unsafe host:port handling.

• go doc -http serves documentation locally in your browser.

• go build -asan can detect memory leaks automatically.

These small upgrades add up to a smoother dev workflow.

Runtime Improvements

Go now runs smarter inside containers. On Linux, it automatically detects how many CPUs the container is allowed to use and adjusts itself. There’s also a new experimental garbage collector called greenteagc, which can make memory cleanup up to 40% faster in some cases.

Flight Recorder API

Have you ever wished you could see exactly what your Go application was doing when something went wrong—like when a request suddenly takes 10 seconds instead of 100 milliseconds, or your app mysteriously starts using too much CPU? By the time you notice, it’s usually too late to debug because the issue has already passed. Go’s new FlightRecorder feature solves this by continuously capturing a lightweight runtime trace in memory, allowing your program to snapshot the last few seconds of activity to a file whenever a significant event occurs.

Platform Updates

• macOS 12 (Monterey) is now the minimum supported version.

• Windows/ARM 32-bit support is deprecated and will be removed in Go 1.26.

• RISC-V and Loong64 gained new capabilities like plugin builds and race detection.

Key Takeaways

• Safer by default: no more silent nil pointer bugs, better panic reporting.

• Faster builds & runtime: DWARF v5 debug info, container-aware scheduling, and optional GC improvements.

• Better tooling: smarter go vet, memory-leak detection, local docs.

• Modern JSON: encoding/json/v2 is the future, with huge performance gains.

Go 1.25 brings meaningful improvements across performance, correctness, and developer experience. From smarter CPU usage in containers to reduced garbage collector overhead, from more predictable runtime behavior to new tools like FlightRecorder, this release shows Go’s commitment to staying simple while evolving with modern workloads. If you haven’t tried it yet, now’s the time—upgrade, experiment with the new features, and see how they can make your applications faster, safer, and easier to debug.

Sources

https://go.dev/doc/go1.25

Often times, the values returned by APIs are stored as generic interface{} types. These require explicit typecasting to use them correctly. But without proper type conversion, you risk data loss, unexpected behavior, or even runtime crashes.

In this article, we’ll explore how typecasting works in Go. You’ll learn what it is, how to do it correctly, and why it’s crucial for writing safe and reliable code.

You’ll learn about implicit vs explicit typecasting, common pitfalls to avoid, and how to safely work with dynamic data. We’ll also cover practical examples, including how to handle JSON data and how Go’s new generics feature can simplify type conversions.

Table of Contents:

• Why You Should Care About Typecasting

• What Is Typecasting?

• How to Typecast in Go

• Common Mistakes to Avoid

• A Real-World Example: Where Things Go Wrong

• Advanced: How to Use Generics for Safer Typecasting

• Final Thoughts

• Common Type Conversion Table in Go

• Helpful Packages for Type Conversion

• References

Why You Should Care About Typecasting

I decided to write about this after running into a real issue in a company's codebase. The app was pulling data from a third-party API that returned JSON objects. The values were dynamic and stored as generic interface{} types, but the code was trying to use them directly as int, float64, and string without checking or converting the types properly. This caused silent bugs, unexpected behavior, and even crashes that took hours to trace back.

If you're learning Go – or any language – knowing when and how to typecast can save hours of debugging. So let’s get into it.

What Is Typecasting?

Typecasting (or type conversion) is when you convert one type of variable into another. For example, turning an int into a float, or a string into a number. It’s a simple but essential technique for working with data that doesn’t always come in the type you expect.

There are two main types of typecasting:

• Implicit (automatic): Happens behind the scenes, usually when it’s safe (for example, int to float64 in some languages).

• Explicit (manual): You, the developer, are in charge of the conversion. This is the case in Go.

Why does this matter? Because if you don’t convert types correctly, your program might:

• Lose data (for example, decimals getting cut off).

• Crash unexpectedly.

• Show incorrect results to users.

I share some resources at the end of the article if you’re looking for Go packages that simplify type conversions and reduce boilerplate.

How to Typecast in Go

Go is a statically typed language, and it doesn’t do implicit conversions between different types. If you want to change a type, you have to do it yourself using explicit syntax.

Let’s look at some basic examples:

var a int = 42                     // Declare a variable 'a' of type int and assign the value 42
var b float64 = float64(a)        // Explicitly convert 'a' from int to float64 and store it in 'b'
                                  // Go requires manual (explicit) type conversion between different types

Here, we’re converting an int (a) into a float64 (b). This is a widening conversion – it’s safe because every integer can be represented as a float.

Now the reverse:

var x float64 = 9.8              // Declare a float64 variable 'x' with a decimal value
var y int = int(x)               // Convert 'x' to an int and store it in 'y'
                                 // This removes (truncates) everything after the decimal point
                                 // So y will be 9, not 10 — it doesn't round!

Here, we convert a float64 to an int, which truncates the decimal part. This is a narrowing conversion and can lead to data loss.

Go forces you to be explicit so you don’t accidentally lose information or break your logic.

Common Mistakes to Avoid

When working with dynamic data like JSON or third-party APIs, it's common to use interface{} to represent unknown types. But you can't directly use them as specific types without checking first.

Here's a mistake many beginners make:

var data interface{} = "123"       // 'data' holds a value of type interface{} (a generic type)
value := data.(string)             // This tries to assert that 'data' is a string
                                   // If it's not a string, this will panic and crash the program

If data isn’t actually a string, this will panic at runtime.

A safer version would be:

value, ok := data.(string)         // Try to convert 'data' to string, safely
if !ok {
    fmt.Println("Type assertion failed")  // If the type doesn't match, 'ok' will be false
} else {
    fmt.Println("Value is:", value)       // Only use 'value' if assertion was successful
}

This checks the type before converting and avoids a crash. Always handle the ok case when asserting types from interface{}.

A Real-World Example: Where Things Go Wrong

We will be using a lot of the JSON marshal and unmarshal functions. If you want to understand what these are, here’s a quick introduction or review.

What is Marshaling in Go?

Marshaling refers to the process of converting Go data structures into a JSON representation. This is especially useful when you're preparing data to be sent over the network or saved to a file. The result of marshaling is typically a byte slice containing the JSON string.

Unmarshaling, on the other hand, is the reverse operation. It converts JSON data into Go structures, allowing you to work with external or dynamic data formats in a strongly typed manner.

In typical applications, you might marshal a struct to send data via an API, or unmarshal a JSON payload received from a third-party service.

When using structs, marshalling and unmarshalling are straightforward and benefit from field tags that guide JSON key mapping. But when working with unstructured or unknown JSON formats, you might unmarshal into a map[string]interface{}. In these cases, type assertions become necessary to safely access and manipulate the data.

Understanding how marshalling and unmarshalling work is fundamental when building services that consume or expose APIs, interact with webhooks, or deal with configuration files in JSON format.

Alright, now back to our example:

Let’s say you get a JSON response from an API and unmarshal it into a map:

package main

import (
    "encoding/json"
    "fmt"
)

func main() {
    data := []byte(`{"price": 10.99}`)        // Simulated JSON input

    var result map[string]interface{}         // Use a map to unmarshal the JSON
    json.Unmarshal(data, &result)             // Unmarshal into a generic map

    price := result["price"].(float64)        // Correctly assert that price is a float64
    fmt.Println("The price is:", price)

    total := int(result["price"])             // ❌ This will fail!
}

This fails because result["price"] is of type interface{}. Trying to convert it directly to int causes a compile-time error:

cannot convert result["price"] (map index expression of type interface{}) to type int: need type assertion

You need to assert the type first.

The Right Way to Do It

Here’s the safe and correct version:

package main

import (
    "encoding/json"
    "fmt"
)

func main() {
    data := []byte(`{"price": 10.99}`)        // JSON input representing a float value

    var result map[string]interface{}         // Create a map to hold the parsed JSON
    json.Unmarshal(data, &result)             // Parse the JSON into the map

    // Step 1: Assert that the value is a float64
    priceFloat, ok := result["price"].(float64)
    if !ok {
        fmt.Println("Failed to convert price to float64")
        return
    }

    fmt.Println("Total as float:", priceFloat)  // Successfully extracted float value

    // Step 2: Convert the float to an int (truncates decimals)
    total := int(priceFloat)
    fmt.Println("Total as integer:", total)     // Final integer result (e.g., 10 from 10.99)
}

This works because we first check that the value is a float64 and only then convert it to an int. That two-step process – type assertion then conversion – is key to avoiding errors.

Advanced: How to Use Generics for Safer Typecasting

With the introduction of generics in Go 1.18, you can write reusable functions that work with any type. Generics let you define functions where the type can be specified when the function is called.

What are Generics in Go?

Generics were introduced in Go 1.18 to allow writing functions and data structures that work with any type. They help reduce code duplication and increase type safety by enabling parameterized types.

In the context of typecasting, generics allow you to write flexible helpers (like getValue[T]) that reduce repetitive interface{} assertions and make your code easier to maintain.

• Type parameters are defined with square brackets: [T any]

• The any keyword is an alias for interface{}

• Compile-time checks ensure the past types are used safely

Generics are especially useful in libraries, APIs, and when working with dynamic structures like JSON objects.

Let’s say you want to extract values from map[string]interface{} without writing repetitive assertions:

// A generic function that safely retrieves and type-asserts a value from a map
func getValue[T any](data map[string]interface{}, key string) (T, bool) {
    val, ok := data[key]                  // Check if the key exists in the map
    if !ok {
        var zero T                        // Declare a zero value of type T
        return zero, false                // Return zero value and false if key not found
    }

    converted, ok := val.(T)              // Try to convert (type assert) the value to type T
    return converted, ok                  // Return the result and success status
}

This function:

• Accepts any type T that you specify (like float64, string, and so on)

• Asserts the type for you

• Returns the value and a boolean indicating success

Usage:

price, ok := getValue[float64](result, "price") // Try to get a float64 from the map
if !ok {
    fmt.Println("Price not found or wrong type")
}

title, ok := getValue[string](result, "title")  // Try to get a string from the map
if !ok {
    fmt.Println("Title not found or wrong type")
}

This pattern keeps your code clean and readable while avoiding panics from unsafe assertions.

Final Thoughts

Whether you’re just starting with Go or diving into more advanced patterns like generics, understanding typecasting is key to writing safe and reliable code.

It may seem like a small detail, but incorrect type conversions can cause crashes, bugs, or silent data loss – especially when working with JSON, APIs, or user input.

Here’s what you should take away:

• 🧠 Always know the type you’re working with.

• 🔍 Use type assertions carefully and check the ok value.

• 🧰 Use generics to simplify repetitive assertion logic.

• 💡 Don’t rely on luck — be intentional with conversions.

Mastering typecasting in Go will not only make you a better developer but also help you understand how typed systems work across different languages.

Common Type Conversion Table in Go

Helpful Packages for Type Conversion

• strconv: Converting strings to numbers and vice versa

• reflect: Introspect types at runtime (use with caution)

• encoding/json: Automatic type mapping when unmarshaling

• fmt: Quick conversion to string with formatting

References

• https://go.dev/doc/effective_go

• https://go.dev/doc/tutorial/generics

• https://gosolve.io/golang-cast-go-type-casting-and-type-conversion/

Let me start by asking you a question: How would you test the performance of a piece of code or a function in Go? Well, you could use benchmark tests.

In this tutorial, I will show you how to use an awesome benchmarking tool that’s built into the Golang testing package.

Let’s go.

What Are Benchmark Tests?

In Go, benchmark tests are used to measure the performance (speed and memory usage) of functions or blocks of code. These tests are part of the Go testing framework and are written in the same files as unit tests, but they are specifically for performance analysis.

Example Use Case: Fibonacci Sequence

For this example, I'll be using the classic Fibonacci Sequence, which is determined by:

if (x < 2) 
   F(0) = 1
   F(2) = 2
else 
   F(x) = F(x-1) + F(x-2)

In practice, the sequence is:
1, 1, 2, 3, 5, 8, 13, etc.

This sequence is important because it appears in various parts of mathematics and nature as well, as shown below:

There are several ways to implement this code, and I'll be picking two of them for our benchmark testing: the recursive and iterative methods. The main objective of the functions is to provide a position and return the Fibonacci number at that position.

Recursive Method

// main.go
func fibRecursive(n uint) uint {
    if n <= 2 {
        return 1
    }
    return fibRecursive(n-1) + fibRecursive(n-2)
}

The function above is a recursive implementation of calculating the Fibonacci sequence. Now I’ll break it down step by step for you as a beginner in Go.

Here’s your function for calculating the Fibonacci numbers:

func fibRecursive(n uint) uint {
    if n <= 2 {
        return 1
    }
    return fibRecursive(n-1) + fibRecursive(n-2)
}

1. Function:

func fibRecursive(n uint) uint

• func: This keyword defines a function in Go.

• fibRecursive: This is the name of the function. It’s called fibRecursive because it calculates Fibonacci numbers using recursion.

• n uint: The function takes a single argument, n, which is of type uint (an unsigned integer). This represents the position of the Fibonacci sequence that we want to calculate.

• uint: The function returns a uint (unsigned integer) because Fibonacci numbers are non-negative integers.

2. Base Stage:

if n <= 2 {
    return 1
}

• The if statement checks if n is less than or equal to 2.

• In the Fibonacci sequence, the 1st and 2nd numbers are both 1. So, if n is 1 or 2, the function returns 1.

• This is called the base stage, and it stops the recursion from going infinitely deep.

3. Recursive Stage:

return fibRecursive(n-1) + fibRecursive(n-2)

• If n is greater than 2, the function calls itself twice:

  • fibRecursive(n-1): This will calculate the Fibonacci number for the position just before n.

  • fibRecursive(n-2): This will calculate the Fibonacci number for two positions before n.

• The function then adds these two results together, because every Fibonacci number is the sum of the two preceding numbers.

For more theory on recursion, check out these articles.

Iterative Method

// main.go

func fibIterative(position uint) uint {
    slc := make([]uint, position)
    slc[0] = 1
    slc[1] = 1

    if position <= 2 {
        return 1
    }

    var result, i uint
    for i = 2; i < position; i++ {
        result = slc[i-1] + slc[i-2]
        slc[i] = result
    }

    return result
}

This code implements an iterative approach to calculate the Fibonacci sequence in Go, which is different from the recursive approach. Here’s a breakdown of how it works:

1. Function:

func fibIterative(position uint) uint

• func: This keyword declares a function in Go.

• fibIterative: The name of the function suggests that it calculates Fibonacci numbers using iteration (a loop).

• position uint: The function takes one argument, position, which is an unsigned integer (uint). This represents the position of the Fibonacci sequence you want to calculate.

• uint: The function returns an unsigned integer (uint), which will be the Fibonacci number at the specified position.

2. Creating a Slice (Array-like structure):

slc := make([]uint, position)

• slc is a slice (a dynamic array in Go) that is created with the length of position. This slice will store Fibonacci numbers at each index.

3. Initial Values for Fibonacci Sequence:

slc[0] = 1
slc[1] = 1

• The first two Fibonacci numbers are both 1, so the first two positions in the slice (slc[0] and slc[1]) are set to 1.

4. Early Return for Small Positions:

if position <= 2 {
    return 1
}

• If the input position is 1 or 2, the function directly returns 1, because the first two Fibonacci numbers are always 1.

5. Iterative Loop:

var result, i uint
for i = 2; i < position; i++ {
    result = slc[i-1] + slc[i-2]
    slc[i] = result
}

• The loop starts from i = 2 and runs until it reaches the position.

• In each iteration, the Fibonacci number at index i is calculated as the sum of the two previous Fibonacci numbers (slc[i-1] and slc[i-2]).

• The result is stored both in result and in the slice slc[i] for future calculations.

6. Returning the Result:

return result

• Once the loop finishes, the variable result holds the Fibonacci number at the desired position, and the function returns it.

This is a more efficient approach to calculating Fibonacci numbers compared to recursion, especially when position is large, because it doesn’t repeat unnecessary calculations and we are proving by using benchmark tests. Let’s prove it.

How to Run the Benchmark Tests

Now, for the benchmark tests, let’s write some test. First, you will need to create a maintest.go file. In it, using Golang's documentation on benchmark tests, you can create the functions to be tested as follows:

// main_test.go

// Benchmark for Iterative Function
func BenchmarkFibIterative(b *testing.B) {
    for i := 0; i < b.N; i++ { 
        fibIterative(uint(10))
    }
}
// Benchmark for Recursive Function
func BenchmarkFibRecursive(b *testing.B) {
    for i := 0; i < b.N; i++ {
        fibRecursive(uint(10))
    }
}

Let's run the test for position 10 and then increase appropriately. To run the benchmark tests, you simply run the command go test -bench=NameoftheFunction.

If you want to know more about this command, check here. Let’s check the function for position 10:

func BenchmarkFibIterative(b *testing.B) {
    for i := 0; i < b.N; i++ { 
        fibIterative(uint(10))
    }
}

go test -bench=BenchmarkFibIterative
Results:
cpu: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
BenchmarkFibIterative-8         27715262                42.86 ns/op
PASS
ok      playground      2.617s

Let’s analyze with the help of this image:

According to the image, we have 8 cores for the tests, and no time limit (it will run until completion). It took 27_715_262 iterations and 1.651 seconds to complete the task.

func BenchmarkFibRecursive(b *testing.B) {
    for i := 0; i < b.N; i++ {
        fibRecursive(uint(10))
    }
}

go test -bench=BenchmarkFibRecursive
Results:
cpu: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
BenchmarkFibRecursive-8          6644950               174.3 ns/op
PASS
ok      playground      1.819s

Using the same image to analyze the result, in this case it took 6_644_950 iterations and 1.819 seconds to complete the task we have:

The benchmark results show that the iterative approach is significantly more efficient than the recursive approach for calculating the Fibonacci sequence.

For position 10, the iterative function ran approximately 27.7 million iterations in 1.651 seconds, while the recursive function managed only 6.6 million iterations in 1.819 seconds. The iterative method outperformed the recursive method both in terms of iterations and time, highlighting its efficiency.

To proven even further this, let’s try with the position 40 (4 times the previous value):

// Results for the Iterative Function
cpu: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
BenchmarkFibIterative-8          9904401               114.5 ns/op
PASS
ok      playground      1.741s

// Results for the Recursive Function
cpu: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
BenchmarkFibRecursive-8                4         324133575 ns/op
PASS
ok      playground      3.782s

The benchmark results clearly highlight the efficiency difference between the iterative and recursive approaches for calculating Fibonacci again.

The iterative function completed approximately 9.9 million iterations with an average execution time of 114.5 nanoseconds per operation, finishing the benchmark in 1.741 seconds. In stark contrast, the recursive function only completed 4 iterations with an average execution time of 324,133,575 nanoseconds per operation (over 324 milliseconds per call), taking 3.782 seconds to finish.

These results demonstrate that the recursive approach is far less efficient due to repeated function calls and recalculations, making the iterative method vastly superior in both speed and resource usage, especially as input size increases.

Just out of curiosity, I tried position 60 and it literally crashed the test:

// Results for the Iterative Function
cpu: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
BenchmarkFibIterative-8          7100899               160.9 ns/op

// Results for the Recursive Function
SIGQUIT: quit
PC=0x7ff81935f08e m=0 sigcode=0

goroutine 0 gp=0x3bf1800 m=0 mp=0x3bf26a0 [idle]:
runtime.pthread_cond_wait(0x3bf2be0, 0x3bf2ba0)
...

Conclusion

If your production code is running slowly or is unpredictably slower, you can use this technique, combined with pprof or other tools from the built-in testing package, to identify and test where your code is performing poorly and work on how to optimize it.

Remember: Code that is beautiful to the eyes is not necessarily more performant.

Reference

• Recursive & Iterative functions to Fibonacci’s sequence here.

• Benchmark testing here.

Homework

This article explains why for some small numbers, the recursive strategy is better. Can you find a better way to improve the recursive function? (Tip: use Dynamic Programming).