<p>Hello! </p>
<p>I'm thinking about learning go, but I have some questions. I will ask them below, and would love if someone can answer one or some of them. Why I do this is because I read alot of good/bad stuff about Go , and want to clear stuff out before I put my head into it! Sorry for my bad english!</p>
<ol>
<li>Why do you ( or your company) use golang? What section of development? (Webservices etc)
1.1 Why use golang for that and not another language?</li>
<li>Is golang one of your "primary" language? </li>
<li>Do you have any positive and negatives stuff you can share about golang?</li>
<li>Have there ever been a problem that can't be fixed (or is hard) with golang during your development of a project etc, and if so what was it?</li>
<li>Anything you miss in golang?</li>
<li>How is the safety in golang? Meaning protection from hackers etc.</li>
<li>Do you develop in a IDE? If so in what? </li>
</ol>
<p>Would be really happy if someone could help just answer one of these questions! Thank you! Happy monday! :)</p>
<hr/>**评论：**<br/><br/>sacado: <pre><ol>
<li><p>artificial intelligence research stuff (not machine learning, but symbolic ai), webapps and several sysadmin tools - 1.1 for AI : excellent sweetspot between raw speed of C++ and productivity of python; for webapps and sysadmin : dead-easy deployment</p></li>
<li><p>Yes, but I use C++/Python/Javascript whenever needed</p></li>
<li><p>Go code is incredibly easy to maintain ; it's not a language that is particularily fun to write, but you can read anybody's code (including your own, 6 months ago) without scratching your head.</p></li>
<li><p>nope, since we don't use it when it is not the adequate tool (maximum raw speed required, for instance)</p></li>
<li><p>not really</p></li>
<li><p>not that much a language issue, although the language being compiled means you are much less likely to run in a runtime error when maintaining a small webapp. Never had any problem with go webapps, but we have been attacked on or PHP base several times.</p></li>
<li><p>vim-go</p></li>
</ol></pre>drvd: <pre><p>Lets try:</p>
<ol>
<li><p>Because it is a nice get-shit-done language and we are payed for getting shit done. Tooling.</p></li>
<li><p>Yes (for me). No (for company).</p></li>
<li><p>No. It's fine where it's fine.</p></li>
<li><p>Yes. Basically everything from NP complete (NP hard too) :-)</p></li>
<li><p>Yes: A builtin language name correction: The language is named Go (not golang).</p></li>
<li><p>If you think languages will protect you from "hackers": Stay away from the keyboard ;-) Go protects you from lot's of lowlevel C-style problems, that's basically as far as most languages can provide "safety".</p></li>
</ol>
<p>7 No. I doubt you would call emacs and IDE.</p></pre>nicolateral: <pre><ol>
<li>Web Services
1.1 Performance, fast programming, good standard library, very easy to learn</li>
<li>Yes</li>
<li>OK for small to medium backend projects</li>
<li>Nothing </li>
<li>Nothing, until you use it for what it was suppose to do :)</li>
<li>Does this question makes any sense ?</li>
<li>You can use any basic syntax-highlighter editor you like</li>
</ol></pre>cameronjerrellnewton: <pre><ol>
<li><p>It is extremely performant, easy to write web services and API's (90% of our work) and we can trust that it will execute the other 10% fast enough-ish. If we run into issues, the built in memory and CPU profilers are wonderful to work in. Go-fmt eliminates 90% of bikeshedding done during code reviews.</p></li>
<li><p>Yes</p></li>
<li><p>I think a lot of that is captured in 1, but</p></li>
</ol>
<ul>
<li><p>pro: </p>
<ul>
<li>Easy to learn. The language itself is small. The learning resources are wonderful -- golang tour, effective go. The spec is digestible, and actually insightful to read, compared to reading other specifications, I feel like I am reading a textbook and am instantly turned away.</li>
<li>You can start coding <em>now</em>, and add more advanced features later. Go is fast enough to do most of what you need in a single threaded, imperative fashion, the kind of naive programming style most people are accustom to. I went about 6 months in my professional gophering career before I touched the "go" keywords and channels. After that it was enlightening, as you learn to think about concurrency not as doing many things at the same time (concurrency is not parallelism) but as a way to structure your code. This was the eye opener.</li>
<li>It blows most things out of the water when it comes to performance that isn't named Java, C and C++. </li>
<li>It is a joy to write web services with</li>
<li>It is absolutely a joy to deploy. <code>go build</code> for your target architecture and OS, and <code>cp my-binary</code> done. It really is amazing. </li>
<li>The language designers and maintainers, and the community as a whole stress a particular coding style that some people dislike, but I find very enlightening and enabling despite me disagreeing with them at times. In go, there typically is a "right way" to do a particular thing or how to structure it at least, and I actually love that. Coming from the Java/C++ world, this is a godsend.</li>
</ul></li>
<li><p>Cons:</p>
<ul>
<li>I miss dynamic-isms like meta-programming and doing things like Hash.contains() (these things were hidden from me, as most language-provided data-structures had these nice methods included. For example, in ruby, as long as a data-structure implemented Enumerable, you could call <code>each</code> on it.</li>
<li>reflection is wonky, and typically discouraged, but since I came from mostly dynamic based programming languages, it's a tool I commonly reach for, so readjusting for that is sometimes difficult.</li>
<li>That's pretty much it for me</li>
</ul></li>
</ul>
<ol>
<li><p>No.</p></li>
<li><p>Answered in 3 </p></li>
<li><p>I don't get this question. </p></li>
<li><p>I don't use an IDE, but I do use vscode. Sometimes I drop into vim.</p></li>
</ol></pre>syndbg: <pre><p>Some of the questions are weird, but here I go. </p>
<ol>
<li><p>Web services built with the default http server and outperforming Ruby greatly. </p></li>
<li><p>Skip. </p></li>
<li><p>Dependency management can be improved and not have to rely on open source solutions, since it makes sense to have this in the golang tooling. </p></li>
<li><p>Nothing I can think of. The specific of the web services is not going to hit any low level error any time soon. They are really straightforward. </p></li>
<li><p>Lol no generics. Jk, as I said dependency tooling in golang instead of open source solutions. </p></li>
<li><p>This does not make sense. It's not that language specific. It makes sense for the language to cover latest confirmed security exploits, but beyond that don't expect the language to cover you from SQL injections and other exploits that completely depend on the programmer. </p></li>
<li><p>Spacemacs and Vim. IDEs are not really needed with Go. I'm fine as long as I can use ctags. </p></li>
</ol></pre>weberc2: <pre><blockquote>
<p>This does not make sense. It's not that language specific. It makes sense for the language to cover latest confirmed security exploits, but beyond that don't expect the language to cover you from SQL injections and other exploits that completely depend on the programmer.</p>
</blockquote>
<p>There are language-level security features; e.g., memory safety. So it's perfectly reasonable to ask about the security features of the language.</p></pre>syndbg: <pre><p>Given the approach and nature of the questions, I'm a little bit biased to say that this is not the intended security feature that OP asked for.</p></pre>varikin: <pre><p>Others have covered 1 through 6 well but I feel the need to add to 7. Vim and emacs are not ides. I have been very happy with intelij with the go plug-in. And they have a go specific ide in beta called Gogland. </p></pre>jiimji: <pre><p>emacs and vim are absolutely IDE in the sense that they can use language services, like Go code to provide a complete integration for Go development. The integration is at the level of go code server. They are not just text editors or Vscode is just "a text editor". It is not. </p></pre>varikin: <pre><p>Honestly, it is comments like your that makes me tell people that the Go community, and devs in general, are toxic. When someone asks about IDE support, almost everyone knows they mean an application that is marketed as an integrated development environment. You know, things like Visual Studio (not VSCode), Eclipse, Intellij, etc. And every goddamn time, there are these goddamn neckbeards shitting on anyone who doesn't edit their fucking code in Vim and Emacs. Woe is us for not knowing how to patch together 50 fucked up config files from random blog posts on being faster because of goddamn ctags and yy and dd. Well, some of us damn normies like modern tools and use a fucking IDE. We like being productive instead of gloating about productivity because you have all the fucking time in the world to finally get ctags working. Until you get a new goddamn computer and ctags breaks again. And fucking again.</p>
<p>OP asked about IDEs, not Vim and not Emacs. Go back to your fucking cave and gloat over how much warmer you are for banging rocks together to make a fire while the rest of use just turn the heat up on our thermostat and let the adults talk.</p></pre>shovelpost: <pre><blockquote>
<p>When someone asks about IDE support, almost everyone knows they mean an application that is marketed as an integrated development environment. You know, things like Visual Studio (not VSCode), Eclipse, Intellij, etc. And every goddamn time, there are these goddamn neckbeards shitting on anyone who doesn't edit their fucking code in Vim and Emacs. Woe is us for not knowing how to patch together 50 fucked up config files from random blog posts on being faster because of goddamn ctags and yy and dd. Well, some of us damn normies like modern tools and use a fucking IDE. We like being productive instead of gloating about productivity because you have all the fucking time in the world to finally get ctags working. Until you get a new goddamn computer and ctags breaks again. And fucking again.</p>
<p>OP asked about IDEs, not Vim and not Emacs. Go back to your fucking cave and gloat over how much warmer you are for banging rocks together to make a fire while the rest of use just turn the heat up on our thermostat and let the adults talk.</p>
</blockquote>
<p>This post is so hilarious that it deserved to become a meme! <a href="http://9gag.com/gag/a1boeR6" rel="nofollow">http://9gag.com/gag/a1boeR6</a></p></pre>Zypho_: <pre><p>Way to shit on a guy who was just pointing out the benefits of using Go binaries to turn a feature poor stock editor like Vim into a full-blown Go programming environment.</p>
<p>Couldn't you have just answered the questions 1-7 like the others and not voice your views on the proper definition of a syntax highlighter? </p></pre>varikin: <pre><p>Because I am sick and tired of being told over and over again that because Vim and Emacs is a proper syntax highlighter, people should not use a real IDE. Well fuck that shit. When someone asked about an IDE, they already know about Vim and Emacs and have already decided that they want an IDE, not Vim or Emacs. </p>
<p>If you would read my top level comment, I was pointing out that the OP asked about IDEs, not Vim and not Emacs. I was answering question number 7. </p></pre>peterbourgon: <pre><blockquote>
<p>I am sick and tired of being told over and over again that because Vim and Emacs is a proper syntax highlighter, people should not use a real IDE.</p>
</blockquote>
<p>Nobody said that. Chill, friend
