So, thank you very much. I love Go and this is the first time I give a talk at a Go thing or attend the Go thing, so I'm really excited. Thank you very much for the opportunity. Thanks. So, the reason I thought this might be interesting is because I don't think

this sort of software has been written in Go before, because Go, from what I understand, is more towards like networking, concurrency, stuff like that. I hope I'm not overgeneralizing. And so, let me just quickly say what formal verification is. So, you guys know TLS signal, these are protocols. And so, when people design these protocols, they want them to achieve certain

security guarantees. Like, for example, TLS has to have server authentication and also confidentiality for the websites, like the data that you're sending to websites like passwords. And so, these protocols are really hard to design. And as a result, it's kind of important to be

able to design them in a way that's formally verified to actually achieve the security properties. And there's a lot of frameworks to do that. And basically, the way that VerifPal works is like the way that symbolic protocol verification tools work, which is basically you write a model for what the protocol looks like and then you ask VerifPal questions like, okay, here's a model of TLS, here's a model of signal, here's a model of IPsec, etc. Do we

have confidentiality when Alice sends this message to Bob? Do we have authentication when Bob responds, etc.? And then VerifPal or these other tools will give you answers like yes and no. So, this stuff has been used to analyze all of these protocols, TLS 1.3, noise, Bluetooth, 5G. Why isn't it used more? Well, because these languages are really specialized and academic

and weird. So, VerifPal tries to be an intuitive, easy-to-use, friendly protocol modeling verification analysis reasoning framework with a new language that's intuitive, avoids user error, analysis output that's easy to understand and it integrates well with your developer workflow.

So, you can kind of see why I appreciate Go as well because it has similar priorities. And so, it has these cool features, doesn't, you know, intuitive language. I want to skip past this because I want to focus on the Go part more. So, the language is simple. You can talk, you know, Alice does this, Bob does this, and then you get formal verification results. We've used it to verify these protocols,

Signal, ProtonMail, Telegram, and people are using it independently as well. You can check out more people that are using it. Okay, so it's a nice tool. You can find talks that are more specific about the tool online, but I want to talk about using Go to make this. So,

generally speaking, Go has been amazing because the language is small, simple, easy to reason about, and predictable. And this has given me also a way to, I've been able to get an alpha version of this done really quickly compared to using something like OCaml, which is what I used when I was in academia,

and the difference has been huge. There's also been an insane, so I wrote the alpha version and then the beta version of this without doing Go routines for concurrency because I was first concerned with like, you know, the correctness of the analysis, like who cares about performance. I'm not going to look into that until later. And then I started looking into

performance, and the moment I started using Go routines, analysis was sped up 240x when I used 240x when I started using Go routines because of what I was able to achieve with concurrency, and that is something that maybe is possible with the most recent versions of OCaml because now OCaml has multi-threading, but I don't think I would have been able to achieve that

as quickly or simply. And so also because of the tooling and debugging, especially Go run dash race, which was really useful when I started implementing Go routines, I've been able to debug and do like releases really quickly and publish for all popular operating systems really easily, so the tooling has been really nice.

Now let's compare to other languages that are usually used for this sort of formal stuff. So usually you would use OCaml or Haskell. So Proverif, the like big deal tool competitor to VerifPal is written in OCaml, and the other really important tool, and both of these tools have existed for like literally 20 years around that time, is written in Haskell. And so

these languages focus on functional programming, focus on being correct languages in the computer science term, and have existed for much longer than Go. So one of the reasons why I chose to use Go as well is because, I mean, you know, people have already written this software or similar software in those languages, so it might be better to have like, okay,

we have one of them in Haskell, one of them in OCaml, and one of them in Go. It's like more sort of more interesting stuff happens. There's a bigger ecosystem of this kind of software. However, so compared to Go, if I were to use OCaml etc, it's much slower, of course, worse concurrency, the ecosystem is tiny, the tooling for OCaml is honestly just not good.

And also, however, there is one thing that these tools do really well, these programming languages do really well, which is that their syntax and semantics are amazing for describing abstract syntax trees, for building parsers, for building languages, models doing like sort

