My experience at Gophercon US 2024

Chicago, what a beautiful skyline from the hotel room, in floor 23rd! https://www.instagram.com/p/C9UsZnFovs7/?img_index=1

I'm sharing in this post the experiences during GopherCon , my first Go conference, not as a speaker, not as an attendee, but as part of the Docker, Inc booth as a gold sponsor. I have to send BIG thanks to the Docker, Inc team here with me at the booth for such an incredible week working with you: Melanie Salman Emily Casey and Sebastiaan van Stijn. ??????

Day 0: Sunday 2024-07-07

Sebastiaan van Stijn, moby/moby core maintainer, and I flew the same day and landed in Chicago at the same time, so we shared the ride to the hotel. We had the chance to meet in person for the entire day, talking about our personal stories in tech.

I registered to the conference right after arriving the hotel, checking that the conference book was amazingly showing the Testcontainers gopher in one of the pages. Great design job!

We attended the “Women Who Go” meetup in the hotel lobby, organised by Samantha Coyle and Cassie Coyle (from Diagrid). Samantha presented her book “Go Programming - From Beginner to Professional” (Packt), and Sebastiaan won her book in a raffle! We had a light dinner during the event, and I went to bed soon, as I was exhausted after a long day travelling from Spain.

Day 1: Monday 2024-07-08

Jetlag hit me strong this day, waking up at 2:20 am. So I started working from the room at 3am after losing the "Battle for Sleep". This conference day was for setting up the booth and for the workshops, and wondering around in between. I took this “free” time to respond on some PRs/issues, and to talk to Sebastiaan about different testing topics regarding Testcontainers libs (specially Go) and Moby, such as the different testing schedules, or what to test in a nightly basis.

Regarding the booth itself, we were located next to Neosync and Temporal.io, and close to Buf Build.

Day 2: Tuesday 2024-07-09

First day of the conference, and jetlag my old friend hit me low this time, waking up at 5am. I was a bit worried because of this was the first time we presented the library in a conference, not in a talk, but in a booth. The first thing I did in the morning was to update the Go workshop to the most recent release of Testcontainers for Go, so we could use it as reference in the booth, and I think this worked pretty well.

As a means to understand the amount of people in the booth this day, exhibitors took lunch 30m earlier than the attendees, so I had mine on time, but could not even finish because of the amount of people that were not in the last talk of the morning, plus the amount of people that came to the booth during lunch. So I barely ate anything.

?? Sebastiaan came with the suggestion of simply having a 20-30 line code snippet in the handouts, as it was pretty clear for the attendees to understand the value proposition with code. We mentioned it’s a Go package you add to your dependencies, it’s a library you put into your code, and their faces only changed when showing the code from the Go workshop. I think this will work.

It’s interesting that many times people did not even know about Testcontainers for Go: “Are you guys a new project?” sic. The library was created in 2018, and we are working towards creating the first major release (v1.0.0) real soon. In any case, this leads me to the following thought: if we were thinking that Testcontainers for Go was below dockertest in popularity, e.g. see Github stars, and the people in the conference do not say anything about dockertest, and are also surprised by our value proposition, then, where are the dockertest users? Simply not coming to Gophercons? I'd have loved interacting with users of that library to understand their concerns. On the other hand, if the case is the Go community is not aware of the testcontainers-way, then my perception is that we are in a very good situation, as we’d just need to advocate for its usage, not being concerned about a possible rejection from the community. Else, using dockertest, or shelling out to the docker cli in the Go code, could be their choice, but this is not the feedback we received during the conference.

I have to admit that by the end of the conference we did not perceive anything against the project, but it could be because nobody expressed it at the booth. In any case, I was checking Twitter for “testcontainers gophercon” and “docker gophercon” and could not see anything sentimentally against.

Interesting booth conversations, apart of the ~100 scanned badges for that day:

• Weaviate team: I could meet the developer submitting the different Testcontainers modules, Marcin Antas . Thank you for creating them!! They shared they are really happy using the module for testing their own product. Cool!
• Daniela Petruzalek (Google Developer Expert in Go), JP Morgan: really interested in the project. I also connected with her on LinkedIn for following-up in the GDE program, to which I would like to participate. She suggested me using her name as referral.
• Matthew Sanabria (Cockroach Labs, Content Creator). I precisely watched a video from him the day before the trip, and wanted to thank him personally for that. We shared with him about the cockroachdb module for testcontainers-go, so we could probably collaborate: 1) using Testcontainers internally, and/or 2) creating Youtube videos on the library. "sudomateo", please be ready for a friendly ping!

