The Go Language: What Makes it Different? - Jay McGavren

The Go programming language emphasizes simplicity and speed. Common programming mistakes are detected by the compiler. The language itself encourages proper error handling. It has first-class concurrency support using goroutines and channels. And on top of all this, Go offers lightning-fast compilation and execution. This talk will cover all the unique features that could make Go the ideal choice for your next project!
Philly ETE 2019 Playlist: • Philly ETE 2019
On the Chariot Solutions site: chariotsolutions.com/screencasts/

[@catwhisperer911]

I. had spent most of the '80s and '90s coding in C and C++ and I have to say that I am loving the Go language. I was anticipating investing my time in Rust but, for me at least, Go makes much more sense for the applications I write. Go is just awesome and I think it has a very unique place in the developer stack, between C/C++ and interpreted languages, which makes it ideal for performant application development.

[@abcdefg-nu4xj]

could you elaborate more about where Golang makes more sense over Rust, or were Rust could make more sense over Golang in your opinion?

[@DagangWei]

Fantastic talk for me Go beginner!

[@pss_crs]

43:00 Channels can close sender or receiver but the go idiomatic/recommended sender will close. Use close() function for it. ⬇️ chn := make(chan int, 5) --- Code.. --- Close(chn)

[@priteshugrankar6815]

Wish more Golang talks were like this...

[@gcxs]

Nice talk but select statement is also worth noting

[@broyojo]

I still feel like not using a variable or import shouldn't be a compile error, maybe only a compiler warning. maybe gofmt would remove the extraneous stuff or the compiler would optimize it away? I feel like it will obstruct creative flow when you have to remove lots of code just to test something out, then to ctrl-z everything back.

[@fernando-loula]

I see no reason why it can't seamlessly be optimized out. Feels like needless compiler intrusion.

[@broyojo]

@@fernando-loula maybe go wants to promote clean code since could easily optimize unused imports or variables

[@Megalcristo2]

That is because no one listen to warnings. It's not very rare to compile open source code and find the "warning: variable not used".

[@Qrzychu92]

One option would be to have it as a warning in debug build, and error in release

[@FPChris]

This drives me nuts. Let the programmer decide. A warning is fine.

[@luizfelipels7]

Wrong output @ 33:23 ?

[@erikecoologic]

24:32 > "Go implements composition over inheritance at the language level." - I don't get it, looks like multiple inheritance to me, what am I missing?

[@ITech2005]

Thats not inheritance dude. Landmark doesnt implement or extend Coordinates. The only relationship there is that Landmark INCLUDES a Coordinates object in its type definition. My only gripe here is them making it seem like some special feature of Go when you can also do this in other languages like Java. In other words, the lack of inheritance is treated like some additional feature. This may be where the confusion is happening.

[@Megalcristo2]

You can't do dynamic polymorphism with composition. If you have the class "Human" and then creat "Male" and "Female" which inheritance form "Human", you could create a vector of "Human" and add "Male" and "Female" items. Also you could pass to s function that receive a "Human", a "Male" or "Female". But composition doesn't allow you to do that. In Go you would use interfaces. This is better overall, because you have 2 independent features, instead of one that is bloated and hard to maintain. Maybe inheritance might be better in some cases, like videogame development, byt composition + interfaces (duck typing) feels more lightweight and make you approach your code differently.

[@1wisestein]

18:49 wtf, is that an inline anonymous struct definition no AND instantiation, immediately assigned to a variable? Dense.

[@chuganator]

5:08 "We all know how to clean up after, still its so nice not worry about it" . People are in silos. Lol

[@mikasd9]

We all know how to do it yet it's still the biggest software issue to date

[@MrCoOrtexX841]

not a web dev, but the purpose of request in paramater at 17:57 ? it's not used after in the code function, i don't understand

[@leo69105]

Probably for the type of the procedure, so you can pass it to HandleFunc on the next slide.

[@TheSurvivor1963]

This demo shows only extremely simple examples. The request-parameter may f.ex contain query-, path- and post-parameters that you will need in a proper web-application. If an application also accepts f.ex JSON it will need to read the request-body.

[@DagangWei]

30:17 seems there is no guarantee for the order, e.g., the 1st size might not be from the 1st page.

[@TheSurvivor1963]

That's right, but there are other ways to fix that,- but why not design you program in such a way that order doesn't matter? ;)

[@OMGclueless]

This is by design. The point is to be efficient and run the three requests concurrently, and respond to them as they come in, in whichever order they come in.

[@BryanChance]

Two deal breaker: 1) "import and not used", 2) Declared and unused variable, 3) ...

[@FPChris]

What if you had 30 RGBA defined globals that aren’t used? Super annoying

[@Cylain]

constants can be defined without being used

[@ms77grz]

👍👍

[@enriquebenedicto9429]