of like this syntax analysis, and dealing with the kind of structures that you would see in that sort of formal setting, especially when it comes to languages and ASTs. And that was, you know, to give the other side of my impressions, something that Go was not

able to compete, just simply the syntax and the semantics when it comes to ASTs, specifically. So there's one really amazing feature that's available in OCaml and Haskell and also Rust called pattern matching. And so pattern, not regex, you know, pattern matching matching the structural pattern of values. So for example, here we have this recursive function,

it matches like, it matches list with, and there's like two potential values for list. There's one which is empty list, and the second, you know, like while it's matching it, splits the list into a head and a tail. So you can sort of look into the structure of what you're

matching and then actually split the result and then use like, okay, if the list is empty, return false. If the list is not empty, then obviously it must have a head and a tail, and then the head is equal to x, and the tail is run recursively through this function with x, right? And you can also have guards on these pattern matching declarations,

where you can sort of impose more restrictions on what you're pattern matching and what happens when you use them. So I really think this is a cool feature. I think that Go, you know, Go is my favorite programming language. I've never had more productive time writing software than when I'm using Go, and I don't think I'm going to switch away from Go anytime soon at all.

It just, I think it would be really cool to consider having this pattern matching syntax, it's supported by many other languages, and it would radically, in my opinion, and I'm not a Go expert, I don't know how the language was designed, there's probably decisions that are smart why this doesn't exist, but it might expand the use cases for which it

is appropriate to use Go, because it might make it like a much more ready language for the sort of like PL and formal stuff, where it has a lot of potential to contribute, specifically because its tooling is so much better than the languages usually used for this, it's got insane performance and concurrency benefits, and it's just really nice, like,

it's easy and fun. So, yeah, check out VervePal, and also thank you for listening, and thanks for Go, it's great. Thanks. Hey, my name is Steve, I'm a back-end engineer at GitLab, I work on the CI team,

and today I want to talk to you how to, what you can do when you import the context package.

So, we'll go over some introduction, cancellation, timeouts, and how we can use context for logging and distributed tracing. So, first thing is why use context package? So, the context package can allow you to do cancel propagation throughout your whole program, so you can do graceful shutdowns, you can have request scoped values, so for example, imagine a request ID and then

you log it, and for distributed tracing, and then you can have specific deadlines and timeouts, so a certain operation can only take X amount of time. So, this is pretty much the whole API that the context package exposes, the with value, with cancel, and deadline and timeout basically

take a context, which we call a parent context, and give you another context and return. So, the way your program ends up looking like is a tree, right? So, you have the context background in the main function probably, and then you pass that context around in your functions,

and then you add more data to it. So, context with cancel if you want to cancel that specific amount of work, with value if you want to add values, and then you end up with the whole tree, and with this whole tree, you can get propagation downwards, so for example, if you cancel the context with cancel, all the contexts under it get cancelled, but keep note that if the context

with timeout is cancelled, it does not propagate upwards, so it's only downwards. So, there are three types of cancellation I like to think about, concurrent code, HTTP requests, and command line applications as well. So, if anyone writes concurrent code, they might be familiar with

the done idiom on Go, so you have an empty struct that you pass around, and then you close that struct. So, the context package follows that idiom very similar. You have a context.done that's just a channel, and it's closed when the context is cancelled, and then you can also read from context.error to see why it was cancelled, and it's normally used within a select

statement. So, as a simple example, we have a func main here, we're creating a context with cancel, then we're spawning a new Go routine, calling the expensive worker, passing in the context, sleeping for five seconds, and then calling the cancel function, which makes the cancellation,

and our expensive worker is just a simple select, which is mimicking some work with the time.tick, and then as soon as the context.done is closed, we exit the program, and we can see an example of the logs here. So, the HTTP NAT package, you can give it a context, and it understands it,

and the benefit of this is you can cancel mid-flight requests. So, for example, imagine that you're sending a request for some aggregation data, and you don't need that data more because something else happened. You can cancel that request, so you save up on resources.

