This is a really good repository. 💯

[kelp404]

I have learned go for a year.
This is the best project what I seen in go.

[KasemOmary]

I was feeling "this language looks stupid" the first time I looked at it.

The articles confirmed my at-a-glance assessment.

[MichaelTJones]

Kasem, I'm not sure that you've understood the point. These are foolish articles, generally, by people who have not understood what they saw, or are applying good lessons in the wrong way or in cases where they are no longer good. A few had valid critiques, but a decade later, generally no longer apply to any recent Go. The idea here is to collect them to know what kind of misinformation may be found by developers curious about Go and why so programmers are enjoying it.

[solidsnack]

@MichaelTJones That is definitely not the point of this repo. It may be a use for it, but it's definitely not the point of it. Many people who contribute are genuine Go haters.

[KasemOmary]

That in mind, progress is always good. Any resources to change my mind for the better?

I am always open to proof.

[MichaelTJones]

Kasem, well, there is direct experience, in a use and judge context. For out-of-date complaints, there really is no point-by-point review because the complainers (in anything) tend to be outside the circle of involved people. One example would the area of memory management. In a few of these (as I recall), the person did not want GC, wanted a particular style of GC, or did not care about the style but wanted it to be faster. The answer are: (a) Go is GC so if you don't want that on principle it is not for you, (b) the implementation is fluid and may, ten years on, be more or less to your style preference, and, (c) it is now extremely fast. For b & c, the presentation at the International Symposium on Memory Management has the best review: https://blog.golang.org/ismmkeynote but that's not anyone's attempt to change minds. Go is an engineering effort with a set of goals. It gets ever closer. If those goals work for a particular developer it could be an excellent choice. It is for me. But, I also code in Mathematica for uses where that's my best power tool. I write assembler for the same reasons. I don't need to have my mind changed and don't want to change that of others. Use what you like. Jason, Ok, sorry. I did not intend to insult anyone. It was my own judgement from reading through this a few months ago that it seemed to have a lot of things that don't match my long observation, so I took it as I did. I'm a Go fan, but not a missionary. There are things I like and dislike, as with all my tools, and I choose among them to get the job done. I never experience anger or "mean" emotions about the technical nature of tools, so the articles that called out people by name for attack were a turn-off too; they made the whole thing seem not so real (in the technical / computer science / intellectual discourse sense). Of course the venting and rage may be real for others. People are different.

…

On Sat, Jul 20, 2019 at 4:36 PM Kasem Omary ***@***.***> wrote: That in mind, progress is always good. Any resources to change my mind for the better? I am always open to proof. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#44?email_source=notifications&email_token=AB4DFJPOUDYM2GBMYEFYVUDQAOOQ3A5CNFSM4FUJ6LDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2NX3WY#issuecomment-513506779>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB4DFJMTAJ3TCOJ5QRVUYSTQAOOQ3ANCNFSM4FUJ6LDA> .

-- *Michael T. Jonesmichael.jones@gmail.com <michael.jones@gmail.com>*

[KasemOmary]

I could also lend a bit of my views to being a bit raw over the shared history of node/go. That's a story for a different discussion.

The language has been on my radar for a while, but I may have done a "personality" thing. You mentioned fluidity - and that's part of my issue, for sure. I can't deal with the project impact of another ES5-ES6 debacle... when a slew of improvements come flying in.

The tools and resources will evolve in time. The instant it becomes viable for my applications - by all means, go joins my toolkit.

In the mean time - I'll search for an excuse to use go.

[MichaelTJones]

Oh...I was not clear: Go language unchanged. Only underneath changes. One thing not (maybe) so obvious about Go is that unlike most new language projects, the goal was not to add things to make programming better, but to take-away/simplify/clean things that have been problematic over the years. This was motivated by several factors. First was an awareness inside Google that 15k programmers building a giant billion line C++ "thing" would always suffer slow compiles and C/C++ risk area bugs; they wanted a safe programming / good teamwork / instant build outcome and a language to enforce that. Some of the complaints here are the result of that. Nobody likes being told no, even when it's for your own good (examples below). Second was a desire by the team (including Ken Thompson, Mr UNIX and C, Turing award winner) to "fix" mistakes that they'd let loose on the world. Ken had a choice to clear local variables in C, did not do so for speed--trusting programmers, and saw 30+ years of bugs from uninitialized data. Go has an attitude to not always trust programmers. It really helps code quality and team programming, but it might bug you. That's a personal choice. These come through in the Go videos but the decades of data driving them are not presented anywhere. For example, Go compilers consider an unused variable to be a fatal error. It's irksome to comment things out just to test something, and several of the objectors here seem to hate this. However, Go code bases have no dead code. That's the upside. Every constraint (no automatic type coercion, not dead code, no raw/mistyped pointer access, ...) comes with improved code health. One of the subtle points Go practices, which I've spoken about in a former speaking career, is the difference between coding as a student, for fun, or alone vs as part of a professional team. The big difference of team programming is that most of your work is with other people's code, comments, indentation, and quirks. Speed of first-time comprehension is critical. Avoiding the quirky habits of others (especially language-changing macros) is important, particularly in debugging. Go's willing to squeeze the developer a little to make the team part smoother, faster, easier. Many people (a million developers) find this to be a good trade. I do. But, it is a trade. You lose some freedom that might hurt, at least at first. Again, not selling. Just sharing. I do believe professionally that the "Go attitude" is good for big efforts whatever the language.

…

On Sat, Jul 20, 2019 at 6:15 PM Kasem Omary ***@***.***> wrote: I could also lend a bit of my views to being a bit raw over the shared history of node/go. That's a story for a different discussion. The language has been on my radar for a while, but I may have done a "personality" thing. You mentioned fluidity - and that's part of my issue, for sure. I can't deal with the project impact of another ES5-ES6 debacle... when a slew of improvements come flying in. The tools and resources will evolve in time. The instant it becomes viable for my applications - by all means, go joins my toolkit. In the mean time - I'll search for an excuse to use go. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#44?email_source=notifications&email_token=AB4DFJPG3YYXRZ4SBEQPF2TQAO2CRA5CNFSM4FUJ6LDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2NY3UQ#issuecomment-513510866>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB4DFJOAPXQ6UK5HJ5FHNWLQAO2CRANCNFSM4FUJ6LDA> .

-- *Michael T. Jonesmichael.jones@gmail.com <michael.jones@gmail.com>*

[Randgalt]

I'd say the articles in the repo speak for themselves. Having yet-another-discussion here in this thread is pointless. I stand by my article that has a pointer in this repo.