GothamGo 2018 - Things in Go I Never Use by Mat Ryer

Things in Go I Never Use by Mat Ryer
Go has a lot of features that everybody learns when they are new to the language. After writing Go for over seven years (since r59 if you know what that is) I realised that there are a lot of those features that I never use, and don’t think you should worry about. This talk covers them and explains why. Drawing on a wealth of experience building real things in Go, this talk explores the theory vs the practice of Go, and aims to lighten the load of those learning the language. The more you know the better, but it’s better to learn things in the context of when you’re really trying to solve those problems, rather than all-at-once up-front with nothing real to pin it to. This talk will appeal to teachers of Go to prioritise the useful, so developers can be valuable sooner.
Mat Ryer has been programming since age 6 (Mat would type BASIC code out from computer magazines with his father to make little programs and games), Mat has always had a keen obsession with programming. An early adopter of Go pre-v1, Mat fell in love with the philosophy behind the language, and has been an active member of the Go community since.
Mat is the author of Go Programming Blueprints: Second Edition, and a regular speaker at conferences around the world. He is an avid believer in open-source technology and founded some popular packages and projects including Testify, Moq, BitBar and various Machine Learning tools.
In early 2018, Mat co-founded Machine Box to provide Machine Learning capabilities to developers of all levels.

[@manikanth2166]

Very nice and useful stuff. But jump to 07:30 where the actual presentation starts.

[@terragame5836]

The part about line of sight is by no means unique to Go. I've picked it up from the Zen of Python (#5, "Flat is better than nested"), and have been using that principle ever since

[@WorstDeveloper]

Really great and fun video to watch. Good speaker.

[@AxxxA4444xxx]

That was a really great talk, thank you! :)

[@mishasawangwan6652]

i can relate.. since i started using go i don’t use else nearly as much

[@TBButtSmoothy]

using else is a situational thing, it goes across most languages.

[@parlor3115]

Especially that you can't write it in a separate line

[@charlesmartel7255]

Your ethos is great. Glance-abilty sums it up well. I’m just starting to look at Go, and I like what I see so far, largely due to this sensibility manifest in the language. I started on C in college then worked in Basic, then dBase and VB (and now PHP and Javascript) and I missed the clarity of Basic. I tried to miss out on Java and OOP as the amount of work needed to manage objects ( rather than just solve problems) struck me as inefficient to the point of silly. Am I right in thinking Go suggests the tide has changed against OOP?

[@TheMrKeksLp]

It has but not because of Go. In fact Go relies on the equally as outdated and bad structural typing idea

[@cryptk]

This is a great talk, but the camera angle changing every 15 seconds is painful if you are actually trying to read what's on the slides...

[@TurtleCoin]

I want to see Mat from all angles to best absorb his intellect.

[@scamcaller]

Also I think the fact that the keyword 'new' reminds programmers of memory allocation can be confusing, since it simply means creating structure, not malloc calloc thingy. &{} is just enough.

[@ninja-vm8uf]

He did a Ricky Gervais at 18:08

[@a_maxed_out_handle_of_30_chars]

good talk

[@1889990]

gotta disagree with 10:39 ...being able to lable such a jump is actually way more readable then creating an extra new bool just to trigger such a behaviour. It adds unnecessary if's and variables and convolutes the actual loop logic. I think this is one of the very few places where a labeled jump can be very beneficial.

[@-..-_-..-]

yeah i think breaking out of an outer loop is essential. sometimes you can structure your code in such a way that it's unnecessary but often a loop in a loop will have to exit early, and using some "done" variable to annotate that that gets checked on every loop is far worse.

[@AleksandrPodyachev]

The issue that I have with go is that I had a problem with importing modules that are within your project

[@pevenphoon7359]

The laughter at 0:59 made me laugh too.

[@sergeywhite8897]

fire!!!)thanks1

[@bronzekoala9141]

I think there are plenty use case for structs without field names. There are some data structs like Vector3, Vector3 or ColorRGB where the order and fieldnames are obvious.

[@daleowens7695]

I pass unexported empty structs as exported interfaces across the package boundary all the time. "Code to the interface" and all that.

[@Sergeeeek]

Single field structs come to mind also, like color.Gray

[@PetrGladkikh]

22:13 - what if I want to pass a reference to that method? Without it I could not do that without making a closure, which is unnecessary burden.

[@W00PIE]

I've just started with Go some weeks ago and I already passed the point where I use "else" - it's simply not neccessary. Go makes you implement things correctly, the compiler is like a strict governess. You'll hate it at first, but once you get used to it, your coding style will adapt. One thing that bugs me once in a while is using channels as a callback substitute, it still feels a bit clumsy. But to be honest: I already love this language!

[@TheMrKeksLp]

Oh boy do I have news for you. Go ain't memory safe (with non-nil interface nil pointers and sharing data structures across goroutines) and I highly disagree that the idiomatic way of returning a value AND an error -- where one is supposed to be nil -- can even remotely be considered "correct". Of course the correct way would be using an algebraic data type like Rus't `Result` which is either the value OR the error