This is another simple example. We have in the main function, creating the context, and then we're calling a function send request, we're passing in the context, the cancellation function, and the URLs, and then in the send request, the first line is we're calling defer cancel, so as soon as one request returns, we will cancel the other one

because we don't need the data from it. We're creating a new request, and then we're calling request with context, which attaches the context to that request, so the NAT package will use our context, and then we can see we're sending the request, we received 200, and then we're cancelling the other one because we don't need it. Most people don't use the context package for

command line application. They mostly use it for HTTP stuff, but I like to use it for CLIs as well for listening to the SIGINT signal, so you can do graceful shutdowns and things like that. A simple example here, context with cancel, we're doing a signal notify on the SIGINT,

and then we're creating a go routine that listens to that signal, and as soon as we get one read from it, we cancel that context. Later down in the main function, we're just doing a simple select that's pretending to do work, and as soon as the context is cancelled,

we exit. So we can see an example here. We're doing tick, and then as soon as the user presses Ctrl-C, we exit. Timeouts and deadlines are very similar to cancellation, but instead of telling it, instead of you having to tell it when to cancel it, you give it a specific time

when to do so. It also returns the cancel function, so you can cancel it before that specific time, and make sure you always call the cancel function, because it will free up some resources and timers. So a simple example, it's very similar to context with cancel.

We're doing context with cancel, passing a time dot second, which is duration, and here we're waiting for a response from the expensive worker, but if it does not return after one second, we will cancel it. The deadline is very similar. Instead of having a duration, you pass a time,

time, and then for logging, we mentioned request ID for the requests. So we use the context with value, and for example, it's quite useful to see, okay, what are the logs that this specific

request generated? So imagine if you have like a simple service. You should not use it to store any like business logic stuff in it, meaning don't store the user role and do some authentication checks on that user role. Be sure it's a global store, so there can be conflicts, and

you can store any data type, so it can even be a loggers entry. So we're creating a simple new type, so our middleware is creating a UUID, attaching the UUID to the context, and then serving it, and then here we have a logger that reads from that context. If it's

successful reading it and type asserting it into a string, we actually add it to the log keys, and here we can see a simple log with the request ID. Distributed tracing depends heavily on context as well, and all the spans that distributed tracing uses are inside of the context,

so you can inspect them, log them, do whatever you prefer. Some resources, so the link to the presentation, just for func, they have two videos about it. The first one is how to use the context package, and the second one is how to actually implement the context package yourself,

because, as we've seen, it's only five, ten methods. And then the Go doc and some blog about how to use the context package for concurrency patterns. Thank you. Thank you. Teal Tosterson.

Cool. Come here. You're using your laptop, right? You said? No? Okay. Then come here.

Cool. So, let's start a timer, and the next talk is on Illuminous, which is one of the systems that might be supported by Go. Might. Will.

We hope not. Yeah, there's some things ongoing, but I'm not going to talk about that. I was just going to say hi from the Illuminous community a little bit, and talk a little bit about porting for Go, and my lessons while doing that. I've been a Go developer for more than a year now, and a little bit also about my projects that are using Illuminous, mostly for

hosting, and what things I have done with Go on Illuminous. If we go to the porting knowledge I want to share with you a little bit today.

Come on. Switch. No? So, while porting Go packages to Illuminous, I've noticed a lot of the projects tend to use buildtack Linux instead of Unix, even though Unix would have been deficed.

For example, you have a network socket or a Unix domain socket, and you guard that by build Linux. You don't need to guard that by build Linux. It's enough if you guard that by build Unix, so it will automatically work on all new supported Unix platforms. We now have a separate buildtack available since 1.13, actually.

It's a child of the Solaris buildtack, so if you're using the Solaris buildtack, you will get Illuminous and Solaris for free, but binaries built on Illuminous will not work with anything on Solaris, so don't just copy the binaries between the two operating systems.

Use what you build and reuse it the same operating system. The one thing that I've really noticed is the Unix package from the standard library does not yet support many operating systems of the Unix variety, NetBSD, some other BSDs, and us.

