From Russia with love

Nope, it's not a review for the Bond movie. It's a story about how I got in love with an event that I've recently took part of and the community of developers behind it.

This past weekend I was lucky enough to be one of the participants and speakers at GDG DevFest Novosibirsk (Siberia).

What is a GDG DevFest? A series of events that happen once a year throughout the world. They are organized by the GDG Chapters (meetups) in a city or region and bring together the developers like you and me that are using Google technology like Go or Android in their job, day to day life, for side projects or just are interested in what's the latest and greatest on the forefront of technology.

It was one of the best conferences I've been too so far and let me tell you why.

At a fist glance, many, especially those who aren't familiar with that part of the world will probably react along the lines: Siberia? Are there any developers there? Turns out there are, and quite a few while at it. From a city of about 1.5 million people, there were more than 500 participants to the event. And I should mention that this is the first time the event is happening, in what I hope to be a long series of such events.

My experience with the conference begun a few months ago when my dear friend Natalie told me about the event and the Call for Papers. She spoke highly about Leonid, one of the organizers she met during Google I/O 16 and how the community there is a really good one. After applying with a few proposals, I was selected to present the Go 1.8 release notes.

I was thrilled about this so the process for getting a visa started, I've got the approval for holidays from my company and the day of the flight arrived. This was my first trip to Russia and the farthest Eastern place on Earth I've been so far.

At the airport I've met Denis, one of the organizers. During the hour long drive from the airport to the hotel near the conference place, we've talked a lot about the event, the developer community there, the companies that are there and many many other things. It was an eye opening experience.

Once we've got to the hotel we've met with the first few other speakers: Tanay, Edward and Daniel. As the evening approached, we went to the conference venue to get a sense of it and participate in the Go meetup. Me and Natalie had a quick workshop on how to get started working with Go, which the attendees were very quick to implement and a nice discussion ensued based on it. Then Alex, a colleague of Denis, presented how he and his colleagues at 2GIS (a local version Google Maps and not only) are using Go, DEIS for their automation, infrastructure, microservices and why.

The meetup was a very good signal that I had to step up up my slides and talk as the local community knows their way around Go very well and are eager to learn even more.

Next day the conference began and the I've realized that 500+ people mean and how coordinating this can be a small nightmare. A "nightmare" which Leonid and his team handled extremely well, as this would have been a thing they are doing on a day to day basis and it's just clockwork.

Having missed the keynote from Marcelo, which everyone was referring to even Sunday afternoon, I've joined Daniel for the Data Science Training session. To those interested in using Go for anything "big data" processing, I highly recommend getting him or his colleagues from ArdanLabs. And if you'll be lucky to attend Daniel's course and see his passion and determination to teach everyone and make them successful to correctly analyze and interpret data (and use Go while at it).

I've then moved into the room where Natalie gave a talk about the Women Techmakers Berlin Chapter (a GDG Chapter focused on diversity in technology). I knew a bit about the subject but seeing Natalie on stage, talking about it to a room packed full of people, was inspiring. During the presentation there was also a surprise announcement about the new WTM Chapter in Novosibirsk as well as a WWG Chapter that will be lead by none other than Elena, one of the co-hosts of the GolangShow podcast.