I do not like using return values for errors. What a pain in the a$$ to always check for returned errors. Just at 16:26. Maybe there are cleaner way of checking for them.

[@wilsonfreitas8418]

A large sized project would require hundreds of lines of code just to check for generic errors. Maybe go was designed for specific use cases where there are no large call stacks. A generic error handler is extremely effective for web applications. I can't imagine how this return value approach would be better.

[@beatricemeyers4640]

@@wilsonfreitas8418 Go is modeled after the C mentality where errors should be handled as soon as they happen, preferably recovering from expected errors and continuing on without crashing. Errors can be compared (equality) with other errors just like you might do with integer error codes in C, but with the added benefit of built in textual error messages and a host of other new features added in Go 1.13. You can easily declare different errors as package variables to make error-checking far less generic. In practice, most errors are handled by the function caller rather than being passed back up the call stack. If the error needs to be passed up further, it is common practice to return a new error which is more specific to the context of that function or package than the previously encountered error. This can help significantly to reduce all of that generic / ambiguous behavior.

[@wilsonfreitas8418]

@@beatricemeyers4640 I get that. I agree with the benefits of taking care of errors as soon as possible, but if you have to write error handlers for every single function that is a lot of lines of code not really related to the problem you are trying to solve. I believe the reason for this approach is to streamline the concurrency support. And I can see how that helps. But it is not a good path for code simplicity.

[@beatricemeyers4640]

@@wilsonfreitas8418 We don't return errors for every function. Functions are written whenever possible to avoid returning errors. This is part of the reason for handling them immediately when they are encountered: the caller doesn't need to know that an error occurred if it was recovered from.

[@wilsonfreitas8418]

@@beatricemeyers4640 here is a very common scenario in web applications. 1. User submits a request, 2. A request handler receives the parameters and invoke some business layer function, 3. The business layer function performs some complex logic that includes invoking multiple functions and this can many levels deep. The user is waiting for the request to complete and needs to know if it worked. How would you report back to the user an error that happened many layers down?

[@SB-rf2ye]

"encourage you to explicitly check for errors" no ... not encourage ... you force the devs to do so.

[@Megalcristo2]

You just have to be explicit when ignoring errors using value, _ := foo()

[@stephendelacruzone]

💎✨👍

[@user-zd9wd]

I used to write go code but the switched to rust; Can only recommend rust but Go is nice too

[@defabc8572]

과제 ㅎㅇㅌ! :)

[@thatkindcoder7510]

*Visual confusion*

[@HiddenLotus9]

Content is good, but speaker would have been slightly better served rehearsing it or by using a script

[@FPChris]

Just have slices or make arrays dynamic. Both seem pointless

[@unknownsoul7043]

i am sold when i see you can parse a string to bool in GO, i am done Go Vue is the way to go sorry

[@soho1080]

W The fuck does one need to invent a new PL every fucking weekend.

[@megetmorsomt]

It was "invented" 13 years before this comment...

[@LaPingvino]

I generally consider the way Go does OOP as the only way that is useful and acceptable xD

[@richdobbs6595]

Hmmm. I guess you consider the vast amount of OOP code written in other languages to have not been useful. That seems like an extreme position.

[@LaPingvino]

@@richdobbs6595 No, not that the resulting code is not useful, I just consider the OOP element syntactic grease.

[@richdobbs6595]

@@LaPingvino Well, you can call higher level languages as syntactic grease on top of assembly language. But there seems to be a lot of folks that use that grease to make things go smoothly. I have tended to avoid much use of inheritance, but the general ideas of associating methods with chunks of state has seemed useful to me in solving a lot of issues and making code easier to understand.

[@LaPingvino]

@@richdobbs6595 Yep, but that is not what OOP is originally as a design method or what those languages are originally made for. the way it does work is exactly distilled in Go. Disclaimer, I'm a programmer since my 8th but as I never had a formal programming education I managed to skip OOP as a main programming philosophy, growing up with imperative, procedural, functional and Go's way of OOP instead. I had a job programming in Common Lisp for example. All OOP-based code bases I saw or touched were an absolute nightmare. With syntactic grease I mean the evil equivalent of syntactic sugar: it is an abstraction on top, but instead of making it sweeter, it makes everything sticky.

[@LaPingvino]

@@richdobbs6595 I fully agree. But procedural languages already have that. C already has that.

[@abdlhamidwaziz9164]

hello gir go😅

[@yapayzeka]

go losts me at handlefunc function :D goodbye

[@LaPingvino]

That kinda grew organically out of the design. It's a jump in thinking, but really worth it!

[@TheIsraelMendoza]

👋 Bye

[@nathanruben3372]

I literally hate go syntax....

[@terragame5836]

Go code might be nice to read, but it's not nice to write. So I don't see why any independent developer would chose it willingly. I can see it being imposed by a project manager, but it's absolutely not something I'd use without being forced to