The golang.org slash x slash sys slash Unix package is a basically the experimental version of it, and I've used it a lot for every function of the Unix package. I can strongly recommend just to use this package instead of the Unix package from

the standard library if you want to really support the broad range of operating systems. One thing that you need to keep in mind on Illuminous is that all Go programs are linked with CGO to libZ. There is no Go code on Illuminous that does not include

CGO. This is a little bit special, and it's also, if you do CGO enabled equals zero, it will still link to libZ, and it works with cross-compiling. It does not work with cross-compiling, however, with third-party APIs and libraries. So, if you have something that has CGO, you still can't cross-compile, unfortunately. But somebody said that could be

possible if something worked out. For now, it doesn't work with third-party libraries, but with libZ, it works. The other thing is APIs on Illuminous are incredibly stable,

so if you link against something on Illuminous, don't be afraid. It will be stable for many, many years to come. So now a little bit about the projects that I've done on Illuminous and the way you can find them. I've done an implementation of our package manager repository files and metadata in Go, so this can parse it and read it and also do, like,

package creation. I've also done a build system for the whole thing, so you can basically just parse spec files which are very popular in the Illuminous ecosystem,

and they basically have extended it a little bit because I found it lacking VCS support or support, so now I can just change the version number and check out the correct version from Git and build that around. I want to add more things like a spec file writer so I can make it interactive and let it build in zones, so our container implementation,

so that they have a clean slate every time. Based on the zones thing, I've made a little cloud or Docker runner, so it can download images from Docker Hub, import them properly like Docker

does it, and just run images in Illuminous hosts or in our container implementation. Currently limited to Illuminous binaries, but Linux binary containers will be supported later on, and I have also written a little bit of a zone API about that which you can use if you want,

so if you want to have your Go code to create zones on Illuminous, that's the API to use, and some people are going to add a nomad driver, so if you have nomad in place, you will be able to write nomad files to provision zones, so and last but not least,

if you anybody needs a little bit helping with porting or has questions about Illuminous or in general wants to reach out what I do about Go on Illuminous, you can find me here. If I don't know it, just ask anyway. I'll redirect you to the right person. Thank you very much.

Thank you. Okay, the next one is Andrew Williams. Cool, come here. I see your slides are ready too.

Cool, okay, so fun, fine features. Thanks very much indeed. Hi, my name is

Fine Project. I don't know if anybody will have heard of it before, but just in case not, it is a scalable graphical user interface built specifically for Go to help build native applications across essentially any graphical platform that you could think of, and for me, Go is just a phenomenal match there. Some people might say that's not what

it was designed for, but hopefully I can convince you that it works pretty well. I've spoken before about the vision and the roadmap of the Fine Project, and instead of that, I thought I would present something a little bit more fun today.

There are lots and lots of cool things built in already. If you were thinking about maybe doing something graphical with Go and you didn't know which toolkit, one of the reasons I might say that you should have a look at Fine is that all of those widgets are built there for you, so it's a good starting point. I'll not run through them all, but

it's just listed up for interest, and following the great tooling of Go and the idea that everything should be really thoroughly tested, we thought it would be very important also to support unit testing, and so the test tap is going to activate the tapping gesture. Type will help simulate the key inputs to your application, so you're testing a full graphical

app but without having to do the nitty-gritty parts of it, and this is all running behind the scenes so you never see windows flashing up in front of you, but if you really want to see the contents are rendered to an image, we've got a playground utility there as well. With all of those things, it's pretty easy to build a nice application. This little pixel

editor was an idea I had on the plane here and thought, what could I do really quickly? Ah, yes, a pixel editor, and so that was put together in under four hours with a 60% test coverage, something like that, so that's pretty decent, I think, for getting a graphical app

running, and that would be across all of our supported platforms, which I'll come back to. If you like playing with pixels, obviously, Go is a good place to be. The image stuff in the standard library is pretty solid, and we're going to allow importing of a standard Go image into our canvas space, and if you change the pixels, you just call refresh

