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

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

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

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

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".

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

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

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.

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.

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

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.

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? ;)

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.

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

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.

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

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

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

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

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

constants can be defined without being used

*Visual confusion*

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

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.

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

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

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

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

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

👋 Bye