[@Sergeeeek]

@@TheMrKeksLp I don't think it tries to be memory safe

[@mysticaltech]

Haha.. Hilarious, thanks Mat!

[@packagemain]

Please add the subject into the video title, so it will be searchable.

[@dragoran149]

Mat, Mat, Mat... never prototyped, huh? I've used every keywords of Go. Don't take them from me, I need it.

[@-..-_-..-]

i think all of them are strictly necessary besides goto. the only valid use for labels in well structured code is breaking outer loops imo. else is maybe overused by novices but it feels like it's there for hyperbolic shock value. unless i missed it, fallthrough i don't think he explicitly talks about, he just lists it as one of the ones he never uses, but it really really really helps dry up code if you have a number of cases that are equivalent. i can envision his argument for why it's evil, which is probably that it's less clear having to follow your eye down the switch into another case block than to just restructure the switch or whatever but it's the default behavior in every other language for a reason imho. go has already improved the readability by forcing it to be explicit.

[@nyrtzi]

No spaghetti but how about lasagna and ravioli?

[@TruongHoang-du9if]

He's a fun guy)

[@Arwahanoth]

I would add this: does not allow return parameters with named return arguments. Bad experience...

[@-..-_-..-]

this

[@benfranklin7526]

What is the font used in this presentation?

[@suic86]

Looks like Courier New (en.wikipedia.org/wiki/Courier_(typeface))

[@pengdu7751]

organiser?

[@nicolasparada]

👏👏👏👏👏

[@tango2olo]

goto statement from C/assembly, is really powerful.. but only gods can handle that power.

[@k1ngjulien_]

Its too powerful. If someone has to use goto in their code these days it says to me that something is wrong about that code and it should probably be restructured.

[@tango2olo]

@@k1ngjulien_ you don't believe in "god" it seems. ;)

[@TheMrKeksLp]

Rust doesnt have goto for this exact reason. It's too powerful and fucks up assumptions about object lifetime and scopes

[@lhpl]

I only looked at these comments (being 4minutes smth into the video) to check if someone had made a "Go2 considered harmful" joke. Of couse... As fo goto: it "serves" two purposes: - continue execution by skipping further down in the code sequence - continue execution by jumping futher up (back) in the sequence. We have names for this now: the first is an 'if' statement, the second a 'loop' statement. Goto is not needed.

[@PetrGladkikh]

4:36 - think Clojure maybe? If we're _measuring_ here :) Or at least Go is not alone with this approach.

[@LaPingvino]

I basically got from Clojure to Go -- they share a lot of similar philosophy, and Rob Pike referred back to Rich Hickey's consideration of simplicity

[@-..-_-..-]

yeah clojure and go have a lot in common. there aren't too many different ways to do the same thing in clojure either. it really feels like what would happen if the go team had decided to make a functional jvm language lol

[@davidguo3995]

Really Nice, but have slides?

[@PetrGladkikh]

The talk starts at 2:20 You're welcome.

[@blacky7801]

go couldn't exclude goto, afterall it has the word "go" in it

[@umeshmalhotra4617]

Can someone explain me subliminal joke at 10:56 ?

[@psl101]

He’s trying to get you to buy his book

[@killerhz]

I didn't know David Brent was a gopher

[@bronzekoala9141]

I think I see why else isn't needed, but the example given really isn't nearly enough to show the idea.

[@jvpdek]

Hi, Matt. Would you please simplify the Greeter.Greet slide. It has code parts that are not relevant to your point and actually distract the viewer. For example, the function doesn't use the receiver, and the struct field name looks too much like an important type name. Instead, make the field name Greeting and the func use Println(g.Greeting,... [the func actually uses g]. Then your example will focus on the point you're trying to make.

[@jacobschmidt]

I think the example was fine

[@jacobschmidt]

it was very simple and demonstrated the point

[@halfwit2]

Weird, I use goto quite a bit :/

[@alexkfridges]

Garbo

[@manigandand]

goto is useful for command line scripts,

[@VictorMartinez-zf6dt]

You should never use goto, ever.

[@ulissemini5492]

@@VictorMartinez-zf6dt then why is it in go ( ͡° ͜ʖ ͡°)

[@ulissemini5492]

@@VictorMartinez-zf6dt stackoverflow.com/questions/11064981/why-does-go-have-a-goto-statement you should read this, i agree you should not use goto, except in very specific situations (i've never used it but someday i might need to)

[@VictorMartinez-zf6dt]

@@ulissemini5492 just because it's in the language doesn't mean you should use it.

[@glxxyz]

Victor Martínez someone should do a video on that

[@01kaskasero]

This isn't useful for real work. Great for talks though.

[@andytheodorko9874]

I'm surprised to see `goto` in go? Dijkstra proved a long time ago that we don't need it.