on the object, and then if you think about where that could go, you could put a timer behind it, call the refresh from a separate Go routine, and then you've got a bit of animation, and so thanks to hfo4 on GitHub who made a fantastic gameboy emulator, we thought, wow, grayscale

pixels is technically accurate, but this is so much more nostalgic, so apply a bit of green and yellow to it, put the board around it, and you've got something that took me back a few years. And now we have a device API, so although these applications are going to work without modification across desktop platforms, mobile platforms, it's sometimes useful to know a little

bit about the device that you're running on, and so we added the device API through current device. You can find it if there's a keyboard available, and if there's not, you might decide to display touch controls, and you can find out about the orientation. Change controllers are not so

important here because the system is going to redraw if the configuration changes, so just look at the if clause is there, and it will redraw appropriately, and so you then have a gameboy emulator that's working with touchscreen controls on your phone for only about six lines of code more

if you don't include the logic of laying them out all in the right place, and the Zelda is absolutely my favorite, but the Tetris high score there was 96 lines, which I think is pretty decent for a touch interface on your mobile phone. If you want to take it a little bit further, that's standard built-in, but we have support for themes as well.

You can set the theme for your application, so we ship with light and dark built-in because we don't really know which people think is more popular. If you want to override that, you can import the theme package and set one for your application, or you could implement the theme interface and specify your own with custom colors, fonts, icons, and so you could then

build this. Thanks SKX there for the fantastic basic emulator. This is actually a standard fine application over the top, but with a custom theme, so it looks again quite reminiscent of what it's trying to emulate, and of course being a Go toolkit, there's so many libraries available.

A lot of people have talked about them already today, so I'm not even going to try and cover them, and most of these are going to be cross-platform by default, so you're not going to have to worry too much about the implications, but then we thought, well, maybe there's some interesting system-specific

stuff. We could be doing hardware access controls for your system, and so the fine desk project was born, so it's not just about little applications or demos. This is a full-blown window manager, multiple screen control. It's doing everything that you might want from a window manager,

and it's all entirely written in Go. Taking the same angle is fine. If you write it with a good language from scratch with a lot of thought, you can actually find it very easy to do complicated things, and the amount of code required to do all of that was minimal. If you are thinking about building a fine application yourself, there's a couple of useful commands here.

Running the application is just as simple as any other Go program, Go run, and it's just going to appear on your screen, but graphical applications have a little bit more complexity when it comes to installing. You don't just want the binary on your hard drive. You want your application search tool to find it. You want the icon to look right, and so we created a helper command

usefully called fine, and you can use that to manage your application packaging. The easiest being fine install, so if you have the current directory is one of your fine applications, it will bundle it up with icons and metadata and install it onto your system, but you probably

want to distribute it, and so we have fine package, which will take the metadata and bundle it into the appropriate format for distribution, so a dot app bundle or a tardiz or an exe file, and if you wanted to then distribute for mobile, it's the same tooling, but you're going to have

to specify the operating system that you're targeting, and a little bit of metadata because of the way that the stores are working. Cross-compiling, thankfully, was brought up slightly earlier there. Yes, when we're doing all this C stuff behind the scenes, which you need to for graphics

hardware acceleration, does make cross-compiling a bit more difficult. It can be done, and to target all of the desktop systems, you could use the standard tooling if you install all the tool chains, which is the C compiler and the libraries and the headers for every single platform that you want to target. Maybe not up everybody's street. It's the way that I like to fly, but I'm just,

you know, working on this stuff hardcore, so we have another project in the community called Fine Cross by Luca, who created this, so it's going to run some Docker containers in the background, build everything inside the container and extract it for you for distribution, so you

need all of that stuff installed. This has been a bit of a whistle-stop tour. I hope it's been interesting. Thank you very much, and enjoy the rest of the day. Thank you very much. We have Yannick

Pierron. Yannick, yes, come here, and you're going to be using a site. How, by SMS, that was not to me. Francesc, F-R-A-N-C-E-S-C.

F-R-A-N-C-E-S-C. Yup, Twitter.

Okay, so hello everyone. So this is a surprise presentation. This was didn't plan at all, but I want to talk to about my project. So this is a new framework written in Golang to write

