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

[@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.

[@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

[@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.

[@barzontus]

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.

[@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

[@TakekazuOmi]

Very nice

[@ninja-vm8uf]

He did a Ricky Gervais at 18:08

[@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.

[@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

[@kf5268]

Love the else part

[@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

[@Arwahanoth]

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

[@barzontus]

this

[@AleksandrPodyachev]

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

[@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

[@barzontus]

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

[@pevenphoon7359]

The laughter at 0:59 made me laugh too.

[@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]

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.

[@packagemain]

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

[@pohjoisenvanhus]

No spaghetti but how about lasagna and ravioli?

[@dragoran149]

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

[@barzontus]

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.

[@dawnrazor]

The section about not using else statements is terrible. Whilst I do agree that they can be avoided when error checking, there are more reasons to use an else other than for error checking. How did you make such a blunder by not addressing non error checking else statements?

[@PetrGladkikh]

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

[@TruongHoang-du9if]

He's a fun guy)

[@sergeywhite8897]

fire!!!)thanks1

[@mysticaltech]

Haha.. Hilarious, thanks Mat!

[@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

[@benfranklin7526]

What is the font used in this presentation?

[@suic86]

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

[@pengdu7751]

organiser?

[@davidguo3995]

Really Nice, but have slides?

[@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.

[@nicolasparada]

👏👏👏👏👏

[@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 :/

[@01kaskasero]

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

[@manigandand]

goto is useful for command line scripts,

[@vectorhacker-r2]

You should never use goto, ever.

[@ulissemini5492]

@@vectorhacker-r2 then why is it in go ( ͡° ͜ʖ ͡°)

[@ulissemini5492]

@@vectorhacker-r2 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)

[@vectorhacker-r2]

@@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

[@alexkfridges]

Garbo

[@andytheodorko9874]

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