Forem: Pedro Bertao

Highlights of Golang 1.25

Pedro Bertao — Fri, 05 Sep 2025 12:23:23 +0000

Go 1.25 isn’t a flashy release with big syntax changes. Instead, it’s a practical one: it fixes long-standing pitfalls, improves runtime safety, adds smarter tooling, and introduces a powerful new JSON engine. These are the kinds of updates that make your day-to-day coding experience smoother and your production apps more reliable.

1. Goodbye “Core Types”

Core types were a formal definition introduced in Go 1.18, where “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.

2. 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 on the code above and made it looked like your program was "fine," but it wasn’t. In Go 1.25, it will no longer run successfully. Now 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

3. 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 ./...`

4. 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.

5. 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.

6. 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.

8. 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.

9. 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.

10. 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

What means to be a Senior Software Engineer focused on Backend

Pedro Bertao — Wed, 16 Jul 2025 15:15:32 +0000

As I keep studying to improve at what I do, I keep asking myself this question and never seem to have a solid answer. Is seniority simply about years of experience? Or is it about expertise, autonomy, and the ability to design and deliver reliable, scalable systems while mentoring and guiding teams? The result was good, though with an interesting twist.

The way I conducted this quick survey was by using a generic prompt across the three most popular AI models at the time of this writing, which I will keep undisclosed. The goal was simply to examine the results and see whether they converge on a similar plan.

Prompt:
What does it mean to be a Senior Software Engineer (focused on backend)? You can discuss years of experience, programming languages they should know, key books, and any other arguments to provide a precise and concise summary.

✍🏼 Results

AI 1 - To be a Senior Backend Software Engineer means possessing a deep, independent expertise in designing, developing, and maintaining robust, scalable, and efficient server-side systems, typically backed by 5+ years of dedicated experience. This involves mastering at least one backend language (e.g., Python, Java, Go, Node.js), coupled with a strong command of databases (SQL/NoSQL), APIs (REST/gRPC), system architecture, distributed systems, and cloud platforms like AWS, Azure, or GCP, alongside proficiency in CI/CD. Beyond coding, it encompasses mentorship, solving complex technical challenges, driving strategic technical decisions, and contributing to the overall architectural vision. Essential reads like "Designing Data-Intensive Applications" and "Clean Code" encapsulate the theoretical and practical knowledge expected, ultimately positioning the senior engineer as a leader who transforms business requirements into reliable, performant, and maintainable backend solutions.

AI 2 - A Senior Software Engineer focused on backend development typically brings 5-8+ years of experience and represents a blend of deep technical expertise and leadership capabilities. They possess mastery of backend languages like Java, Python, Go, or C#, along with comprehensive knowledge of databases (both SQL and NoSQL), system design principles, API development, and cloud platforms such as AWS, Azure, or GCP. Beyond pure coding skills, they demonstrate system thinking by designing scalable and maintainable architectures, understanding distributed systems, microservices patterns, caching strategies, and performance optimization techniques. Their role extends into mentoring junior developers, leading technical decisions, conducting thorough code reviews, and driving architectural choices that impact entire product ecosystems. Essential reading includes "Designing Data-Intensive Applications" by Kleppmann, "System Design Interview" by Xu, and "Clean Architecture" by Martin. Most importantly, senior engineers translate business requirements into robust technical solutions while balancing technical debt against feature delivery, possessing strong debugging skills, DevOps knowledge including CI/CD and containerization, security awareness, and the ability to collaborate effectively across product and design teams to deliver meaningful business impact

AI3 - Being a Senior Software Engineer (backend) means having 5+ years of experience, technical autonomy, system design skills, and focus on delivering value. Strong in languages like Go, Java, or Python, databases (SQL/NoSQL), messaging, and scalable architectures. Familiar with Clean Code, Design Patterns, and DDD. Leads by example, reviews code, proposes robust solutions, anticipates issues, and drives impact with a strong sense of ownership.

Analysis and Thoughts

After reviewing the responses, I consolidated and summarized them into key points, as follows:

🧑🏽‍🏭 Experience

5+ years (typically 5-8+) of backend-focused professional experience

Technical autonomy and independence

📊 Technical Expertise

Mastery of one or more backend languages: Go, Java, Python, Node.js, C#

Deep knowledge of databases (SQL & NoSQL)

API development (REST, gRPC)

Strong understanding of system design, distributed systems, microservices

Familiar with caching strategies, messaging systems, performance optimization

☁️ Architecture & Cloud

Experience with scalable and maintainable architectures

Cloud platforms: AWS, Azure, GCP

Proficient in CI/CD, DevOps, containerization (e.g., Docker, Kubernetes)

👥 Leadership & Mentorship

Mentoring junior engineers

Leading technical decisions and architectural choices

Conducting thorough code reviews

👔 Soft Skills & Business Impact

Ability to translate business requirements into robust technical solutions

Balance technical debt vs. delivery

Collaborate effectively across teams (e.g., product, design)

📚 Essential Knowledge & Books

"Designing Data-Intensive Applications" by Martin Kleppmann

"Clean Code" by Robert C. Martin

"System Design Interview" by Alex Xu

Familiar with Design Patterns, DDD (Domain-Driven Design)

As expected, the responses were very good, and I agree with every single point — especially those related to backend engineering itself, such as cloud and architecture. However, for some reason, none of them mentioned AI as a tool or as part of the requirements. Was this omission intentional, or was my prompt not phrased correctly? I leave this question to you, the reader, and will provide an additional prompt to help explore the role of AI in this context.

▶️ Bonus prompt: What about AI and how it helps the engineer ?

While AI is incredibly powerful, it's crucial to remember that it augments, rather than replaces, the human engineer. Human intuition, creativity, ethical judgment, and the ability to understand nuanced user needs and business context remain irreplaceable. The most effective engineers in the AI era will be those who can leverage these tools effectively to amplify their own capabilities and tackle more challenging and impactful problems.

Golang 1.21 is here (Part 3)

Pedro Bertao — Sun, 08 Oct 2023 12:36:49 +0000

This final part we will be looking at some features of the new slices packages which brings a lot of awesome features.

First we are going to use slices.Compare which is a very useful function when comparing two slices.

        intSliceA := []int{1, 2, 3}
        isEqual := slices.Compare(intSliceA, []int{1, 2, 3})
    if isEqual == 0 {
        fmt.Println("Is Equal")
    } else {
        fmt.Println("Not Equal")
    }
    // Is Equal

    isEqual = slices.Compare(intSliceA, []int{4, 5, 6})
    if isEqual == 0 {
        fmt.Println("Is Equal")
    } else {
        fmt.Println("Not equal")
    }
    // Not Equal

Another great use of slices packages is slices.contains

        intSliceA := []int{1, 2, 3}
    isEqual := slices.Contains(intSliceA, 1)
    if isEqual {
        fmt.Println("Contains")
    } else {
        fmt.Println("Does not Contain")
    }

Finally another interesting function is slices.Max where it locates the max value inside the slice as shown below

    intSliceA := []int{3, 123, 23, 57, 98, 4, 3, 2}

    max := slices.Max(intSliceA)
    fmt.Println("Max:", max)
    // Max:  123

If you wanna to check more of the 1.21 slices package, you can click here

To finish this post I will quote the overview of changelog

The latest Go release, version 1.21, arrives six months after Go 1.20. Most of its changes are in the implementation of the toolchain, runtime, and libraries. As always, the release maintains the Go 1 promise of compatibility; in fact, Go 1.21 improves upon that promise. We expect almost all Go programs to continue to compile and run as before.
Go 1.21 introduces a small change to the numbering of releases. In the past, we used Go 1.N to refer to both the overall Go language version and release family as well as the first release in that family. Starting in Go 1.21, the first release is now Go 1.N.0. Today we are releasing both the Go 1.21 language and its initial implementation, the Go 1.21.0 release. These notes refer to “Go 1.21”; tools like go version will report “go1.21.0” (until you upgrade to Go 1.21.1). See “Go versions” in the “Go Toolchains” documentation for details about the new version numbering.

Go 1.21 brings a lot of features that will makes your code more cleaner and readable. It is must read if you want to use this version for your next projects.

Golang 1.21 is here (Part 2)

Pedro Bertao — Thu, 31 Aug 2023 10:07:07 +0000

In this comprehensive post, I will delve into the intricacies of maps and cmp packages in the context of Go programming. I'll shed light on the standout features that have been intelligently incorporated to enhance your day-to-day experience while developing Go applications. Stay tuned for valuable insights and practical tips!

Maps

    m := map[string]string{
        "name": "Pedro",
        "age":  "20",
    }

    m2 := map[string]string{
        "name": "Pedro",
        "age":  "20",
    }

    m3 := make(map[string]string)

    r := maps.Equal(m, m2)
    r2 := maps.EqualFunc(m, m2, func(s1, s2 string) bool {
        return m["name"] == m2["name"] && m["age"] == m2["age"]
    })

    fmt.Println("Equal: ", r)
    fmt.Println("Equal Func: ", r2)

    cloned := maps.Clone[map[string]string](m)
    maps.Copy[map[string]string](m3, m)

    fmt.Printf("Cloned: %+v: \n", cloned)
    fmt.Printf("Copied: %+v: \n", m3)

In the presented code snippet, we can observe the introduction of some remarkably useful functions for maps. When using copy it generates a shallow clone of the chosen map, when use clone it generates a full copy of the the map. This becomes incredibly advantageous when the aim is to duplicate a map variable while preserving the integrity of the original data.

The result of the previous code is:

Equal:  true
Equal Func:  true
Cloned: map[age:20 name:Pedro] 
Copied: map[age:20 name:Pedro]

You can also check the code here

Cmp

From the documentation, it is simple as:

Package cmp provides types and functions related to comparing ordered values.

It's crucial to grasp that the cmp functions exclusively operate with ordered types constraints, adding a layer of convenience for mathematical operations and more.

Here is the code of two functions available in the cmp package

    var num, num2, num3 int64 = 1, 2, 1
    var str, str2, str3 = "ab", "abc", "ab"

    r := cmp.Compare[int64](num, num2)
    r2 := cmp.Compare[int64](num, num3)

    r3 := cmp.Less[string](str, str2)
    r4 := cmp.Less[string](str, str3)

    fmt.Println("Num is less than Num2: ", r <= 0)
    fmt.Println("Num is equal to Num3: ", r2 >= 0)
    fmt.Println("Num2 is greater than Num: ", r2 >= 0)
    fmt.Println("")
    fmt.Println("Str is less than Str2: ", r3)
    fmt.Println("Str is less than Str3 ", r4)

With the result

Num is less than Num2:  true
Num is equal to Num3:  true
Num2 is greater than Num:  true

Str is less than Str2:  true
Str is less than Str3  false

When using cmp.Compare it will return -1,0,1 which means from the documentation:

-1 if x is less than y,
0 if x equals y,
+1 if x is greater than y.

When employing cmp.Less, it evaluates whether the first value is less than or equal to the second. This utility proves highly beneficial for tackling algorithmic challenges.

You can check the code here

And that concludes this post. In our next installment, we'll wrap up with discussions on slices packages. Stay tuned!

Part three

Golang 1.21 is here (Part 1)

Pedro Bertao — Sat, 26 Aug 2023 10:57:27 +0000

Golang 1.21 arrived on August 8th with some performance improvements, the addition of native packages, and functions that will enhance your code syntax and productivity in your daily work. Below, I've selected the a fews topics along with examples of how to use them. You can follow the complete change log here.

Let's start with the changes in the language itself, where utility functions were implemented: min, max and clear.

Min and Max

func main() {
    minInt := min(3, 2, 1, 4)
    minFloat := min(4.0, 2.0, 3.0, 1.0)
    minString := min("ab", "a", "abcd", "abc")

    fmt.Println("Min Integer:", minInt)
    fmt.Println("Min Float:", minFloat)
    fmt.Println("Min String:", minString)

    fmt.Println("==================")

    maxInt := max(4, 2, 3, 1)
    maxFloat := max(1.0, 4.0, 2.0, 3.0)
    maxString := max("a", "ab", "abc", "abcd")

    fmt.Println("Max Integer:", maxInt)
    fmt.Println("Max Float:", maxFloat)
    fmt.Println("Max String:", maxString)

}

With the result

Min Integer: 1
Min Float: 1
Min String: a
==================
Max Integer: 4
Max Float: 4
Max String: abcd

What's interesting is that with the addition of these two helper functions, Generics are used as input, and the type of the Generics is cmp.Ordered, which basically applies to all comparable types in the Go language.

You can see the Min-Max code here

Clear

According to the documentation,

The new clear function deletes all elements from a map or zeroes all elements of a slice.

func main() {
    intSlice := []int{1, 2, 3}
    floatSlice := []float64{1.0, 2.0, 3.0}
    stringSlice := []string{"a", "b", "c"}
    mapString := map[string]string{
        "Name": "Pedro",
        "Age":  "20",
    }

    clear(intSlice)
    clear(floatSlice)
    clear(stringSlice)
    clear(mapString)

    fmt.Println("Int Slice", intSlice)
    fmt.Println("Float Slice", floatSlice)
    fmt.Println("String Slice", stringSlice)
    fmt.Println("Map", mapString)

}

With the result

Int Slice [0 0 0]
Float Slice [0 0 0]
String Slice [  ]
Map map[]

As we can see, it not only clears the Slices, but also makes their sizes equal and replaces the values with default ones. In the case of the Map, after using the Clear function, it's as if it were an empty Map.

You can check the Clear code here

For the next parts I will cover some new cool Log, Cmp and Maps features that were added.]

Part two

What I learned building my first side project

Pedro Bertao — Sun, 11 Aug 2019 18:23:33 +0000

I have always wanted to be a better programmer since my first job a few years ago. And by wanting to be a better programmer you would naturally look for ways to achieve that goal.

It's not hard to find lists explaining step by step what you should do to enhance your programming skills. Almost all of those guides would mention building a side project.

So I decide to build a Crypto Tracker App where you could follow your favorite cryptocurrencies values with local notifications.

Here are the lessons taken from it

1. You have to deal with problems outside of your comfort zone.

This project was built using React Native and I'm working with this technology for sometime now. It wasn't difficult until I had to deal with Local Notifications (iOS/Android), something that I never had done before. It took me a couple of days of reading and testing to finally get to work. After that, background tasks are something very blurry in the RN world leading to more problems with my original idea.

I ended up solving those issues and I'm more prepare to handle tasks related to those topics in the near of far future.

2. You code, you review, you fix

Build something by yourself can be sometimes make you produce lazy code and poor syntax. I've had more than one occasion that my codes were so bad that even though was working, I didn't want to commit it. I would patiently rewrite to follow a design pattern or the very minimum syntax standards. That's because I knew I would want others to look at my code and send me feedbacks about general architecture and UI/UX, not about how poorly my code was written.

After finishing this first version I can say for sure that my ability to search for inconsistencies and flaws throughout codes (mine or others) have increase significantly.

3. Motivation is tricky, you have to set micro and macro goals

Something that delayed this side project from being released early was probably because I wasn't motivated enough to keep going. In the very start I was trying to build everything in one go. Of course that didn't work and kept me thinking if this was really a good idea. But at the same time I didn't want this project to end up in the 'I don't have time' purgatory.
So I changed my routine of work and added small incremental steps (just like any other agile methodology) and gradually build the core of the app. After that, every time I'd sit to code this project I would focus on one micro task at the time always pursuing the macro objective.

That way I managed to finish the first version within 2 months (I was expecting one month) and I have to say, this was of a great relief.

Conclusion

Building a side project can be somewhat stressful and can lead to some headaches, but the overall experience and learning are worth taking.
You should build a side project because will increase your knowledge about the technology, you will face and solve new problems and you will have something awesome to share with the community. Don't let your ideas purge away on the 'I don't have time' zone.

Checkout the project here and the source code