some microservices. So a word about me. So I am an Odoo developer, so Odoo is an EAPIS software, so this is a software I've used since 2009.

So I started studying Kubernetes and Golang since a few years. I saw a lot of potential here, and especially with Odoo, the problem I had is Odoo is a monolithic application. So this means

that I work as a freelancer, and for my customers this means that everything where all the process of the company are written in one software, so in a single code base.

And this really, according to me, this really empowers the flexibility of the company. So there was a lot of things that I can't really do with Odoo, so I started to study other patterns, especially microservices, to see what was possible in that area.

So the result is a project I called the Empolar Stack, which uses several technologies, especially where I use Golang to write back-office services, so you can have

several services. For example, we can have one service managing the customer's of the company, and also managing the ID invoicing services, etc. Everything accessible through GraphQL gateway, and with a front-end written in React. So I also use other technology

like gRPC and GitLab, and of course Kubernetes. So this is still at alpha, this is really soon. I really wasn't expected to do a presentation today, because the website was

launched just last month. To show you some pictures, just so you can have an idea how it can work, at the top you have the web interface, so this is where your employees will

control the data, which will contact the gateway, which it says redirect the request to the corresponding services. So here is the interface, so for this I use another project,

which is called React admin, which is really great because you can use any back-end, thanks to so this is a front-end, an agnostic front-end, which you can use any back-end. And when you make any request here, so you have all the muting, for example, you can see

the jagger trace at the end. So I just show you the website, which contains a little more details.

All right, so this is the website. I encourage you to see it, because of course I really don't have the time to talk about many of the things. So just to show you, so you have a little presentation. You have the two ways you can install the stack, so either you use

Docker Compose, you can install on your computer, so just you use Docker Compose and you have every component on your computer, or you can go on the GitLab example and for Git, so you have to create your own Kubernetes cluster. For example, I use digitalization for

10 euros per month, so this is really nothing, and your GitLab representation, well, you connect it to your Kubernetes cluster and it will deploy everything on your Kubernetes. So here is the technology I use inside the stack. So of course,

Golang for the back office, React for the front, Kubernetes. So GitLab, as I said, for the CI, the CD process, gRPC, and here is the technology I want to use later

when we will be more advanced about it. I invite you to read the article I written on Medium, which describes what is the reasoning behind the project, and if you want, join the mailing list. So here it is to show you the

repository on GitLab. So here is the repository, and that's it.

I really don't like the touchpad. Okay, this opened a new tab. And so since I have just a little more time to show you some other features,

the reasoning behind, because maybe some of you don't like the word framework. This is not really a framework because I make sure to not use the reflect package. Instead, it extensively uses code generation. Also, at the core of the libraries, it uses protobuf to ease the use of

gRPC to communicate behind the services. So that's pretty much it. Thank you very much.

Okay, so we actually have one more line in talk. Wait. No. What? Oh. Never mind. Okay. So we have one more line in talk. I'm confused. So wait a second.

Person with a cube. It's not you yet. Okay. Sure. Go for it.

Hello, everyone. My name is Shitij, and I'm from India. And I'll be talking about middlewares and

reverse proxy today. And just a bit of background. I graduated recently, and I started my new job at OTA Insight in December. And this is my first time at Fostum and my first ever technical talk. So yeah, I haven't practiced it as well. So what will I talk about? I'll

show you some code. And this talk basically builds upon what Alicia talked about what they do with reverse proxy in GitLab. So I'll be talking about HTTP handlers, middleware, and reverse proxy.

Just a quick show of hands how many people have worked with any of these before while writing applications. Okay, cool. So let's go into the code. So I've got like three files, which I'll show gradually. But the key idea here is that I've got a HTTP service, a hello

service that has got two endpoints, one running on local host 8080, and another one is an internal endpoint that's also an 8080. And there's a reverse proxy that's running on port

9090, and it forwards the incoming request to the hello service. Basically that's the infrastructure and this, there's the code. It's open source, so you can go look at it. The important thing here is that for the hello service, the two endpoints for the internal endpoint, what we do is that we have got a middleware that adds a couple of response headers to the response that's going.

