Go is the language of personal projects

xuanbao · · 753 次点击    
这是一个分享于 的资源,其中的信息可能已经有所发展或是发生改变。
<p>I&#39;ve seen Go grow a lot in my time as a user, and like all languages, now that it has started working its way into business and large open source projects, it seems to have come under a lot of criticism in regards to how well it actually works in industry.</p> <p>I can&#39;t really comment on any of that, but I will say that Go seems very comfortable in a different spot. In my experience, small to medium sized projects written by about 1-3 people outside of industry really benefit from Go. Projects like that tend to fall pray to cowboy coding and the compiler&#39;s insistence that all variables and libraries are used as well as tools like gofmt help keep that kind of code readable. More complicated languages seem to often times be the birthplace of code that is very tough to follow if the proper precautions aren&#39;t taken early on.</p> <p>Go&#39;s simplicity by design also helps with that quite a bit. It&#39;s very easy to get started with a project, because most Go APIs stay relatively simple. Without classes and other complicated language constructs, library writers can&#39;t get too creative. Godoc also helps with that immensely. Larger and more complicated languages often feel unwieldy to me when the project you&#39;re making isn&#39;t also large and complicated.</p> <p>I wouldn&#39;t be surprised that if Go doesn&#39;t end up tackling the enterprise server-side programming market, it will live on as a language for small and medium sized projects like personal web servers, command line tools, indie games, mobile apps, and web crawlers. That being said, I often have no idea what I&#39;m talking about. This is just my experience with the language. Any thoughts?</p> <hr/>**评论:**<br/><br/>peterbourgon: <pre><blockquote> <p>it seems to have come under a lot of criticism in regards to how well it actually works in industry.</p> </blockquote> <p>Really? By whom? I haven&#39;t seen this at all, in fact rather the opposite... depending on your definition of &#34;industry&#34;, I suppose.</p> <blockquote> <p>I wouldn&#39;t be surprised that if Go doesn&#39;t end up tackling the enterprise server-side programming market, </p> </blockquote> <p>I really don&#39;t agree, I think Go is perfectly suited in that environment. And projects like <a href="http://gokit.io">go-kit</a> will help get it there.</p></pre>Velovix: <pre><p>I said <em>if</em> Go doesn&#39;t take off in that environment. I&#39;m not saying it won&#39;t, I just mean that even if it doesn&#39;t, I think it will still find a place in the niche I&#39;m describing.</p></pre>dvirsky: <pre><p>It&#39;s already taking off (adopted by Dropbox, Facebook, Netflix, Canonical, Mozilla, and thousands of start-ups and smaller companies you&#39;ve never heard of, including the one where I work). It&#39;s emerging as the leading language in the current generation of cloud infra (Docker, etcd, consul, Kubernetes, Vitess, etc). I find it hard to see what can curb this growth and adoption in a significant way. Looks like Go found its niche, and this niche is exploding at the moment. </p> <p>Maybe I have some sort of confirmation bias because I&#39;m part of this community, but over the 2.5 years I&#39;ve been working with Go, it has turned from a hipster language to a force to be reckoned with.</p></pre>dmikalova: <pre><p>I think all that criticism is really about dependencies which is valid, and getting better.</p></pre>hariharan-uno: <pre><p>My opinion is quite opposite. Go was designed for large teams (Google). All the tooling and straight forward code makes it easy for any new member to understand the code easily. So, I feel its more suited for large projects compared to small hobby ones. Also, I feel that once Go solves some basic problems for enterprise properly ( like dep. management ), we might see an increase in enterprise usage.</p></pre>natefinch: <pre><p>I actually find that the &#34;large team&#34; features just mean that my side project code is of much higher quality than it otherwise would be.</p></pre>darthlukan: <pre><p>I agree with you to an extent, but I&#39;d go further in saying that Go&#39;s design lends itself to being adopted easily. You can familiarize yourself to the point of usefulness with the language in a weekend, even if you come from (like me) a dynamic language background. I think that&#39;s its strength, it&#39;s a great language for small projects as well as large ones thanks to all of the points you raised.</p></pre>Velovix: <pre><p>You&#39;re right, it was designed for large teams. I can&#39;t argue with that, and it may well turn out that&#39;s where Go shines most. But the two aren&#39;t mutually exclusive.</p> <p>Right now, large teams often use more complicated languages, and they get around the fact that those can harbor hard-to-understand code through code review processes and by creating standards for how code within that company should look, among other things. This may not be the best way to do it, but it&#39;s one way to solve the problem.</p> <p>Very small teams and individuals don&#39;t and can&#39;t set up this large code writing infrastructure, so the result is that a couple hobbyists can sit down and write a bunch of code, but it often ends up being a big mess of misguided design decisions. Go doesn&#39;t let you make as many of these mistakes and so small teams benefit as a result. Code written in Go under less rigorous requirements seems to fare better than code written under the same circumstances in another language.</p></pre>kpmy: <pre><p>Well, in Russia such contradicted situations are described by phrase &#34;One doesn&#39;t have sex because of having acne, and does have acne because of doesn&#39;t having sex&#34;. All you need to do is start new enterprise level project with Go and not with Java solutions. It would be hard to explain to your PM, but if you can, this will be example of using Go in enterprise.</p></pre>martingx: <pre><p>I am using golang for enterprise server-side programming and so are several of friends and ex-colleagues in other companies.</p> <p>I&#39;m pushing for it to be more widely used in our company (a high profile international news organisation) and so far I&#39;m not having to push very hard.</p> <p>FWIW, our current main languages is java.</p></pre>natefinch: <pre><p>I totally agree. The benefits that go brings to large projects are also enjoyed by small projects. I&#39;ve jumped into Hugo, a relatively large side project in the scheme of things, and the fact that the code is all very straight forward meant I could get hacking very quickly. </p></pre>Low-Eel: <pre><p>Well, actually to be good at something cannot be described as a defect, IMHO.</p> <p>But, I can confirm is very very good for personal projects: I am running one, and it is <strong>fun</strong>. It makes funny to program, and: very very often you get at a point you planned 1-2 hours to code, and you finish in 15 minutes, or so. This is because you discover some &#34;surprise&#34; like some library function which is doing exactly what you have in mind. So yes, I totally agreee, it is a language for personal projects.</p> <p>About the point &#34;personal is not enterprise&#34;, I <strong>don&#39;t</strong> agree for several reasons.</p> <ol> <li>Just for an example: Linux kernel was a personal project. having a personal tool means you can write a prototype quickly. After you show the prototype, if your idea is good, then you have the others joining and making your chance to become the next enterprise. How many good ideas we lost just because the guy which had the idea had not enough time to develop a prototype? </li> <li>All developers team I have seen are made of individuals. (Maybe I should work in a Borg cube to see non-individuals :) :) ?). Jokin apart, golang itself has a nice structure in packages, which are then structured in files as like you want. So to break a task in pieces is very easy, under the point of view of agile/scrum. And it comes with native methods to include git code, which is a <strong>cooperative</strong> tool. So it makes fun for developers <strong>AND</strong> is ready for git , <a href="http://golang.org/cmd/go/#hdr-Import_path_syntax" rel="nofollow">svn and others</a>, since the beginning.</li> </ol> <p>About point 2, of course some bad &#34;project manager&#34; could fail in distributing tasks. Of course some bad &#34;software architect&#34; can fail to structure the source code. But, in the other languages when you have <em>bad project management</em> and <em>bad software architects</em>, you fail as well. Where <em>fail</em> means your product will never ever be successful: because it is slow, buggy , high time to market, and so on. </p> <p>I think there are no programming languages which can get rid of human incompetence, in no language ever.</p> <p>I don&#39;t think being so good for personal projects will <strong>stop or prevent</strong> golang to be a corporate language. Maybe it should have more libraries for corporate infrastructures, a bit more focused to integrate with Confluence/Microsoft Active Directory/Exchange or whatever. But here you go into a patent infringement chapter, and I can understand google will be very conservative about it. </p></pre>ask: <pre><p>All the benefits you are listing for &#34;small and medium sized projects&#34; built by small groups or as hobbies applies just as well for larger projects built for large companies. Why wouldn&#39;t they?</p></pre>Velovix: <pre><p>That&#39;s a really complicated question. The fact that there are so many articles out there complaining about Go&#39;s lack of generics shows that not everybody thinks simplicity is the answer. I don&#39;t claim to know the answer to what makes a language good for industry, but the answer obviously is not so simple as to assume that what&#39;s good here is good everywhere.</p></pre>

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

753 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传