If you don't know about GolangShow, it's a Russian weekly podcast about the latest and greatest in Go (I also think it's the oldest podcast series about Go). Talking to Elena after the presentation turns out that this will also be the home of a new GoBridge Chapter.

There I was, at a totally non-Go conference speaking about Go, GoBridge and a lot of other things. And I've discovered just how big the podcast is and the efforts behind it, as I knew about it from Vlad. We came out with a few ideas out of our talk which were about to be reinforced and extended in just a bit as we've met Andrew from Bishkek that started roughly with: "Hey Florin, I want to help out to get GoBridge and content to our community in Kyrgyzstan. How can we do make it happen?" I think this is a resounding signal that Go is growing faster than ever and the efforts that the community is doing right now will send shock waves not only in time but in the whole industry as well. With the upcoming London training at the end of January and many many more things in the pipeline GoBridge is getting also a lot of traction and it's a great feeling to see that diversity matters to all Gophers, new or experienced. But back to the conference for a bit as there's even more Go stuff happening in the second day. Who knew?!

The first day ended with a small party and it provided yet another good way to interact with Go users from everywhere as well as socialize a bit more with other speakers and organizers.

Second day began with Natalie talking on the main stage about Developing Apps for developing countries (#appsforafrica if you want to search for it on Twitter). I only wish I'd had more time to dive into this as well as the presentation surfaced so many things that you'd not even consider about at a first glance. If you are an apps developer, or searching for an idea for an app / start-up, I highly recommend watching this talk.

After the presentation I jumped back in the speakers room in order to add a surprise to the slides as well. Since the list of changes in Go 1.8 is quite big and I only extracted what I think it is interesting from the 400+ commits that happened in Go between 1.7.3 and 1.8 I could also move quickly through the slides and instead of having a full hour of me, I've invited Elena, Daniel and Andrew on stage and had an open Q&A session with them and the audience. Sadly we couldn't find the cloning device in time to also have Natalie as her flight was an obstacle. For those of you watching the recordings, some of the questions / answers will be in Russian. I felt this would be a good opportunity for everyone to remove some of the language barriers and allow them to express in their native language and from the feedback I had it was a good idea.

If you are speaking Russian I highly recommend watching the recordings from the talks that were presented at the event. While I don't speak Russian myself, I believe that having people clapping for healthy amounts of time at the end of the talks is usually a pretty good indicator something was right. Oh and hearing some of the topic names being mentioned in the conversations / passing by others.

I haven't touched too much the community part of the event so far but I've seen people having fun with VR apps, Project Tango, various challenges, smiling chilling out between sessions, hacking out a project and in general having the rooms packed. And no, I'm not saying venue was not great, quite the opposite, I think if the even would have had 2x the space, the rooms would still have been packed. What was good was also that there was a diverse crowd that attended the event. And contrary to what they say, Russians do speak English very well, but for some reason they are sometimes too shy to do it.

I could probably go for hours describing how cool the co-working space in the building the event was looks like, or how the organizers where always there to help with the most stupid of issues I've had (from some minor medical issues to breaking my glasses, yeah, that happened). Or how for being the first time this event happened I couldn't see that in any parts of it, everything that I could see was spot on. The Go community in Novosibirsk is a very welcoming one, how they value deep technical questions and are happy to help out newbies starting with the language. Or how the new chapters dedicated towards increasing the diversity are among the first in Russia from for organizations like GoBridge, WWG and WTM.

But probably as much as I’d love to I wouldn't do justice to what's a really amazing corner of the world. I would definitely recommend visiting it, and if you don't like -30C they have +30C during summer.

I'd like to end up thanking Natalie for pinging me about this one, Leonid, the lead organizer of the event for all the help I've got from him, Denis for being there to pick up and drive around what would be otherwise be known as a frozen gopher now, to the speakers and attendees and last but not the least to the whole organizing team for all the efforts behind this event. I hope I’ll have a chance to attend next year as well (but I'm afraid that it will be even bigger next time!).

Edit: Oh, to see what you've missed and what to expect next year:

https://vk.com/video-52955676_456239020

and

https://vk.com/video-52955676_456239021

Edit 2: Updated some links thanks to Natalie.

Why you should not use iris for your Go projects

Update:
To make this clear, this is my opinion and mine only. Nobody else was involved in creating this, nor does it have a secret agenda or anything like that. The authors of the mentioned libraries have no link to me nor should you go after them. If you have anything to say about this, please use the comments section below and I'll do my best to answer when needed. If your comment somehow ends up in a moderation queue, I promise that I will publish it as soon as time permits (and as longs as it's not real spam OR contains foul language). Thank you for understanding.

Update five:
Since my article appeared in the latest Go newsletter the following happened:
- the history of iris was rewritten (again)
- the project went from a lot of commits to a single squashed commit back to multiple commits
- I've been called a liar and a competitor of iris (not sure how since I'm not even remotely related to writing muxers or web frameworks for Go)
- I've been blocked by the kataras on iris so I can't properly defend myself against being called a liar, with video proof: https://youtu.be/e7ZnHH30zgo
- more importantly: the authors got their attributions back. And that's the single most important thing.

I apologize for everyone trying to use iris in the past days, it probably was your worst Go experience ever (due to so many rewrites). I can promise you that there are a lot better and more mature projects out there and these kind of issues have never happened to them.
You can keep reading if you want but at this point it's going to look like I'm a liar and a scum. So be it. But have a look at this: https://www.reddit.com/r/golang/comments/57w79c/why_you_really_should_stop_using_iris/ and https://www.reddit.com/r/golang/comments/57tmp1/why_you_should_not_use_iris_for_your_go_projects/ because honestly I don't have the time to fake all of this and I' more busy than you can probably ever imagine.


Update six:
Because once it's on the internet it's out there for good... How do you think I've faked this fork: https://github.com/KevinSjoberg/iris/ or this https://github.com/KevinSjoberg/iris/tree/46566b167b608ea926c9f92cb665273b7a2dfe13 ?

Again, with screenshots to make sure we have some more Photoshop skills to add to my cv:

I wonder how those folks got with that history like that :)