I particularly could not attend any talk, as it was a busy day in the booth.

Regarding our neighbours, we had a few conversations with them, about them creating Go modules for their technologies. Therefore, a potential partnership agreement could be done with them for the official modules program:

• Neosync Anonymize PII, generate synthetic data and sync environments for better testing, debugging and developer experience.
• Buf.build: Distribute, govern, and streamline your Protobuf APIs with the Buf Schema Registry.
• Temporal Technologies Manage failures, network outages, flaky endpoints, long-running processes and more, ensuring your workflows never fail.

All of them were excited about the chance to be part of the Testcontainers ecosystem with a module.

Another interesting feedback about the booth is that the Docker logo was in the desk, in the below part, so it has very low visibility compared with other sponsors. We had a few Testcontainers rollers and people just come by because of the project name, realising that Testcontainers is indeed a Docker, Inc sponsored project after us telling them. My impression the relationship between Docker and Testcontainers is still very new and people are not making the connection.

Day 3: Wednesday 2024-07-10

Second day of the conference, with way less booth work. I had the chance to attend the first talk of the day: “Who Test the Tests”, by Daniela Petruzalez, where she shared ideas for adding mutation testing to any Go project. There exist a few libraries, probably outdated, but following that work it’s possible to create “mutants” that would pass or be killed after a test run.

Then, more booth work, but definitively different and more relaxed compared to the first day. I also attended two more talks, right after we closed the booth in the afternoon:

• “Go in the Smallest of Places” by Patricio Whittingslow. I do recommend you this talk once it’s live on Youtube, as it gave a good historical introduction to TinyGo compiler, starting with Assembly and C.
• “Range over Function Types” by Ian Lance Taylor. This talk presented the internals of the new iterator APIs that will be introduced in Go 1.23.

Interesting out-of-the-booth conversations:

• Ron Evans (TinyGo maintainer), living in Spain and having a friend in common (the other maintainer of TinyGo), I could approach him and talk about the TinyGo project, as I did a workshop with him back in 2019, in Lisbon during a GDG offsite.
• Morgan Bazalgette GNO.Land core team developer) Spanish speaker, we could talk in Spanish about the benefits of using Testcontainers approach.
• David Chase (Go team), I approached him to talk about the GDE program, and after helping me out with the mechanics, he shared about the recent optimisations in the Go 1.23 compiler thanks to shuffling the functions order in the compiled binaries. We also talked in Spanish ??, which always helps in refreshing my brain when I'm abroad. Great to meet him, somebody from the Go team!

Day 4: Thursday 2024-07-11

This is the day that you fly back home, and for me it's always the same: your brain is already at home, but your body still needs to get to the airport 2-3 hours before the departure, then 8-9 hours more sitting a tiny seat, and then commute back home, ending up in almost an entire day travelling. Thankfully, the return flight was smooth, I could sleep 4-5 hours in the plane, arriving Friday morning to Spain. A bit tired, but after a 2-hour hardcode nap on Saturday morning, I could skip jetlag and return to my poor sleeping routines (you know, babies need to be fed by night!).

Conclusions

We wanted to accomplish two major goals from the conference:

Learn from attendees what messaging resonates

Many of them understood the value proposition of Testcontainers for Go and Testcontainers Cloud, but the vast majority of them simply did not know about the existence of the library.

I did not perceive a strong feeling against the Docker container runtime. In fact, there were many Docker customers in the room, so there were not that many questions about using Colima, Podman, Orbstack, etc.

Present Testcontainers for Go, for first time in a conference, as the testing library for Go projects

My perception is that the library was really well presented by the team and the audience extracted the value proposition we wanted to share. I’d expect more Testcontainers for Go usage in Ryuk pulls that could correlate more adoption after the conference, probably something to share as a follow-up. At the same time, the audience acknowledged the major issues we usually detect with projects not using Testcontainers, seeing themselves in the scenario where they were building Go code to integrate and manage the lifecycle of the Docker containers with Makefiles and Compose files, which is exactly one the issues that Testcontainers resolves.