According to the stackoverflow survey Go popularity has risen from 4.3% to 7.1%

According to the stackoverflow survey 2018, over the past year, Go popularity has risen from 4.3% to 7.1% <a href="https://insights.stackoverflow.com/survey/2018#technology">https://insights.stackoverflow.com/survey/2018#technology</a> <hr/>**评论：** tywkeene: <pre>From spending a lot of time writing Go and trying to find a job writing Go, I feel like it's really an untapped resource. It's a really solid language for cloud computing, it's easy to learn (even at a higher, production-ready level) and it has really solid standard lib, documentation and community.</pre>BowsersaurusRex: <pre>Let me prefix this by saying that I use Go and C# on a daily basis. Go is great. My main problem with the platform is that .NET exists. Specifically .NET Core. Go and .NET Core are extremely similar, except C# is far more mature and has far better tools simply because it's been around for so long. Feature wise, Go almost feels like a pure subset of .NET Core which makes it very hard to justify its use for new projects. Performance is comparable. To make matters worse, .NET Core is actually easier to get started with since there's no messy environment, path, or directory management. We generally use it on projects in which the lead developer simply refuses to touch anything associated with Microsoft. Or because people have outdated knowledge on .NET and think it runs slowly or only on Windows. I'm hoping Go branches out and does something unique that makes it easier to recommend. The more .NET Core spreads into Linux environments the more Go will end up living in its shadow.</pre>Thaxll: <pre>I don't think net Core will ever eat Go because they're a bit different, net core needs a VM, Go doesn't, you can compile Go into a single binary where net core is like Java with a "bloated" runtime. Even when you look at the libraries Go is more mature in terms of backend services, Kestrel is not production ready for instance.</pre>BowsersaurusRex: <pre>.NET Core can build self contained binaries. Future versions of .NET Core will have method level trimming of runtime features from the build output. Kestrel is production ready. It's designed to be used by a reverse proxy. Go should also be used by a reverse proxy. Neither should be public facing.</pre>ar1819: <pre>Go works perfectly without any sort of reverse proxy. In low latency scenarios it's actually preferable, since nginx introduces additional overhead, and there are times when you really don't want to pay for this. Since most of the crypto stuff is implemented using platform dependent assembly, it's also pretty fast. Last time I checked cloudflare infrastructure worked like that. There is also fact that I can just launch Go web app with some sort of the embedded database inside my ODROID box, and it will do ok. I know it's not a big deal, but the fact that I don't have to deploy the usual proxy/app/database/cache stack is very uplifting. I don't want my little home application to be "webscale". I just want it to work. </pre>DocMerlin: <pre>Go actually works better (much faster) without a reverse proxy. <a href="https://blog.gopheracademy.com/advent-2016/tls-termination-bench/" rel="nofollow">https://blog.gopheracademy.com/advent-2016/tls-termination-bench/</a> In fact there are some rather good reverse proxy implementations that are built in go <a href="https://github.com/containous/traefik" rel="nofollow">https://github.com/containous/traefik</a></pre>BowsersaurusRex: <pre>Of course it does, but I still wouldn't expose it directly to the public internet.</pre>scottjbarr: <pre>People have an aversion to MS for a reason, but at the root it is typically burned trust. When it catches you out, you'll know get it. If it has caught you out and you're still on that train, you're a very trusting person indeed :) The problem with .NET on anything other than Linux is that every so often it proves to be a second class citizen on anything other than Windows. I tried trusting MS again with .NET core, and not long in evaluation... Boom! Hello Linux the 2nd class citizen. I can't remember the exact issue, but it was along the lines of exbrace/extend, bait/switch or Windows first/only. Once trust is burned it takes quite some time to earn it back. You don't have to look far to find a bunch of examples in recent history. Others can list them if they like.</pre>BowsersaurusRex: <pre>I would be curious to see what the issue was since the .NET Core team is composed of Linux enthusiasts who operate largely independent of Microsoft. .NET Core is open source, on GitHub, and has a lot of community contribution. I keep seeing people make vague references to this happening with .NET and .NET Core, but rarely do people provide any concrete details. Do you have links to the GitHub issues?</pre>tristan957: <pre>I'm excited to see .NET Core more available on Linux and Mac. I also think that Microsoft has kind of made so that you have to use Visual Studio to have a good experience writing C#/.NET. I think they are moving in the right direction, especially with the C# support in VSCode. I'm excited for the future of VSCode and development of Core :)</pre>BowsersaurusRex: <pre>VS Code on Linux is great. I use it for C# and Go. But C# with Visual Studio is definitely the best experience. The amount of tools at your disposal is insane. I've unfortunately become addicted to historical debugging. :P</pre>PaluMacil: <pre>I really love Core and after having had similar time working with both, I agree that both are great, but I vary from you a little on the conclusion. I don't necessarily think Core has better tooling and setup. I tend to favor Go for those features. As far as library support goes, I go either way. I wrote an Active Directory integration once and actually chose Go because once I realized I would need to use some raw LDAP either way for my particular needs, C# didn't add anything extra. Sometimes I need something .Net gives me, but usually it ties into something where I wind up needing Framework, so I don't get any of the nice things from Core anyway. I do prefer C# (or Typescript) for desktop, but for a cli I love Go. Web can be fine either way. Both are a pleasure. In the end, the reason I prefer Go when things are even is that you don't get clever things from a previous developer nobody can figure out in Go. In C# you'll eventually get an application that imports assemblies at runtime, does reflection on them, and puts them together in a way that will take you months to decide. In Go you might find someone spending an extra hundred lines of code somewhere to stick to the standard library, whereas in .Net you're more likely to find that each product has it's own unique homebrew ORM. ?</pre>BowsersaurusRex: <pre>My problem with Go tooling and setup is that I'm always wrestling with the GOPATH or directory structure or some other BS. I wish they would fix this. It's my biggest complaint.</pre>tiborvass: <pre>It's being fixed: <a href="https://research.swtch.com/vgo" rel="nofollow">https://research.swtch.com/vgo</a></pre>Phr0ztByte: <pre>Wrestling with GOPATH? <blockquote> $HOME/go on Unix-like systems %USERPROFILE%\go on Windows </blockquote> It really is not that hard. I was a C# dev, well before .net core. I relied in VS almost exclusively for a long time. I moved to Python, Java and Go on Linux, and I see no reason to go back. I feel no less productive, and C# has no real benefits over any of the above. </pre>BowsersaurusRex: <pre>Specifically, having to specify one at all, which you don't need to do in .NET Core. And needing to keep projects in a specific directory structure is counter productive. I wish they would fix this. Regarding C# features that Go lacks, I could compile a long list. The most glaring is the lack of generics. It makes Go feel like .NET 1.0, including the exact same work arounds and arguments.</pre>Phr0ztByte: <pre>Regarding project structure. It has never been a problem. My source usually lives in a specific folder anyways. Would it be nice if I could choose, sure. But it is not a glaring problem. Once I coded go for a while, I didn't miss generics anymore. And the verbosity of the language makes it easy to read and understands. There is no "clever" code anywhere. I like C#, don't get me wrong. I am just saying, after been coding Go for a while, I don't miss it. Every project I wanted to do, I have done, and a lot faster than I would have done it in C#. </pre>abstart: <pre>Exactly, C# can be used to generate very complicated code using multiple inheritance, extensions, linq and other ways to express functions, loops and conditions, lambda syntax, and tags. These can build in a huge technical mental burden into the code for anyone new to the system. Go is like C#-Lite and that's a good thing (*sometimes).</pre>recurrency: <pre>After two years of go I still for my life can't understand the complaints about the GOPATH. It's the greatest relief of all time. Just put your stuff in ~/go, you are done and voilà you have a fantastic way of keeping things organized. I even put all non-go projects in the Path, since it's just such a great idea to have it symmetrically organized with the source repo urls. </pre>rotharius: <pre>Because one wants to manage dependencies and pin down versions per project and in the project repository. Not in some machine/environment specific directory. Every mature language has this (although it also kinda sucks in Python).</pre>sethammons: <pre>Is this not exactly what vendoring does?</pre>rotharius: <pre>Yes, it is. But I don't see why a GOPATH is necessary for that. In fact, I want to isolate my projects.</pre>allowthere: <pre>Does .net compile to static executables or do you run it in a JVM like JIT compiler?</pre>BowsersaurusRex: <pre>.NET Core can be compiled with or without the runtime. If you compile it without the runtime then the runtime needs to be installed. If you compile it with the runtime, then the runtime will be included in the executable but trimmed down to only to the parts you're using. .NET Core is jitted, it does not run on a VM. Ahead of time compilation will be added in a future version. Jitting has it's advantages. It can produce code optimized for a specific machine instead of just a specific build environment. Jitting also has the benefit of being able to dynamically emit code, which can provide a huge performance boost in certain scenarios.</pre>abstart: <pre>Just started a Go project, and I agree C# .net core is very attractive. It was the main other language we were considering. But .net core is still new, so yes people will be worried about it (from what I read, msbuild support was just added in august). When I looked at the setup for C# .net core, it looked more complicated with more dependencies. Go is easy (ok so set a gopath variable not a big deal). Installing on linux or windows is easy. Depending on the developers on the team, it is much easier to write very magical and complicated C# than it is to do the same in Go, and Go is easier to pick up for new developers. These are really important business attributes for long term projects that don't need the extra power of C#.</pre>golang_or_nolang: <pre>And something that's often overlooked is its leadership. Rob Pike and Ken Thompson have been industry leaders for a very long time (although C is outdated now), and their wisdom is often overlooked.</pre>PaluMacil: <pre>I think outside the west coast and known Go-using companies, there are a lot of places that use Go but don't mention it in job postings. I've worked with two teams where they had Go code but only posted to hire .Net devs. Sometimes you have to get lucky, and then as you gain seniority, you will also gain the ability to make some of your own decisions in this regard.</pre>tywkeene: <pre><blockquote> but only posted to hire .Net devs. </blockquote> See, I always just completely ignore those postings. I don't use windows, haven't used it in years and don't plain to in the future. Ever. Double goes for .Net</pre>PaluMacil: <pre>Sure, and I don't entirely know why management and or HR chooses to have inaccurate postings, but my assumption is that they don't believe they will find a go developer and simply want a developer that will fit in with the rest of the stack. It is annoying since it makes it nearly impossible to find a lot of those go jobs since go will not be listed in those cases. I just don't know a way to find those jobs other than getting lucky when you're hired for a Java, Python, C#, or Ruby job and suddenly you are a go developer instead. ? That said, one of the teams I'm mentioning did not deploy to Windows. It was 100% .Net core on Ubuntu Linux with Docker and Postgres, so C# does not necessarily mean a Windows stack. I strongly prefer Linux to Windows but also think C# is a pretty good language, especially if you use .Net Core and VS Code. </pre>BowsersaurusRex: <pre>You are aware that .NET runs on Linux, right?</pre>tywkeene: <pre>Didn't but it doesn't really matter. Go has much better support for Linux, and I grew up on Linux and I make a living on Linux. Really no reason to use anything else. Especially something ported from windows.</pre>BowsersaurusRex: <pre>Can you provide examples for Go having much better support for Linux?</pre>ar1819: <pre>I can. Syscall interface and whole interaction with Linux is horrible. Working with libvirt, for example, is impossible under Linux unless you are using mono (and no, it's not even remotely bugs free - I see it everyday just by seeing random freezes and crashes in my KeePass). The language itself feels overcomplicated. And that's coming from C++ dev, mind you. The actual performance is subpar - check the techempower benchmarks, especially database related tests. I don't mind Microsoft projects - in fact I use Windows as my home system. And I don't mind Net since they have one of the most powerful GUI toolkits. But if we talk about Linux networking - I would really like to have the first class citizen support. Honestly, you have better chances to convince someone to use Java/Kotlin on Unix environment in this sub. At least they were designed to be cross platform from the start - and JVM ecosystem is second to none (npm module that doesn't do anything useful doesn't count as an ecosystem). P.S. C# crypto is slow everywhere but Windows. This is just sad. </pre>BowsersaurusRex: <pre>I mainly use .NET Core on Linux for cloud services, so I've never dealt with syscalls. I use C++ quite often. Personally, I think C# is an extremely clean and simple language. It's behavior is well defined and predictable. C++ macro hell and template hell makes it one of the most unweildy and complex languages in existence. But I will admit that C# has a bit too much syntax sugar. If I recall correctly, .NET Core 2.0 crypto uses the underlying platform implementation on Linux.</pre>ar1819: <pre>If we talk about web or cloud applications: basically CRUD with semi to very complex business logic - there is no bad choice. Since most of your app logic isn't tied to underlying OS mechanics you can use anything from Node and Elexir to Java EE. It's just a matter of personal taste and project required functionality. I don't think that Go really shines in that area tbh, since most of the business logic is quite repetitive and you want to remove as much boilerplate as you can using language features. This is where having syntax sugar and a rich collections is a good thing. But not every app is a CRUD that do not care about the underlying OS ?</pre>BowsersaurusRex: <pre>That's my point, when choosing between Go and .NET Core for cloud services there's no real reason to choose Go since it's missing a lot of features, even though Go is great. Although cloud services can be a lot more than just CRUD and business logic.</pre>tywkeene: <pre>I can't, nor do I care to. I will die before I develop .Net on Linux. I made a big assertion. You got me.</pre>BowsersaurusRex: <pre>I don't blame you. Logical decisions based on data have no place in programming.</pre>tywkeene: <pre>Yep. It's logical to use a language ported from another OS over one with native support.</pre>Rizens: <pre>In my opinion this is just the beginning. More and more company are going to turn to Go for API & Back End. Go "out of the box performance" & architecture really makes it a perfect fit for low latency application and large traffic applications , especially compared to NodeJS or Java. Wouldn't be surprised if the language went to 12% or so in the coming 2 years .</pre>cbll: <pre>Yeah I'm a Java dev primarily but I've been fiddling a lot with Go for smaller stuff(data processing, taskrunners mainly) and it's incredibly fast and performant for the amount of code you write. A ~50 line Go program would be 7-8 classes in Java sometimes.. And the Go program oftentimes perform better.</pre>nwss00: <pre>Go replacing Java, albeit unlikely, would be fantastic. I'd even settle for just Kotlin replacing Java!</pre>cbll: <pre>Java isn't going anywhere. It's bearable with Lombok annotations, though. But yeah - I hope to use Kotlin some day, it's difficult to argue for when no one knows it and everyone would prefer Java because it's comfortable..</pre>PaluMacil: <pre>A small dev shop near me is nearly 100% Kotlin in as small a place as Grand Rapids MI, so you might be able to find was small Android team near you that writes Kotlin, if that's interesting to you. It seems like phone app dev shops are small enough to enjoy languages like that more frequently.</pre>cbll: <pre>Step one, acquire US Visa :P</pre>PaluMacil: <pre>Yeah, I don't mean to imply that I think everyone in this community is American, and I don't know what it's like in other markets. </pre>cbll: <pre>Can say that here in Denmark, nobody uses Kotlin. But we're a Microsoft country.. so C# is mostly all the rage</pre>Rizens: <pre>UK is also a very .NET C# country. Microsoft really did a great job selling their stuff.</pre>PaluMacil: <pre>It's true trends aren't distributed evenly. I went from a team that was moving from C# to Go to a team that is 100% C#, making me a mere Go hobbyist again. (sigh) At least I spent enough time in Go to be comfortable and efficient in my own projects now.</pre>BowsersaurusRex: <pre>I posted about this above, but our main issues is .NET Core. It's very difficult to recommend Go above .NET Core since .NET Core matches it in performance and portability but has far more features and far more mature tools. Go code is a bit less verbose than many C# projects, but you could just throw your entire codebase inside a single C# class and get a similar result. Go needs its killer feature. Something C# can't do. I'd like to use it more.</pre>kaeshiwaza: <pre>The killer feature of Go is to don't have too much features. For C# to beat Go it needs to remove some features like inheritance, generic, overloading...</pre>zoweee: <pre>Just curious since you've mentioned needing a "killer feature" a couple of times: do you not find go-routines or the interface system to be unique and compelling? I've found that the trivial concurrency of go-routines have really shaped the way I write software (in fact I feel a little claustrophobic without them) and the ability to design interfaces and implementations of those interfaces has made me a much better producer of modular software.</pre>chriselliott82: <pre>Go in time will take over node. Even the guy that made node says go is better!</pre>alierbey: <pre>we have a company that make developing smarthome technology. and we almost used to for 4 years at go. we are like everytime because it is very fast language</pre>MrPhatBob: <pre>We are replacing all of the video streaming components that we had written in Go - because of the cost savings which are demonstrable with the cloud servers we run our stack on.</pre>NeedsMoreTests: <pre>I read that sentence over five times and still don't get it. Please unbreak my brain with one of the following choices: <ul> <li>You're replacing the stuff you had written with Go and can demonstrate the cost savings in your cloud environment.</li> <li>You're replacing the code you wrote in Go with the cloud.</li> </ul> The first one makes more sense. The second one may make sense with a serverless type approach but without more specifics it sounds like "Just put it in the cloud!" ha.</pre>defaultprimate: <pre>They are rewriting the video streaming components, which are not currently in Go, in Go</pre>NeedsMoreTests: <pre>You sure because that's not what it says: <blockquote> we had written in Go </blockquote> Pretty sure you're right, it's the thing that makes the most sense....but I asked anyway since you never know.</pre>MrPhatBob: <pre>Yes, this.</pre>MrPhatBob: <pre>Miss-keyed quite badly there. Let me re-word it with a little more clarity. We are re-writing the components that we had written in NodeJS using Go instead. It is demonstrable to any non-technical business stakeholder that the cost savings are significant, and will save far more money, when we start to scale up, than sticking with the original implementation. We are also able to show that lower processor overheads will cascade as less infrastucture is needed, and so less cooling will be required.</pre>NeedsMoreTests: <pre>Cool, thanks for the explanation! I figured that's the direction you were heading but I've been surprised before haha. </pre>Hunterbunter: <pre>third option is: <ul> <li>they're replacing all of their video streaming components from another language, to go, because go is cloud friendly</li> </ul></pre>MrPhatBob: <pre>We're not going specifically serverless, but we are using Docker swarm as Go works really nicely in containers.</pre>NeedsMoreTests: <pre>Was swarm something you already using or something you decided to use over kubernetes? Seems like if you're cloud based you could go with GKE/EKS(when it lands), k8s overall is more flexible and you wouldn't have to run it yourself.</pre>MrPhatBob: <pre>Swarm was chosen because we need the option to deploy on customer's servers, as many have their own data centres, and others just plain don't trust the cloud. Our DevOps uses both Kubernetes and Docker and suggested that the installation overheads in our case would be rather high using Kube.</pre>TheRealLukeSkywalker: <pre>.mn </pre>

用户登录

今日阅读排行

一周阅读排行

最新主题