Dev on Filippo

Claude explained maps.Copy. Then I read the source.

Mon, 01 Jun 2026 22:57:39 +0200

I really like AI, and I love Claude. It is a great tool, particularly when it comes to learning or comparing approaches. It does a pretty good job of evaluating pros and cons, and providing me with explanations for them. All great, until recently.

The PR

In the context of a code change, in a BSON variable containing some file information, I had to include the parsed information extracted from the file name.

doc := bson.M{
	"filename":   fileName,
	"content":    string(content),
	"created_at": time.Now(),
}

meta, err := parser.Parse(fileName)
if err != nil {
	log.Printf("Error parsing file name %s: %v\n", fileName, err)
	continue
}

for k, v := range meta {
	doc[k] = v
}

The comment

Despite being a pretty straightforward change, a colleague left a comment on the last loop.

My IDE suggests to replace the loop with maps.Copy(doc, meta) according to this https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/modernize#hdr-Analyzer_mapsloop

Alright, we don’t use that analyzer, but I was curious to know more.

mapsloop: replace explicit loops over maps with calls to maps package

The mapsloop analyzer replaces loops of the form

for k, v := range x { m[k] = v }

with a single call to a function from the maps package, added in Go 1.23. Depending on the context, this could be maps.Copy, maps.Insert, maps.Clone, or maps.Collect.

The transformation to maps.Clone is applied conservatively, as it preserves the nilness of the source map, which may be a subtle change in behavior if the original code did not handle a nil map in the same way.

It wasn’t clear to me whether this approach, other than being shorter and possibly “more idiomatic”, would bring any tangible improvement. While digging into it, I decided to involve Claude, hoping it would point me in the right direction.

Claude

I asked Claude (Opus 4.7) about it:

Does the mapsloop analyzer for Go suggest real improvement here?
for k, v := range meta {
	doc[k] = v
}
the suggestion is to use maps.Copy(doc, meta). How is it better?

The answer was… something.

maps.Copy is better in a few small but real ways.

It’s clearer to read. maps.Copy(doc, meta) immediately tells you “copy meta into doc.” The loop version requires the reader to scan three lines and verify it’s actually a plain copy — not a transformation, not a filter, not a conditional merge. The intent is explicit at a glance.

I don’t think this is a valid point at all. The loop is stupidly simple. In my opinion, it’s even clearer as it is!

It’s slightly faster. The standard library implementation skips some of the overhead of a Go-level range loop. For small maps it’s negligible, but for large maps it’s measurable. Not a reason on its own to switch, but a free bonus.

Interesting. Let’s have a look at the maps.Copy implementation.

func Copy[M1 ~map[K]V, M2 ~map[K]V, K comparable, V any](dst M1, src M2) {
	for k, v := range src {
		dst[k] = v
	}
}

It handles nil destinations more predictably. Both versions panic if doc is nil, but maps.Copy makes the assumption explicit by being a documented function.

Wow. I mean. I don’t even know how to comment on this.

It composes better. If later you want to copy with a filter, you’d switch to maps.Insert with an iterator, or use maps.CopyFunc (depending on Go version). Starting from maps.Copy makes those refactors more natural.

Man, I am just merging two maps. And even if I had to add a filter, I’d need to change the code either way.

The walkback

After confronting it with the truth, it admitted its error.

You’re right, and I overstated the case. Looking at the actual implementation, my “slightly faster” claim was wrong — it’s literally the same loop, no compiler magic, no optimization. That was sloppy of me.

Your other pushbacks are also fair:

The readability argument is subjective. A two-line range with dst[k] = v is about as transparent as Go gets. Calling it less clear than maps.Copy(dst, src) is a stretch — both are immediately obvious to anyone who knows the language.

The nil panic point was filler. Both panic identically. Documenting the panic in a stdlib function doesn’t change runtime behavior.

The composability point assumes a hypothetical refactor that may never happen. You’d rewrite the code either way.

So the honest answer is: the only real reason to prefer maps.Copy is idiomaticness — it’s the standard-library way to express the intent, and consistent codebases tend to be easier to read across files. That’s a legitimate but weak argument, and not enough to justify changing existing working code on its own.

If the analyzer is enabled and you want to satisfy it, switch. If you don’t, ignoring this particular lint or disabling it for the project is perfectly defensible.

Claude didn’t just give an incorrect answer. It confidently invented benefits that did not exist. Hallucinations are nothing new, but this was the first time I had run into one in such a simple, verifiable scenario. Hopefully, it’ll be the last.

Building a customizable Telegram bot in Go

Mon, 18 Nov 2024 14:01:48 +0100

Telegram bots are powerful tools for automating tasks and interacting with users. They are also easy to build and deploy, so it looked like a good idea to build one to play around with Go. This post will guide you through building a customizable Telegram bot. If you’d like to see the final code or simply go and grab the ready-to-use script to customize and run, you can find on GitHub. The setup and running instructions are included through the post.

Understanding Telegram bots

A bot in Telegram is a special account that is not linked to a phone number. It can be used to receive messages and send responses. The bot API is simple and well-documented. Note that there are two ways to receive updates from a Telegram chat: via the getUpdates method, or by setting a webhook. The getUpdates method is a simple way to poll for new messages, but I’d recommend to use a webhook because they are faster and more reliable. This post will focus on setting up a webhook.

Creating a bot

To create a bot, you need to talk to the BotFather via Telegram. This bot will help you create and manage your bots. You can create a new bot by sending the /newbot command to the @BotFather. Follow the instructions to set up your bot and note down your API token.

Setting up the bot

Create a new project folder and initialize a Go module:

$ mkdir telegram-bot
$ cd telegram-bot
$ go mod init telegram-bot