And for the proxy server, it's just straightforward reverse proxy, as Alicia showed earlier. It uses the HP util package. And the interesting thing that it does is it has got a couple of middlewares which change the format of the date and adds a proxy header

just to show that this request was actually served by a reverse proxy. So what I want to do next is I want to get some interaction from you. I'll, I'll

want you to guess what happens for the four endpoints, what response do we get, okay? So let's start off with a simpler one. So this is the hello service, this is the basic one, and we, oh okay, I need to run the server first. Okay, I hope that's running now.

So for the hello service, we get response with three headers and the message basically. Now for the internal endpoints, we get the same response but with couple of extra headers,

right? This was due to the middleware. Now let's see what happens with the reverse proxy. So this is 1990, the reverse proxy, and it redirects to the hello service. So it gets the same response back. All, all fine, right? But what happens when I try to

reverse proxy the internal endpoint? What do you think is going to happen? What's going to be the response? Any guesses? Will I get the same response as this? How many people think that it will be the same one as this? No? Okay, just one. Let's see what happens. Anybody thinks that there's going to be something

different? Any guesses? Okay, what do you think? The, the date will be different because of the middleware, right? Okay, anything else? Any ideas? Okay, let's see, let's see.

Whoa, what happened there? There are two dates, the internal endpoint, and two servers. Did, did someone expect this to happen? Like, multiple header keys? Any idea why this is happening? Why this could happen? No? Okay, let's see. Let's see what happens. So,

basically, what, what's happening is, if I can get it to scale, yeah. So, this is, let's stop the server for now. So, basically, what the reverse proxy that we are setting does is that it, so it fetches the response from our hello service, basically, and

then forwards it to the client, right? But, internally, what it does is it automatically adds all the response headers that it got and forwards them as well. So, basically, what happened was that the hello service sent him, sent the proxy the response with the headers

and it just forwarded it with more headers that we added by the middleware. So, let me, let me show you. So, this happens, actually, here in the code, the copy headers, which uses the add function on the headers, rather than using the set function. So,

and our middleware, basically, it doesn't care whether this header was already set or not, it just adds new headers on top of it. So, that's the whole point of using middlewares in Go. You need to be aware that you are, this header is actually set, not added to the,

header's feed. So, now, the next question would be how would he fix it, right? So, the fix is also easy. I've already got it, just to save us some time. If I can, actually, there are two ways to fix it. I'll stash them. Okay. So, the first fix

is to use a hook that was added in Go 1.12 called modified response on the proxy itself. So, what modified response does is it gives you a chance to deal, actually, with the response

that the proxy got from the underlying service. So, you can do all kind of stuff over there. If you want to change response headers, or if you want to, like, change the response itself, maybe remove some fields, you can do it here. There's a hook available to do that.

So, basically, what we can do here is, like, we can just set that we don't want to expose the internal response headers that we get to the external client, so you just add them there. But then the question comes is should there be a support in the Go standard library for this? But then there's the argument that the library doesn't care whether you're using it

as a transparent proxy or whether you want to use it as a real gateway for your, to protect your internal services. So, in our case, what we actually wanted was to to restrict the client from using the internal metadata. So, for that, we had to use this plug.

Yeah, so, but what happens if, like, you're not using a reverse proxy? You're just using HTTP middleware, and still this problem will persist because what you want to do in your

middleware, actually, is you want to serve the request and then change your headers, right? You basically want this to be, if I can, this. Okay, okay. So, yeah, so, I'll cut to the, okay. Okay, cool. Cool, so, actually, since we have time, we have one more, actually,

two more lightning talks. One is an actual lightning talk and the other one is a super lightning talk. So, these are our backup speakers. So, thanks so much for being in

backup and helping us make this happen as soon as I have connection. Okay. Wait, what? Where's the connection? Connecting. Yes, yes, yes. Cool. And you can use this.

