This course has been updated! We now recommend you take the Basics of Go course.

Check out a free preview of the full Go for JavaScript Developers course:
The "Go vs JavaScript Comparison" Lesson is part of the full, Go for JavaScript Developers course featured in this preview video. Here's what you'd learn in this lesson:

Brenna explores the differences between JavaScript and Go in terms of types, structures, conventions, and error handling.

Get Unlimited Access Now

Transcript from the "Go vs JavaScript Comparison" Lesson

[00:00:00]
>> The next thing I want to talk about is some of the more peculiar aspects of the language. As we work through examples, there are few obvious differences between JavaScript that I want to cover off the bat so as we run into them, we're a little more prepared.

[00:00:15] The first we'll notice is typing, and some of the big words are string, integer, float. And so when you're defining variables, whatever variable that type is or whatever type that variable is, it needs to stay that way for the rest of the program. So you can't define a number and then be like, just kidding, I want that to be a string down the road, once it's a number It is always a number for the life of the program.

[00:00:34] In JavaScript because it's dynamically typed that's not the case, you can redefine a variable called name to be set of numbers if that's how you feel like living that day. You will find that there are a lot of similarities to how Typescript looks and feels, so if you're working in Typescript at all, there are some familiar patterns between the two.

[00:00:53] In terms of structures in other languages, if you're trying to turn JavaScript into more of an object oriented language, a lot of times you'll think of ES6 classes or React components that encompass both behavior, functionality, properties, types, and stuff like that. And in Go, those structures we're gonna be talking about are structs, pointers, methods and interfaces.

[00:01:14] Both of which on both sides have to do with encompassing and encapsulating some of the code around what an object or what something is trying to do, and how it's described. Error handling is a particularly interesting part of the Go language, in JavaScript it's built in, exceptions are gonna be thrown as you're writing your code, and you don't have to do a lot for those to appear it'll be pretty obvious.

[00:01:37] In the go language, you have to be extremely explicit, so errors are treated like values rather than exceptions, and so for you to actually manage that you need to capture that error and then decide what you wanna do with it in a very intentional way. Another way to think about writing Go is starting with all of the sad paths, so if you're writing a function, you handle all of the sad paths with your error handling as you go through the function.

[00:01:59] And then that last line of code should be, if everything goes great, you've already handled all the things that could go wrong, what do you want the function to actually accomplish? But it's a little bit of a different way to structure, what you expect to happen. In terms of multitasking, JavaScript is single threaded, and it is notoriously difficult for asynchronous behaviors, you're talking like callbacks, promises async await, a variety of approaches to try to make this less painful.

[00:02:24] And in Go we have a couple of tools around Go routines, sync packaging, multi threaded, pneus with concurrency that's actually really seamless and is a really powerful part of the language. And then lastly, we've got some opinionated-ness, the Go language does have strong opinions around syntax and style as you're writing your code, there are built in linters that are one size fits all.

[00:02:49] In JavaScript we do have a little bit more control over which linter do we want? How strong do you want it to be? What are the ESLint rules you wanna turn off? And that's not the case with Go, it's kinda just like everyone does it the same way, which does make it super great.

[00:03:01] Because when you're looking at a new code base that you didn't write, it looks like your Go code, which can be a really positive aspect of the language.