Original text:

I've said it so many times to various gophers I guess it's time to put it on a blog post: iris is a toxic framework and you should not use it at all.

Probably there will be people saying that I should write this but I see no other option as I have no power to simply remove it from the Internet. So instead I prefer to tell people why it's toxic and why they should stay away from it. Click here if you trust me and want to see the alternatives out there.

iris looks good on paper, it offers everything you'd need to do web development in Go but once you start using it you'll realize sooner or later that it has some fundamental flaws.

Lets start with the components it's stealing the code from (I'll come back to the stealing part later). The base package it's using is the amazing github.com/valyala/fasthttp which is a different implementation of the http protocol than the standard library net/http. The package authors make it clear in their Readme/FAQ section that the implementation is not compatible with the net/http one. What's more, they state explicitly that due to the design philosophy of fasthttp, certain corner cases net/http handles are dropped. But perhaps the biggest gotcha is that it currently does not support http2. You might say that's fine, you don't need it. But if you want to use any other technology such as gRPC, you are out of luck.
So why is this of any concern then for iris users? Because iris does not make this effort (at the time of writing) to make the users aware of these limitations.

Moving forward, another well known Go package iris is stealing from is github.com/julienschmidt/httprouter This has been well documented in the past: https://github.com/julienschmidt/httprouter/issues/148 and after all the efforts that the community had to try to fix this, the project relapsed again after just a few short months, see https://github.com/julienschmidt/httprouter/issues/160 You might argue that httprouter is open-source and it's ok for the author of iris to use it, and that's fine, the problem is that nowhere near the project you'll see the license of httprouter nor the attribution of code, as required by the license.

And these are just a couple of examples.

The thing that seem to attract the most people are benchmarks. What many people don't realize is that the benchmarks have been debunked a few good times. Take for example this PR to change the results of a well known benchmark comparing the various http routers Go has and read this comment and the following ones. Fortunately there people were not tricked by iris caching your responses. How would you feel if your API would suddenly get a cache without you asking for it? Probably in some cases it would be ok but what about cases where it's very important not to? Simply by having caching turned on by default, iris is not playing on a even field as as the rest of out there which allow YOU to have control over YOUR application, the way it should be. To this day the author refuses to acknowledge this.

People fear when they see those benchmarks that their app will be slow because of this. In reality, any project that will do a decoding from JSON, call the network the handler they execute or, worse, touch the disk the cost of the http router / net/http will be insignificant in comparison to the costs of handling the request. There are definitely projects that will have bottlenecks in various parts but realistically, if your http router appears in your pprof, please contact me as I would be happy to be proven wrong.

Let's look at the project from another perspective.

The first thing that should trigger a "huh, I need to look a bit more into this" reaction is: there is a single contributor to it. And it was always a single contributor. The author of the project actively rejects PRs and the occasional accident when a PR gets merged that contribution will be obliterated any time soon after, when the author decides to flatten the history of the repository (again). Which helps deliver the next point, API stability.
But before that, I'll briefly mention that the issues that are opened on Github are almost always edited to reflect a different reality, comments get deleted and conversations get locked. It happened to me (I admit that I could have done better in the initial message but I couldn't change things as my issue was instantly locked by the author and I couldn't do anything about it anymore).

The author is simply trying to paint a different reality than the one experienced by everyone else and this is dangerous. Will you trust your production code on this?

Back to API stability.
If anything, most of the Go projects that have been out there for a while can brag about the stability of their API. And for a good reason. Projects like gorilla/mux, httprouter, fasthttp, have a vast, rich history, filled with contributors. fasthttp mentions that things might break ocassionaly (and I have no statistics about how often that happens), but when used by so many people, they will tend to follow the "Go way" of not breaking stability to the best of their extent.
Even with the advent of a proper package manager, I think the authors of gorilla/mux will not suddenly start and break things apart because they can do so now. Oh and in the 3.5 years I've been using Go and I've first used gorilla/mux all the projects I've wrote can still compile against it. That's a really fantastic job from all the persons involved in the project.

If I haven't convinced you yet here's the last point.