Install the required dependencies. In this case, we will use godotenv to manage environment variables through a .env file, yaml.v2 to parse the triggers, and bluemonday to sanitize the input.

$ go get github.com/lpernett/godotenv github.com/microcosm-cc/bluemonday gopkg.in/yaml.v2

Loading the configuration from .env

Create a .env file in the project root with the following content:

TELEGRAM_BOT_TOKEN=your-telegram-bot-token
PORT=8080

Then, load the environment variables in the code:

err := godotenv.Load()
if err != nil {
    log.Fatal("Error loading .env file")
}
if os.Getenv("TOKEN") == "" || os.Getenv("PORT") == "" {
    log.Fatalf("TOKEN or PORT is missing")
}

Loading the YAML file

Create a triggers.yaml file in the project root with the following content:

- key: hello
  values: Hello!
- key: say hello to
  values: Hello __input__, how are you?

Then, load the triggers in the code:

type Trigger struct {
    Key    string      `yaml:"key"`
    Values interface{} `yaml:"values"`
}

var triggers []Trigger

func initializeTriggers() error {
    file, err := ioutil.ReadFile("./triggers.yml")
    if err != nil {
        return err
    }
    return yaml.Unmarshal(file, &triggers)
}

Handling incoming messages

Telegram sends updates using JSON. We need to parse the incoming message and send a response. The message structure is defined in the Telegram API.

type Update struct {
    Message Message `json:"message"`
}

type Message struct {
    Chat Chat   `json:"chat"`
    Text string `json:"text"`
}

type Chat struct {
    Id int `json:"id"`
}

Then, we can handle the incoming messages:

func callHandler(w http.ResponseWriter, r *http.Request) {
    var update Update
    err := json.NewDecoder(r.Body).Decode(&update)
    if err != nil {
        w.WriteHeader(http.StatusBadRequest)
        return
    }

    responseText := computeResponse(update.Message.Text)
    if responseText != "" {
        sendTextToChat(update.Message.Chat.Id, responseText)
    }
}

Computing the response

Match the incoming message with the triggers loaded from the YAML file:

func computeResponse(input string) string {
    for _, trigger := range triggers {
        if strings.Contains(strings.ToLower(input), strings.ToLower(trigger.Key)) {
            switch values := trigger.Values.(type) {
            case string:
                return values
            case []interface{}:
                return values[rand.Intn(len(values))].(string)
            }
        }
    }
    return ""
}

Setting up the web server

Listen for incoming requests using Go’s net/http package:

func main() {
    loadEnvVariables()
    err := initializeTriggers()
    if err != nil {
        log.Fatalf("Error initializing triggers: %s", err)
    }

    http.HandleFunc("/", callHandler)

    log.Printf("Server running on port %s", os.Getenv("PORT"))
    err = http.ListenAndServe(fmt.Sprintf(":%s", os.Getenv("PORT")), nil)
    if err != nil {
        log.Fatalf("Server error: %s", err)
    }
}

Sending messages

Call the Telegram bot API to send the message back to the user/chat:

func sendTextToChat(chatId int, text string) {
    url := fmt.Sprintf("https://api.telegram.org/bot%s/sendMessage", os.Getenv("TOKEN"))
    _, err := http.PostForm(url, url.Values{
        "chat_id": {strconv.Itoa(chatId)},
        "text":    {text},
    })
    if err != nil {
        log.Printf("Error sending message: %s", err)
    }
}

Running

To run the bot, you need to set up the webhook. You can do so using the Telegram API:

curl -X POST "https://api.telegram.org/bot<YOUR_TOKEN>/setWebhook?url=<YOUR_SERVER_URL>"

Then, run the Go script:

$ go run main.go

Conclusion

Building a Telegram bot is a fun way to approach a new language or technology, since it’s pretty straightforward and you can see results quickly. This post covered the basics, but you can use it to automate tasks, send notifications, or even build a chatbot. The possibilities are endless, so go ahead and build your own!

Another default_scope story

Thu, 14 Nov 2024 14:49:41 +0100

Rails default_scope is an ActiveRecord macro that allows you to set a default scope for all the operations on the model. This is useful to filter out records by default, such as soft deleted ones.

class User < ApplicationRecord
    default_scope { where(deleted_at: nil) }
end

In this way, we can filter out soft deleted users from all queries.

User.all
# SELECT * FROM users WHERE deleted_at IS NULL

This is a powerful tool, but it can lead to unexpected behavior. If you Google it, you will find a lot of examples. This is what I found out the hard way. On a Friday. Afternoon.

The problem

In our application, we use soft deletion on a number of models, including users. The Pallet model has a belongs_to association with the User model. This ensures that somebody had inspected the pallet before approving it.

class Pallet < ApplicationRecord
    belongs_to :inspection_by, class_name: 'User', optional: true
    validates_presence_of :inspection_by, if: -> { approved_at.present? }
end

Last Friday we had to approve a pallet, but that was not possible because of a validation error. The record was not valid, with the error message Inspection by can't be blank. But the inspection_by_id attribute was set. What was going on?

The solution

I checked the user who inspected the pallet and found out that they were soft deleted after inspecting the pallet. The default_scope was filtering out the user, and the validation was failing because the user was not found. The solution was to change the validation in the Pallet model to check for the inspection_by_id attribute instead of using the association.

class Pallet < ApplicationRecord
    ...
    validates_presence_of :inspection_by_id, if: -> { approved_at.present? }
end

This way the validation will pass if the inspection_by_id attribute is set, regardless of the user being soft deleted. That was safe enough for our use case since many validations ensure that the user is valid at the moment of inspection.

So after a nice Friday afternoon deploy to production, we were able to approve the pallet. And I was able to enjoy the weekend.