It really depends on what you understand as digital disruption, so unfortunately I'm not really sure how to answer.

If by digital disruption you mean the impact on society of a new technology, I doubt that Go has had any specific impact (or at least that I can think of).

If you include the way we write code ... Go powers Docker and Kubernetes, so there's some big disruption right there.

I think I partially answered your questions here: hashnode.com/ama/with-francesc-campoy-flores-cjos…

But I wonder what future proof really means ... Go is a pragmatic language, therefore it's been designed to solve the problems programmers have today.

It is pretty obvious that those problems will eventually change, and that the way we write code will have to evolve. I'm thinking about really disruptive changes like commoditized Quantum Computers.

Once Quantum Computers are the norm, will Go be able to run efficiently on them? Probably not, but I might be wrong.

In that sense no procedural programming language is really future proof. Other programming paradigms might be better suited to these changes, since they are at higher levels of abstraction! Functional languages are a good example of this, but probably Declarative or Logic programs (like Prolog) will be much better at adapting to different technologies since they were designed from a completely different point of view.

That's an interesting question, because the biggest challenge here is not necessarily Go as a language but rather the design principles behind Go's runtime.

I'm unfortunately not an expert in the topic, since I care more about the way you use Go than the way it's implemented, but Go does require an OS normally.

But ... there are some efforts on implementing a kernel in Go! I'm not 100% sure of how this works, but I'll leave the project here so you can have a look: https://github.com/achilleasa/gopher-os

Ok, so first of all I don't think saying npm lacks security is fair. They're probably one of the largest targets for attacks, so I'd say they've been doing quite amazing even though there's been a couple of bumps.

That said, indeed the Go ecosystem doesn't have the abundance of packages of node.js, and this can be an issue for some problems that you might want to solve. But in general, I'd say there's enough Go packages that creating most programs doesn't require building everything from scratch.

I guess the big difference is how node.js embraces frameworks like node express, while Go shies away from them. This is more of a cultural difference rather than technical, I'd say.

Often, in Go, you'll see people writing web servers without any framework and I think that's not because of a lack of frameworks (beego, buffalo, etc do exist) but rather a sign of the quality of the net/http package itself!

Go does provide a lot of different packages to be used as toolkits rather than frameworks (e.g. the Gorilla Web Toolkit) and you can find them quite easily on godoc.org.

Is there any specific field of work that you feel Go packages are missing? I'd say Data Science and Machine Learning are two of them, but not sure node.js has a better ecosystem for those than Python.

Concebollista hasta la muerte!!

clarifcation: he's asking whether I use onions in the Spanish omelette, the answer is "duh!" 😄

Yes.

Is writing science or art?

When you're writing you need to follow some rules in order be understood, there's some guidelines on how to avoid complexity to make your ideas as clear as possible to any reader.

But writing is also creative and can communicate and create emotions on the reader's mind! Poetry is a great example of this, but not the only one.

I believe coding can be both: sometimes we want to keep it simple and write the most obvious and boring code we want because we prioritize clarity, sometimes we'd rather focus on writing "beautiful code" and that's also great.

The programming language you choose will help you go one way or another, obviously. But as in natural languages, beauty can be found anyway.

WARNING: I sincerely have no idea ... so this is pure speculation.

The blockchain is a distributed system, which means you're going to need to handle many concurrent events over a network. Luckily for Go, these are two of the things that you also need to be a successful language to tackle the problems that Google does.

So I guess it's nothing related to blockchain per-se, but rather to distributed systems such as the blockchain, but also kubernetes!

I sincerely hope Go 2 never happens.

This might seem a bit excessive, I know, but the reason is that having Go 2 would imply that somehow there's a non backward compatible change in the language.

This could cause the same kind of drama Python had when the migration from Python 2 to Python 3 was proposed. The amount of Python 2 code that is still running out there and that can't be used from Python3 is just painful. The community is finally getting back together, but it's been some rough years.

I really enjoyed this talk by Ian Lance Taylor (https://www.youtube.com/watch?v=LqKOY_pH8u0) since it talks about different ways we could have breaking changes that do not imply breaking the community in two. Basically how a single project could use some files in Go 1 and some in Go 2.

If that's the case ... let's go for it! But let's be very careful, please.

I think Go has a very bright future, but I'm also not fully attached to the language and I recommend doing the same. Attaching your career to any specific technology is always a losing bet.

I'd say my favorite thing is the effort on bringing generics. I've wanted them for quite a while, since they will empower gophers to write more concise code.

Imagine a library containing common concurrency patterns, or maybe even some functional programming concepts like reduce or filter ... the dream!

I don't care that much about the error handling, because I think that once we have good generics we should be able to improve error handling thanks to other concepts like error monads etc.

Oh my god you just made me laugh because today has been so crazy hahaha

I'm currently VP of Product and Developer Relations at source{d} so my day is a bit all around the place.

I do still code a lot and use our products, for instance yesterday spent my day coding Python and SQL to analyze the Kubernetes codebase with source{d} Engine (https://sourced.tech/engine).

I also meet with potential customers regularly to better understand their needs and how to meet them with our products. This is somehow right in between Product Management and Developer Relations if you think about it! Since our users are often developers, the empathy required for Product Management is actually basically the same skill needed for DevRel!

Other than that I travel a lot ... too much even. I'll be in Seattle next week to attend KubeCon (say hi if you're around!) and on Friday I'll be running a workshop at Disney in Burbank. I am platinum with Air France, premier 1k with United, and pretty hight status too with American. This is not bragging, but rather a call for help 😅

On top of that I try to have my own hobbies so I still play piano often (you might see some tweets on that from time to time), plus hit the gym at least 3 times a week 🏋️‍♀️

github.com/golang/go :)