The author now receives donations for iris. And don't get me wrong, it's within his right to do BUT... remember when I said that the projects iris is based at its core are.
There are other components which the author at least mentions briefly in the Readme (but again without mentioning their license) are in a state where I can't judge but probably they should be mentioned.
And remember the other contributors to the project? Ah, right, you can't can you, because there's no history to show them, to show their work, the fact that they've put maybe hours or more into getting something done just so that they are either denied or obliterated from history.

Here we are, at the end of this rather long article, probably left with a question, what should you use instead then?

There are many projects out there which are great and can be used, but as always, it always depends on your needs.
Someone was asking last night what framework should he use for a four pages and a form website written in Go. For that, net/http should be more than enough to handle but here is a list, not exhaustive by any means of projects I think can fit the needs of many (if not all) devs out there:

- net/http -> obvious choice for very simple projects
- gorilla/mux, julienschmidt/httprouter -> for anything else.
- there are more out there and probably some are just as good but I don't have experience with them so I can't recommend them. I've seen people using: pressly/chi, some using labstack/echo and others having various other choices

They can all be used with things such as urfave/negroni or GoKit for handling the middleware part of your apps. negroni is pretty simple to use GoKit can look a bit intimidating in the beginning but it's is extremely powerful.

For databases, if you are using SQL then jmoiron/sqlx is an excellent complement to the database/sql.

These are all components which play well with the standard library, follow established patterns and above all, are composable, one of the best features of Go.

You might feel that you need a framework, especially if you are coming from another programming language which has terrible support for HTTP interaction, but I can assure you that once you've experienced how things are supposed to be done in Go, you will feel liberated and the control you'll gain over how your application works will be unprecedented.

In conclusion, iris could have been a nice project, maybe even an interesting one, but all the issues that the project leadership display from cheating to stealing makes it a no-go. There are plenty alternatives out there, all brilliant, all truly open-source and all ready to be used in your next Go project.


Update:

On 17/10/2016, the author decided to make a PR to have a his library added again into the awesome-go collection. When things didn't go his way, the following happened:
- he changed his github handle to then revert to the previous out. If you've had problems fetching iris, that's why it happened
- started using language that is really not nice (see below)

(this was taken literally after the Github comment appeared in the UI, you can recognize the nice glowing yellow)

- there have been other heavier words exchanged, as you can see from some other replies, but I would not advise using them.

This just proves once again that in a simple conversation, when things don't go the way the author desires he will just revert to primitive language and he would rather have things broken (see the renaming that happened) rather than try to work his way on this.

It's sad because I really don't enjoy doing this and I sure would have liked to spend my time doing something better for the community than writing these lines.

Update two:
Before the author figures out how to remove the closed PRs, here's a couple of those merged ones, as you can see, their authors do not appear in the contributors list anymore:

And this little gem:

Update three: typos :D

Updated four:

It seems the author has done it again and wiped all the git history and at least some libraries got their license added to the list.
I guess I should apologize to the users for breaking their repositories once again. Sorry about that.
Probably I'm going to be accused by him and his "followers" (strangely enough there are only 1-2 people, always the same ones) for lying and spreading false things in the next hours and this will continue for a couple more days.
This lasted about 4-5 months last time, back then someone else exposed the issue and the pattern seems to be repeating itself.
At least people get their rightful attributions meanwhile.

Using dependency injection in Go

There are three ways to handle dependency injection done in Go.

Explicit, by sending the dependency to your function / method call.



Creating a wrapper to handle injecting that dependency into the code of the of the which can then be used everywhere else in the application.

Adding a field to the structure you already have with the dependency you need.

I've used the log.Printf function especially because logging can become a dependency.
Instead of importing the "log" package then calling log.Printf every time, you should be inject that as a dependency.
This can be useful in order to allow the existence of two (or more) log levels or for swapping out logging libraries without changing the code itself every time you do it.

How to halve the performance of NATS?

Rename the subject from "a" to "MyTopicName" :)

go get for Github Chrome extension

As I'm a Go user and I frequently get packages from Github, I've made this little extension to help me out running "go get" quicker.

It works by detecting if the repository contains any "significant" amount of Go in it (using the Github breakdown of languages) and adds a button that you can click and have in the clipboard the "go get" command for that repository. There are a few options as well to control the format of the command.

It looks like this:

It's available here: https://chrome.google.com/webstore/detail/go-get-for-github/ahkfiobnoafagbaaghmbbopfdpdbaidi and the sources are available here: https://github.com/dlsniper/ggg Hope you'll find it useful.