>> The official Go User Survey showed that
Visual Studio Code is
the most popular editor for Go development.
Features like smart code completion,
debugging support, and extensions
for Docker could explain why.
Ramya is here to show us what the Go
Developer experience is like in VS Code,
today on Azure Friday.
Hi, everybody, I'm Erik St. Martin.
Today on Azure Friday,
we have Ramya here with
us who's going to talk to us about
the development experience in VS Code for Go Developers.
So, welcome, Ramya.
>> Hi! Thanks.
>> So, excited to have you here.
>> Very happy to be here.
>> So, what do you got to show us today?
>> So, we'll talk about the Go support
in Visual Studio Code.
I'll start from a basic Hello World App
and build that up and show
you all the cool things about it.
>> Excellent.
>> All right. So, as you can see,
this is the Go extension in the marketplace.
There are a host of language
features that can help you
in your day-to-day development,
be it if you're code editing,
you're navigating your code,
you're testing your code trying to
find errors or if you're debugging.
We have something for each of these areas,
and we'll touch briefly upon each of these today.
I know I have a utility for strings called stringutil,
that's a custom package and oops!
Typo. Let's do that.
>> We all still do it.
>> Yes. So, what I wanted to show here is you get
the completion even if
the custom package is not yet imported.
So, I see that reverse string there,
so I'll choose that.
>> So, this just scrolls your Go path looking
for anything that you might actually be trying to import?
>> What I do behind the scene is I already know
the package name and I slip it in and then call Go code,
and Go code does the rest.
>> Got you.
>> Yeah. So, all right.
So, let's reverse our string here,
that's what's hello in reverse. That should do it.
All right, but there's no use just doing that.
Let's wrap that up in a print statement.
Okay, that looks good.
Now, at this point, you can hover
over any of the symbols and you will
see the signature as well
as the docs associated with that function.
So, that's very helpful if you want to
quickly know what each
of the symbols are doing or how they do it.
We use this Reverse function but we
don't really know what it does.
I mean, can we really trust the docs over here?
>> Of course not. >> So, let's go see what it does.
So, you can "F12", that takes you to the actual file.
So, let's do that,
and looks like it's pretty much doing what it says.
Take the string, reverses it,
gives it back. That's good for us.
Let's see code navigation wise what else we can do.
You can do a find out references,
that will show you a pic window right here giving
you all the places where this function was used.
What's the next thing we want to see?
Let's see what the extension does in
the area of errors and warnings.
So, let me introduce an error,
rune becomes something else. Let's remove the comment.
We all know what happens now.
Linter is going to scream at us saying that
an exported member needs to have a comment.
You can see you have these squiggly lines
saying just the same.
>> Now, this is great that it actually does
the linting stuff for you in line.
>> Yeah. So, what happens behind
the scenes is on every file saved,
by default, we run build,
we run linters, and we run Go bet.
So, and the reasons of all those are shown
as problems in the editor.
Where the aptly named is the problems view right here.
So, this shows all the errors and warnings in your files.
So, here I am using F8 goes to the error,
another F8 goes to the next error or warning.
>> If I want to jump the next phase.
>> Yeah. So, you can imagine
again if this is a large file,
you have errors say up
somewhere and then some were sparsely down you
can just F8 your way around it
instead of scrolling around
and seeing where the error is.
>> Now, is the problem for you
just for the one file you're working on,
or is that for the entire package.
>> Good question. So, by default,
it works on the package you're
currently editing because when
you save we build lint and read the current package.
So, if you have multiple packages and
you've opened all of that in VS Code, run,
go build workspace and that'll build
everything and all the errors
would show up in the problems filed.
>> Owesome.
Let's go to the test file.
You could either go to the "Explorer"
or find it or just open the file.
Another handy way to do it is
this toggle test file method here, command.
So, you toggle it and you land
in the corresponding test file.
If you did not have a corresponding test file this
would generate the file for you and
have some placeholders and test
skeleton's for each of your exported members.
>> Sort of like a template of...
>> Yes. We use behind
the scenes a toggle called Go test for that.
>> Okay.
>> It was a community integration,
that's a very cool feature people love it.
>> Less typing is always great.
To run the test, there's a bunch of commands based
on whether you want to just run the single test,
all test in a file,
all test in a package or all test in your workspace.
So, you use any of these commands for that or.
>> I'm already seeing some fun links there.
>> Yes. There are these handy links we
call codelense above functions.
So, you can just click on that
and it'll run the tests for you.
>> This is just the single one for that particular...
>> Yes. But you also
have these run file test that will run
all the tests in the file or run
package test which will run all the tests in the package.
>> So, they're just going to set up the package file.
>> Yes. So, the debug
test right there next to the run test codelense.
Let's see how easy that is.
So, I put a break point there.
I click on "Debug".
There you go. Break point head.
So then I can use this handy bar here to step in,
go over the loop,
step out, keep continuing.
Since there were three test cases,
it went through all of them.
There you have a debugging,
the test as simple as that.
Remember everything that I do using a mouse here,
you can use keyboard shortcuts for it.
Everything that's in the context menu has
a corresponding command in the command pallete,
so, any pick,
however you want to use VS Code you can use it.
We did debugging test,
but how about debugging the actual program,
is it that easy as debugging tests?
Of course, it is. So, we're here back in Hello Go.
So, I just press "F5" right now and that's it.
Delver started in the background
and you hit your break points.
You can do the same dance again.
You can go over things.
Step out, step in,
continue the whole shebang.
Now, let's take off the kid gloves.
Let's go on to something more complicated.
Let's talk about a Web App.
I have another project here.
This is from the Golang example repo.
What this is supposed to be doing is run
a web server that will tell you whether
a particular version of Go is out yet or not.
That's why it's called Out Yet.
So, let me see what this does.
I'll F5 this. So, it is running.
Okay. I go to the browser,
the localhost:8080 and there it is.
That's the thing that it says, 1.4 is out.
>> That went on for a long time.
>> It has been on for a long time.
>> I Hope nobody is asking that still.
>> Yes. Let's fix that actually.
So, 1.4 was a long long
time ago. Let's see how to fix that.
So, probably that 1.4 is handcoded somewhere right there.
It's a parameter to this function.
Sorry, to this program.
So, if I'm debugging,
and I want to send a parameter to the program.
How do I do that? A simple F5 won't help here.
So, we go to "Configuration".
So, here on the left side you click on this.
This will create a default debug configuration for you.
What is interesting for us right now is this args.
So, let's pass that arg.
What is at 1.11, is it the hot new thing.
Let's try that. Coming back here.
So, I want to set some breakpoints
right before we solve the page.
So, let's do that and now I F5. That's running.
Back to the browser,
breakpoint head. So, that's good.
What's the data being sent?
There's a URL and there's some data.
Let's go back to the browser and see it.
>> That's awesome. So, when you hover
over the data it actually
tells you what's past, what's the value of that.
>> Yes. So, all variables you can just
hover over it to see what the values is or on
the left hand side you have all the local variables.
So, let's continue this thing and see if 1.11 is released.
It's not. So, now we go to production.
Let's containerize this thing. Right?
So, for containers,
we have this handy extension called Docker.
This is what we're going to use.
You can imagine generally
if you were to start from scratch,
you have to create the Docker file,
decide whether you need to compose up, compose down,
whether you have to remember
all the command line arguments which
is great for some people but not for others. Right?
So, we try to make it easier for you.
So, the Docker extension has this whole view for itself.
Let's see what I can do with it.
So, in the commands,
I have the first thing I'll do is
add some Docker files to this workspace, right?
So, I'll choose that, it gives me a set of options.
I'm going to go with Go because well, Go.
Let's chose that.
Give it a port,
and let's see, did it do something?
It did. It created these files.
>> This is perfect because I hate
typing those every single time.
>> Right. Yeah. So, now it's just one command away.
So, let's see what it did.
This is the Docker file and it's a multi-stage build.
You use one big image for a building and
then a lighter image for actually running
the app. So, that's good.
Let's see, can we build this image?
Okay. Choose the file,
tag it because you have to tag.
So, you can see the progress here in the terminal.
It did everything it has to do,
and I can see there it is.
A few seconds ago I have the Out Yet image build.
>> This is going to make me use the terminal a lot less.
And I'm a terminal person.
>> That's my goal. So, okay back to this.
You can now run containers
from using this image either from
the command pallete or if you're out of context menu
kind of person, just say run.
And this runs again, you look at the terminal,
it does what you usually do with the terminals without
the command line arguments and here's your container.
It's running. The green dot says it's running.
It would be red if it was stopped.
>> Now, all of this is just interacting with
Docker that's running on your local system.
>> Yes yes.
So, we have the container running.
Let's test that.
It's back to 1.4 again because now it's running from
there using the default argument.
Let's see if we can change that here.
One of the files we created for
you was the Docker compose.
So, here is where you can change
or pose extra things to your Docker file and run it,
right and customize it.
So, let's change the entry point and
pose the argument. All right.
So, let's see let's stop
this container and that's stopped and gone.
Let me compose up. Oh! That was done.
Sorry. Docker compose up.
I'll choose the file and there you go.
I have another container running.
Now, this should be using 1.11. There you go.
>> It works.
>> Still bad news.
>> Still bad news but.
>> It would have been awesome.
>> It is news.
>> In the middle of our conversation it came out.
>> Yes. That would have been great. All right.
So, we had compose up,
that means there's compose down and you bring it down.
So, that in a nut shell or a very large nut shell is what
everything you can do with
VS Code and Go and the Docker extension.
>> Well, thanks so much for coming in
and showing me all these cool new tools.
I'm going to have to play with.
>> To check out what else you can do with the extension,
just go to the extention's view click on the "Extension".
This is the same read me that you can see on the website.
But more interesting is the contribution sections.
All of these are settings that you can use to customize
your own VS Code instance and of course the change log.
>> Awesome. Well, thanks so much.
We're learning all about the development experience in
VS Code for Go developers on Azure Friday.