And he's going to be talking about, wait, he's going to be talking about this cube. Cool. So, I am Eike. I am working on TinyGo. And this is something I made. So,

like, almost two years ago, I was working on MicroPython, maybe you've heard of it, and while I was working on it, I was like, if Python can run on my controllers, why not Go? So, I tried to do it and apparently it works. So,

then, at the end of the year, I went to the Chaos Communication Congress, maybe you know it or been there, actually, and I saw this cube. And I was like, oh, I really want

something like that. I mean, it's pretty amazing, right? So, I looked into the specifications and turns out these screens are called Hub 75. They're really hard to drive. Most people use an FPGA. But I looked into it and I was like, I think a microcontroller can actually do it

with some effort. And this thing is actually running on a microcontroller. It's a microchip, actually, on a itsy bitsy M4 board from Adafruit. 120 megahertz is quite fast for a microcontroller. So, yeah.

And so, I made a driver that uses all the special hardware that's in the chip available, like DMA and timers and everything, and provided this interface. Basically, it defines

all the pins I'm using on the chip, the number of screens, in this case six, and the brightness. Actually, I changed it to 10, not one, so it's a lot wider right now. And it provided this global variable in my program because I'm lazy.

But what I like about Go is I can define an interface, the display interface. This interface is shared by all drivers for TinyGo, all display drivers for TinyGo, like all the all the small screens and everything, e-ink displays. And it makes

this easier because you can very easily port code from one display to another using the duct typing feature of Go. So, this is the part of the code that converts the... So, what you may have seen in the previous code is the set pixel takes an

x and y coordinate, so it's a two-dimensional space. And so I have to map it somehow to 3D space instead of 2D. So, that's what I do here. Took me a while to get it right, but

this function gets a time at which to draw. It's fully pure code, so it's no hidden state somewhere. And it gets a function that has all the three coordinates for every pixel

and the time and returns a color. So, for every... It loops through every pixel on the cube and calculates the color for the pixel and at the end displays it in the main function that's not shown here. So, let's see what's next. This is what I'm actually running right now.

It's a noise function. It's a simplex noise, which is a variant of Perlin noise. Maybe you've heard of it. Basically, it uses the three coordinates plus the time and converts it to a value that goes up and down in a somewhat natural way. And then it uses that value as the u of a

HSV color and then converts it to RGB with full saturation and full brightness and returns it to be displayed on each pixel. So, this is a different animation. It's a fire

animation. I'm not going to show it right now, but it's really nice. Maybe if I have some time left over at the end. Okay. So, it's a little bit more complicated and it also has some

cooling effects. But this is basically the core of the animation. There's nothing really special about it. And it's cool, of course. Let's see. Okay. So, while I'm working on this,

you might be wondering, why use Go for something like this? And I there are many reasons. And personally, it's mainly because I just like it. But like most people here, probably. But what I personally also like about it is the portability of Go code. So, what I so the whole

only the driver is the nonportable part. Because it's very specific to this chip. But the whole everything else, the animation, the algorithm that calculates the colors and everything, it's all portable. So, what I did is

I have an implementation of the same display interface. But using SDL2, which is also used for games on, I think, especially Linux. And in just a few minutes, I wrote this.

And I could debug the code just on a regular desktop without any hardware involved. And that made it much faster to work through it. And this is the result. It's basically the same code

running on the cube and on my own laptop. So, yeah. That's it. Thank you. Okay. Okay. I have two mics now. And for the last talk, it is here.

So, this is a mini lightning talk. About the seventh Go Dev Room. So, this is the end. So, we wanted to thank all of the speakers. This is from yesterday's speaker's dinner. And Google paid for food. So, thanks, Google, again. Yeah. The food was really good. And also,

we wanted to talk about the garbage collection. Collect your garbage. So, as you're leaving, please, take stuff and leave it there. There's a trash outside. If you do it, we will not have to do it. This room is really big. So, also, if you want to stay and help us doing that,

that would be super nice. So, let's use it and let's all pick one piece of trash, put it there, and then we only take like ten nanoseconds. Let's do this. Great. Thanks, everyone, for coming. See you next year.