There's some packages that I've never ever used ... I'd say any of those!

A good example of this is anything below https://golang.org/pkg/container/.

On the other hand the net package is incredibly well designed! The context package is also one of my favorites, not because of how it's used but rather because of how it's implemented.

I made a video on that, btw!

https://www.youtube.com/watch?v=8M90t0KvEDY

Hah, great question!

Channels are more about communication and synchronization than streaming data, tbh. Everything you can do with streams you can also do with channels, but take into account that the result will very probably be much less efficient.

This is due to the inherent complexity on making things work correctly across multiple goroutines and threads.

If you want to write with streams in Go, io.Reader and io.Writer are your friends!

For instance you could do something like:

1. http.Get on a url that serves a zipped json file, that returns an http.Response
2. Create a zip.Reader reading from http.Response.Body
3. create a json.Decoder reading from zip.Reader
4. io.Copy from the json.Decoder to os.Stdout

This will start printing the first decoded objects from JSON before you're actually done downloading the file if the network is slow enough!

So if you wanna do data streaming use io.Reader and io.Writer, if you wanna do synchronization of workers sharing tasks channels.

For the synchronization of tasks, check out this talk by John-Graham Cumming!

https://www.youtube.com/watch?v=woCg2zaIVzQ

If I was to learn Go today I'd probably try to learn it the same way ... by joining the Go team! Hahaha

I'm not kidding, that learning experience was amazing and I recommend it to anyone that has the chance to try.

But more realistically I'd say a good idea is to simply start writing Go, as much as possible, even when it doesn't really makes sense! My first program in Go was something that I would have normally written in bash, a bunch of calling other commands and pipes, etc.

The next step is to share that code and seek feedback wherever you can (the gophers slack is a great place for this)! I do code reviews on http://justforfunc.com from time to time, so make sure you send your code for consideration at http://form.justforfunc.com.

Code reviews are actually my favorite way to learn, because you're getting feedback on what you're doing wrong! So you already have the context and the knowledge is absorbed much more efficiently.

That said that's not always possible for everyone so if you want to know websites and books to read:

• excerism.io: great place to exercise your coding skills in Go and receive feedback from the rest of the community
• adventofcode.com: a great way to find problems to solve in Go! also you'll be able to see many other solutions, which kinda counts as getting feedback I guess.
• Dave Cheney's blog posts are a jewel! https://dave.cheney.net/category/golang
• justforfunc.com ... I've heard it's pretty decent 😎

Regarding books, I'm not much of a book reader when it comes to programming languages ... other than "Learn you a Haskell for a greater good" which is amaaaaaazing!

I'd say the cannonical book is "The Go Programming Language" by by Alan A. Donovan and Brian Kernighan, but I'll admit I haven't read it completely ...

It is indeed kind of hard to do it here! hehe

First the things I like about both is the fact that at the end of the day, no matter which one you're using you can always end up exposing the vendor directory therefore letting your users simply use your code without having to care about your choice for dependency management.

On the other side dep is not integrated into the go tooling as much as modules (for reasons that belong more to political rather than technical conversations). This means that eventually everyone will be able to use modules natively without having to have an extra tool ... and we know programmers are lazy!

So yeah, I'd say modules and dep are both solutions to the same problem, but given the fact that modules is already integrated with the official Go tooling I do not think dep will be popular for much longer.

And that makes me a bit sad, because the team of gophers behind dep is amazing! Great people and great coders. The show must go on, as they say.

Since I joined source{d} I've been doing more and more data science and machine learning ... which has driven me back to Python.

I would have loved to be able to write those things in Go too ... but unfortunately things like tensorflow and pandas are not available in Go.

Ok, tensorflow kinda is ... but not really, you can't do any training with it anyway. Gorgonia is worth having a look and I think it might eventually become a great option but the biggest challenge on using it right now is it's documentation.

So ... I guess I want pandas in Go? It could be called gophers! 😅

Code as much as possible in as many languages as possible and have fun!

Programming is all about creativity :)

Hi Jill!

I'd say this answer has already been answered here: hashnode.com/ama/with-francesc-campoy-flores-cjos…

But let me know if you have a follow-up question :)