Hello everybody, I will talk about Go Evil, which is a project, a personal project, which
allows you to do one-liners in Go, so you just type your Go code and call it with Go
Evil, and you can simply write a name or word from the command line. So this is like magic.
I will show you a bit under the hood how it works. The word project is about 300 lines of code,
not more. Here is an example, you can call Go Evil and tell it to take the code from the
STD in, but here is how it works under the hood. From your Go code, from the command line, Go Evil
generates a full Go program, and so the dash E allows to print that Go program that has been
generated. It is sometimes useful when you want to debug the syntax around that you make, and then
the Go import equal allows to stop using Go import, because here you see that in that code,
there is no import of the FMT package, but it is introduced by the Go imports, which is called
by Go Evil. So I am announcing today that Go Evil has been, 1.0 has been released just a few
hours ago, and the new feature of Go Evil 1 is that Go modules are supported, and with Go module,
you get locked versions for your dependency code from Go Evil. So this allows to submit to share
your one-liners with other people, because the previous code that I showed was depending on
the dependency to be installed in Go pass. And so that's it. Try it, use it, report bugs,
and I'm available for question later. Thank you. It's weirdly enough, not the first open source
project to be released when people are in the dev room. If this is your slide, you can come up now.
Hello, everyone. My name is Keegan. I'm a staff software engineer element, and I've been spending
the past year debugging why Go servers are slow. So hands up, who's made a crud application before?
Create read, update, delete. That's basically everyone in this room, which is what I thought.
Who's tried to speed up their server before? This is a slow request, 3.6 seconds. Fewer people,
but still a fair number of people. Cool. Who's used PPROF before? So flame graphs. It's great.
Who's used runtime trace before? Not that many people. Okay. Who's struggled to figure out what
was going on when you're using this? Right. Okay. Great. This talk is for you. So the first thing
you need to really is use spans to make these traces readable. Very easy. If you've ever used
Jager spans before, they're basically the same sort of thing. So you can create a new task,
and then you get a new context. You pass the context through to new functions. You can create
regions from those, and you end up getting something that looks a bit like the stuff on the
bottom there. You can also add log lines for some contextual information. That'll appear on the UI,
which we'll get to in a moment. And the crash course in using runtime trace is you make a trace
in the same way that you'd make a CPU profile with PPROF, except you hit a different endpoint,
but you also tell it how long you want to trace for, and then you use gotool trace to open that
trace. You don't use the gotool PPROF, confusingly, and you'll get something like the bottom over
here, which is quite a lot of scary words and links, and you have no idea which thing to click.
The only thing you care about is the user-defined tasks. If you click on that, you'll see something
a bit like this. The only thing you care about is this GoRoutine view, and if you click on that,
you can profile basically everything. So, for example, here's a bit of a request,
which is slow because of garbage collection, and if you click on any one of those Gs at the
bottom, which are highlighted with the red circle, you'll see stack traces that mention GC. Also,
the blue bar in the middle there says GC, so spoiler. Other thing, if you have slow SQL queries,
you can find that as well because if you click on any of these things, you'll see stack traces,
and those stack traces refer to any point where the GoRoutine yields away for network IO or
syscalls or things like that. So, you can clearly see, oh, it's doing something with SQL, and it's
just doing the same thing for SQL for not particularly long here, only 20 mils, but still,
it takes a long time. You can do the same thing for profiling functions, if functions are being
slow, so you may, this is calling the same function over and over and over again, which it
probably shouldn't be doing in this particular scenario, but again, it depends on your actual
code as to whether or not this is the right thing for it to do. Sometimes that is normal
behavior, in this case, it's definitely not normal behavior. So, the TLDR is you should
probably use runtime trace next time and not CPU profiles. So, for me, I've sped up requests
that were taking 3.6 seconds to 96 milliseconds for the same request, and they're bottlenecks
from various different things, so from garbage collection to poor database queries and poor
computational complexity on certain algorithms, and some of these things will only be visible
if you use runtime trace. So, flame graphs don't help you for debugging slow SQL queries,
but runtime trace will do. Thank you very much.
Thank you. If this GitHub repo is yours, come to the stage. And you've got 10 seconds to
switch laptops. 10. No. And it works, which is a miracle for Linux.
Hi. I actually didn't create a slide, and this will be the fastest lightning talk in
my life. Basically, I just wanted to talk about the JSON package and the issue what
we faced with, and a lot of people faced with it. Basically, it's the... Have you ever used
struct with omitempty? Then, basically, this is where the issue come in, and that is an
open issue here, which trying to fix this, but it's basically abandoned, and it's a pretty
big issue because it's created in 2015, and there is nearly 200 comments under that. And
basically, I just wanted to make an attention on this ticket, because if someone fixing
this ticket, that means that, basically, you can do something like what I show you in this
code. So it's really hard with point. Yeah. Probably use this package, the encoding JSON.
I have a struct here, which is here. Thank you. Thank you. So this is basically, I introduced
a new struct, which is basically a new string, or something like that, and here I added omitempty.
In this case, I implemented the E0 method here, which says if it's not valid, then it's
basically a 0, so I wanted to remove it from the JSON. But if I run the actual code, please
run it. Live demo is in a lightning talk. You're brave. Yes, live coding. You see that
it's basically here inside the JSON, however, I wanted to basically an empty JSON. And there
is another implementation with exactly the same code, but I just created a pumpkin seed
JSON, which is exactly the copy of the built-in JSON. The only difference here that the issue
what I mentioned is basically suggesting an implementation that the omitempty section
of the built-in JSON should check for the E0 method, whether it's existing in the struct
or not. And if I run this one, it's basically doing what it should do. And basically that's
it. So this is something what I think should be implemented in Go and this ticket with
this number is basically showing actual implementations for that. Right now, most of them are not
declined but not processed. So I think if anyone has a good idea how to implement it
in Go, then basically it would be nice to put into this ticket. There are also, this
is the actual change request in the code language what the guy made and I just copied
his code. Yeah. One disclaimer, the pumpkin seed JSON package, you shouldn't use in production.
And that's it. Thank you. If this is your slide, come to the stage.
All right. Hello. My name is Michiel. I created Mox. I've been working on this for quite some
time. I started using it two weeks ago, released it earlier this week. It's a meal server.
So I'm curious, is anyone here running their own meal servers around the main? One, two
persons? Wow. Okay. Three, room for improvement. So let's go right ahead. This is the tagline.
It's a modern, full-featured open source secure meal server for low maintenance self-hosted
email. So let's break it down. It's modern because it supports all the latest meal standards
and there have been added quite a few over the years. It is full-featured in the sense
that it aims to do everything at once, meaning all the relevant email standards. So you just
need this one thing. You don't need a whole bunch of components to make a working system.
So just really to make it easier. It's MIT licensed. It is secure, meaning it supports
all the latest security things about email like TLS, et cetera. And of course, a bit
of secure coding and low maintenance. So you actually started using it because I hear many
people are moving all their email to the cloud, some big providers because it's too hard apparently
to run a meal server. So it's for your self-hosted email. Email is one of the oldest decentralized
messaging protocols, but we're making it more centralized by moving everything to the few
big providers. So Mox is an attempt to make it so easy that you will all start using it.
So a bunch of features, a list of acronyms. IMAP, so you can access your mail, SNTP, so
you can send mail. Nowadays, if you want to send mail, you need to configure SPF, DKIM,
DMARC. Does anyone know what that means? Yeah, see, that's good. Automatic TLS, so you don't
have to worry about any certificate stuff. So it's like the caddy for email. TLS reporting,
MTA, STS, that's one of the latest additions to secure email. There's a reputation-based
junk filter in there, so if you receive messages from people and you don't like those messages
and you mark them as junk, the next time those people send mail, it's rejected. So new senders
don't have any reputation. You can look at the content, so there's a content-based abyeasing
spam filter, so in there. Internationalized email, so you can have smileys in your domain
names, that's what you want. And auto-configuration, so you get your thunderbird, and setup is
just instant. No need to worry about all the port numbers, et cetera. It just works. So
getting started, of course, now you're all convinced you want to use this. Luckily, there's
a quick start. You just set up a Linux machine, probably, get your email address for your
domain, and you get a configuration file that's all, that has this all configured. You just
can start it right after. Not only does it make a configuration file, also print some
commands and all the DNS records that you need to create, so you don't have to think.
You can just copy, paste, and be happy. Then the code, 40K lines of implementation, 10K
lines of tests, quite some test coverage. There's integration tests, fuzzing tests.
It's all pure Go, no C Go, just go install, cross compile, all the good stuff that you
get from Go. The implementation is heavily cross-referenced with the RFCs, so both ways.
You can go from code to the RFC and back from the RFC to the places in the code where it's
used. So this is supposed to help with maintenance, so it's implementing all these protocols,
and it gets a bit overwhelming to understand all of that. So if you would code it once,
you cannot go back to the specification and back to the implementation. You don't know
what's going to, so how you, how to fix bugs, et cetera. Let's move. Oh, wow, quick.
So what's next? I just released it. I'm looking for feedback. Please use it and tell me if
it works for you or why it does not work for you. So I aim to make it very simple, so if
you find something that's not simple, let me know. Of course, if you find bugs, let
me know. And this is where you can find it. All right.
Thank you. If this is your slide deck, you can come to the stage. If this is nobody's
slide deck, I'll just skip it. Something with Postgres. If this is your 404 page which you
sent to me, please also come to talk to me. So yeah, also the speaker is not found. That's
the thing with last minute talks. Then I had one backup speaker. You can come to the stage.
And the gophers are also falling down. They are tired. Understands me too, me too. Yes,
I have HDMI. I also use USB-C. Let me just close this down for you. That's 4G clicker.
Okay. So thank you, first of all. So I want to tell a go-of-story and why we use Go to
have to implement this idea of fluid pull requests. Before starting with that, I need
to talk a little bit about pull requests. So for that, I brought Robin and Kat with me.
So Robin wants to contribute to a project that Kat is a maintainer. And what everyone
does or at least they try to, they open a branch, they create what they have to do. And
then at the end, it comes a time when it needs to merge into main. And then when Kat comes
in and says, wait a minute, we need to review those changes. So this kind of methodology
is important for critical contributions from interested parties. And it's well-known as
open source projects, especially with the name of pull requests. We also use it inside
our own companies. But it's well-known at the open source community. And it's quite
popular. As you can see, in 2021, we got a lot of pull requests. And the process goes
like you do whatever you want to do. Then the CI triggers, you get the review, you get
some feedback, and then you have to apply the feedback. And we enter a loop here until
someone decides that it's good to go and we get our approval. Then it goes to merge and
that everyone is happy. And the problem here is that Robin goes through this process every
time, regardless of the type of change it is. And we are unavailable with the fact that
Robin and Kat have been contributing and working with each other for some time. So this idea
that all pull requests are the same can be actually improved. For instance, this scenario
where Robin is just trying to do some configuration change, why do we need a pull request? Maybe
we can just go directly to main without a review. Another scenario where Robin just
gets an API with some documentation or some warnings. Let's imagine why can it go to main
and then we can do a review afterwards. And then when it comes to critical changes, then
when we want to stop the process and say, okay, this is critical, we need to have a
very good review here. And maybe instead of just asking one guy, we can ask two people
for them to get their own approval. So this idea of pull requests is that all that I just
said could be defined in rules. And we can apply those rules into our own process and
minimize the time. That's where we came with the review pad, which is done on go and it's
full open source. And that's where we can define all these ideas of what are the rules
for our team. So here's how we could work with this terminology. Behind this is go,
of course, then it can, for instance, if my changes are all on markdown files, I want
to merge my pull request right away. So no review. If, for instance, my author actually
is considered a new joiner, a new joiner could be someone that didn't do 10 PRs, like Spotify
does, I want to assign a reviewer from my tech leads. And then, for instance, if I want
to get some compliance, make sure that my pull request is an issue. I can confirm that and
make sure that the user gets notified as soon as possible in order to iterate on that. And
then we can do some more incredible things. I want you to look at the line at the top
where we have an annotation saying that it's critical, saying that every time someone changes
that function, that function is critical. If the function is critical, if my code touches
a function that has this annotation, then I want to trigger my pull request review that
is for critical changes, like I want to assign a label, I want to send someone from the tech
list to review it, and I want to notify join, which is the tech architecture. Okay, we
had a talk this morning about reducing cognitive load from Federic, and I want to show how
we could do that with this terminology. So here's how we could look into line of sign
and make sure that if someone uses a lot of tabs, so it means that we have a lot of loops
between each other, if and else, we can actually send a warning to the user. For instance,
our error validation, making sure that they don't use string contains for errors or equals,
but they use error is. And last one, the mysterious Boolean, making sure that no more than one
Boolean is used in the function signature, that's pretty much it, how we could use to
make our lives easier on pull requests. Thank you all.
Thank you. The last lightning talk of the day is from me again. What do we want to talk
about today? Well, two subjects, what is naming God? No, I want to talk to you first of all
a big thank you again to everyone. First of all, to all speakers who came here today to
give an amazing talk, standing with a lot of stress to say things. I also want to thank
Eva again for helping me out. I also want to thank the two FOSDEM engineers in the back
who made our audio video work all day. I want to thank the people from FOSDEM who brought
me food today. I also want to thank everybody at FOSDEM. And I also want to thank all the
volunteers. I think they are left right now. Who helped us with video, even what they couldn't
solve today. Thank you very much. Thank you all for coming, by the way. Thank you for
staying so late. Thank you. And now my second subject. Which is that Go is a garbage collected
language. And you know you can trigger the garbage collection by doing runtime.gc. So
when the time is 19 o'clock, I want you all to do runtime.gc and grab some waste you see
around it and put it in any of our bins. But I think Eva wants to say something. Yes.
Thank you. Thank everyone that has been here to help you. But without you this wasn't possible.
So a big thank you to Marcia. And thank you for coming.
Thank you.