Go over .Net/C#, Why?

Looking for a convincing story to choose Go over .Net for "anything". Yes Go has a great concurrency model - the present state of concurrency/async/etc is not too shabby in .Net. Yes Go has great tooling - like it or not, Visual Studio is pretty damn good, and with the right setup you can be very efficient. I've built some decent CLI tools in Go, but I can do the same in .Net, perhaps not deployed in a single binary (unless you go the route of ILMerge), but still. Roughly equivalent and I can use F# if I want a more functional experience. I'm asking this sincerely as someone who is trying to convince himself that there is value investing valuable time in Go in the future. I'm always learning new languages and there is major value in just the learning aspect alone. That said, given the current and planned future state with .Net (Core, cross platform, etc), why would you pick Go over .Net? <hr/>**评论：** fortytw2: <pre>Choosing any tool "for anything" over anything else is fundamentally a mistake. Choose the right tool for your task, and don't be afraid to switch around. Go is incredibly good for building CLI tooling and network/performance dependent applications (daemons, monitoring tools, infrastructure tooling, etc), but for many other tasks there are languages/tools that will work better than Go :) </pre>qu33ksilver: <pre><blockquote> Choose the right tool for your task </blockquote> My advice too. And lastly, if you are a Windows + Visual Studio shop, you are probably better off with C#. </pre>woozyking: <pre>Go is a first class citizen in the open source world. That can either be your reason to go for, or against it.</pre>ultra_brite: <pre>If you plan to use F# since you want a "more functional experience" you are certainly not going to enjoy writing go code, at all. </pre>salbass175: <pre>Sure, understood. That was just a minor point though.</pre>kl0nos: <pre>As someone that know and used both. They both have their use cases and different tooling. I would use C# over Go for any desktop(Windows)/mobile UI development because tooling is a lot better. I would use Go everywhere where i need control over allocations and performance (it's a lot easier to do with Go guarantees instead of using C# generational GC and hoping that all will go into first generation). I would use Go in every team that do not know either one, because Go is a lot simpler to learn than C# (with all it's concepts and rules). Simplicity is very strong argument to choose Go over C#. If i would need highly structured code with a lot of corporate constraints and composition (access restrictions private, public, protected, inheritance, generics etc.) I would choose C# because it shines there. As you see it depends, both are better than the other for different use cases, they have also common ground on which they are both good. It really boils down to your use case.</pre>weberc2: <pre>If you haven't already, go to the <a href="http://tour.golang.org">Go tour</a>. IIRC, it takes a couple hours and you should be able to write complete, interesting Go programs by the time you're done. Adding to that, the fact that you can learn a programming language to the point where you can be productive in hours (or at worst, a couple days) is a big selling point in and of itself. C# is a great language, but a few of my reasons for preferring Go are: <ol> <li>In Go a type definition is neither pointer nor value, it's just a type. Individual instances can be passed around by value or by reference and converted back and forth. This makes it much easier to reason about memory allocations and collection (Go also has escape analysis, which C# doesn't, at least not yet), and eliminates the need for copy constructors and other such things.</li> <li>Go doesn't have classes (no extra runtime metadata on my object, though reflection still exists). In my opinion, C# would be much better if it only had its "struct" types, and passed these around by reference when necessary (see point 1).</li> <li>Go doesn't have inheritance, it has interfaces for polymorphism and some sugar for automatic delegation ("struct embedding"). One fewer footgun. Building your project is 1 command (<code>go build</code>) if you have all of your dependencies installed, otherwise it's <code>go get && go build</code>.</li> <li>Simple build system. No project metadata files. Everything Just Works (this will be even more true in 1.8 when GOPATH defaults to $HOME/go). No runtime dependencies, so you can get a binary with <code>go build</code> and then pass it around to anyone on your platform. Want to compile for linux arm from your MacBook? <code>GOOS=linux GOARCH=arm go build</code>. Send the binary to whomever you want--there are literally no runtime dependencies besides a minimal OS (<del>not even libc</del> this isn't quite true, see <a href="https://www.reddit.com/r/golang/comments/5cenu6/go_over_netc_why/d9w653v/">conversation below</a>). Last I checked, there was no practical way to do this for .Net (though there were some experimental solutions).</li> <li>Implicit interfaces. If I'm using your library, and I want to use one of your types to satisfy my interface, in C# I would have to create a new type that extends your type and implements my interface. In Go, I would just use your type and never think about it again.</li> <li>Great standard library. Go's standard library covers JSON, Templating, HTTP (production grade), testing, benchmarking, etc, etc. BTW, <code>go test</code> will run your tests by default., <code>go test -bench .</code> will run your tests and benchmarks.</li> <li>Standard formatting. Everyone uses the same style courtesy of <code>gofmt</code> (a program distributed with Go, which everyone binds to the save function in their text editor).</li> <li>Documentation for free. No special syntax, <code>godoc</code> parses the comments above any public declaration and produces documentation. <a href="http://godoc.org">http://godoc.org</a> does this for any repository path you pass it (e.g., <a href="http://godoc.org/github.com/russross/blackfriday">http://godoc.org/github.com/russross/blackfriday</a>).</li> </ol> Did I mention you (and thus your entire team) can learn it in a couple hours?</pre>TheSpreader: <pre><blockquote> Simple build system. No project metadata files. Everything Just Works (this will be even more true in 1.8 when GOPATH defaults to $HOME/go). No runtime dependencies, so you can get a binary with go build and then pass it around to anyone on your platform. Want to compile for linux arm from your MacBook? GOOS=linux GOARCH=arm go build. Send the binary to whomever you want--there are literally no runtime dependencies besides a minimal OS (not even libc). Last I checked, there was no practical way to do this for .Net (though there were some experimental solutions). </blockquote> This is mostly true, however I wanted to point out that unless you are cross compiling CGO is still enabled by default in many cases, so libc still gets linked to on mac and linux platforms. This is easy to overcome in some cases, you can just disable CGO, but certain features may not work (os/user as an example). And often it isn't a problem anyway, provided the system you're transferring the binary to uses a compatible version of libc. But then you get into situations on linux with distros like Alpine, popular in the Docker world, which use musl libc, and you can have problems. And never mind if you actually need CGO, i.e., to link to an external lib, then cross compiling gets back to being as hairy and complicated as it is on most systems that have native binaries.</pre>weberc2: <pre>Looks like this is true, at least if you depend on the <code>net</code> package. My mistake. I edited my answer and linked to your comment. Thanks for the information!</pre>szabba: <pre>You've left out the "github.com" in the example godoc link.</pre>weberc2: <pre>Fixed now. Many thanks.</pre>-Nii-: <pre>Too bad in your godoc link to blackfriday, several of the exported funcs do not have documentation, and there isn't any example code either!</pre>weberc2: <pre>Yeah, not all projects are well documented.</pre>SaltTM: <pre>One thing I hope GO developers do more often is proper version control. There's way too many packages out there that sit on master without any versioning at all lol.</pre>weberc2: <pre>Probably true, but this hasn't been a problem for me yet. When I find a bug, I can move to the latest version with the fix; I don't have to wait 6 months for a release to drop (which seems to be the norm, at least in Python). I find I can do this with some degree of confidence because the quality of Go projects tends to be higher than projects of other languages.</pre>vimthrowaway: <pre>I have a current project that has a service running as dotnet core(C#, on linux. I originally wanted to go with java/scala - but the guy i am doing it with couldn't quite get into java from a C# background, no idea why, anyway), its self contained and released as a docker container, the reason why we chose that is the awesome generics in C#, it was easy to map our entire model in it, we have migrations with EF, the restful controllers are easy to maintain and the testing frameworks seem nice enough. Now we needed a webserver aswell, and it didn't need a good ORM, generics etc. So i started to look around and i hadn't tried Go at this point, i just looked around the programming community for an alternative to C#, and its mainly Java/scala, Node.js, php, ruby, python and the other huge languages, and honestly there wasn't any of those that i really wanted to work with. Now, my first encounter with Go, i have been an avid Vim user for a bit more than 1 year now, and i love it, when i joined golang a few weeks ago and realized that alot of people actually develop with vim in this environment i googled their setup, i installed neovim, vim-go, deoplete, deoplete-go and it is freaking awesome, i have never had intelligent autocompletion in Vim before, jump to declaration etc. and it just makes a world of difference when you combine a simple programming language with the power of vim, and at the same time you feel like youre not too far from the steel either, then it also auto indents your code in a specific way everytime you save the file(so awesome), easy to generate HTML from the docs you write, type-safety, the project structure is very UNIX like(and clever in the sense that it structures your project based on source control structure(hadn't thouth of doing that before Go). On the other side we had C#, which is "fine" i suppose with its View in the MVC pattern but its never something that blew me away, i think i spend most of my time just copying documentation when i write in C#, everything is just so laid out for you, which is nice when you need to get the job done. But if you want a code flow that is not interrupted all the time of frameworks, online docs and perceived best practices - its very liberating to just jump into Go and code, if you call a method from the std library, you can jump to its implementation and actually understand what it does. And of course, Go is opensource, which just makes a world of difference when talking about tooling, editor support etc. i am allways surprised when i see a successful opensource project in C#, i dont know why, it just seems so unnatural to me, why anyone would spend so many hours improving a companys product without them being paid for it. I just think that alot of it boils down to the UNIX feel vs the Microsoft feel - and some people just like one over the other, and i am 100% for the way of developing on UNIX, in general i think its more programming oriented, while microsoft has a whole market of casual users they have to take care of. </pre>abotalot: <pre>you have conjured the great <a href="http://i.imgur.com/C4Oao7G.png" rel="nofollow">alot</a>! <hr/> #bot If you would no longer appreciate occasional alot conjurings in replies to your comments, PM me. Also, if you are a mod or admin and want them excluded from certain subreddits, please PM me </pre>lucaspiller: <pre>Well that's random...</pre>weberc2: <pre>The OP was writing "alot" instead of "a lot". The former is not a word in the English language, but a common typo. Evidently this bot is "conjured" by said typo.</pre>PaluMacil: <pre>I find that .NET is something I need to work with a lot to remain an expert because new frameworks and libraries are always coming out. There is a lot of great stuff there for the taking if you want to integrate with Active Directory, and I love ASP.NET and Active Directory Services. That said, Go is nice because it's simple enough that I can use it as a hobby. I'd enjoy a job writing only Go, but I don't need one to keep up on the language. Where C# adds tooling, new syntax, and flexible features, Go instead tends to stay readable, understandable, and easy to leave and return to. Sometimes the explicit nature costs a few more lines of text, but it's a fantastic feeling. I find myself nearly never lost in a complicated codebase in Go where C# can hide a lot with its magic. I love both, and I feel no reason to choose between them since they both offer a lot of advantages. Both are more or less elegant for different things. I've recently been using Angular 2 with Go, so I don't use the Go templating much but really enjoy making the APIs in Go. Microsoft's Web API framework is also wonderful, but even now that I know it well, the magic is sometimes too thick for my tastes. Core is fantastic, but still different pros and cons between them all.</pre>metamatic: <pre>Because I don't use Windows, and right now .NET's promises to be fully cross-platform are just that -- promises.</pre>jewishobo: <pre>I have production C# code running inside Docker containers on linux. It is already here.</pre>ultra_brite: <pre>.net core runs perfectly on linux.</pre>shadowmint: <pre>ha! Says a soul who wasn't tried actually doing that I'm guessing. You can technically compile and run some things, and even use some nuget packages, but you can't use nuget 3.* yet, and many things don't quite work; the package.json format is depreciated and the new format isn't fully supported yet. Once Rider is out of EAP and doesn't crash any more (to be fair, it only crashes about 3 or 4 times an hour at the moment) at least there will be a compelling IDE story for it, but its certainly not there yet, and 'runs perfectly on linux' is flat out not true. Try it. You'll immediately see that it's far from perfect. Its usable; barely, but definitely usable. You'll want to wait at least a few months before betting on it as a platform though. I don't think there's any real decision on the .Net standard vs. .Net core yet is there? </pre>ultra_brite: <pre><blockquote> ha! Says a soul who wasn't tried actually doing that I'm guessing. </blockquote> I have several .net core apps deployed on Heroku + MVC.net + postgres without a single issue. Maybe you should actually try to deploy .net core.</pre>shadowmint: <pre>/shrug Lucky you. All I can say is, my experience in no way mirrors that. I've had dozens of problems with nuget DLLs, restoring packages, running applications, compatibility problems. I 100% recommend anyone who is thinking about using .net Core on linux: DONT. Wait until the dust settles, rider is out and things actually work. I think the number of open issues on the dotnet/* github repos speak for themselves in terms of 'works perfectly'. </pre>jewishobo: <pre>I am running production .NET Core code, it's a perfectly viable 1.0 release. But if you get into it, you have to remember it is 1.0.</pre>jewishobo: <pre>Everyone please stop downvoting this. There is no reason why we can't acknowledge .net core works on linux today, because it does. Golang is still a great option, it's not competing with .net core, there is room for both.</pre>dcormier: <pre>Really, <a href="/r/golang" rel="nofollow">/r/golang</a>? Downvotes for contributing to the conversation? I expected better.</pre>MALE_SHOEGAZE: <pre>Congrats on your several apps, that's clearly evidence that .net works perfectly for everyone on linux. Also evidence that you're a tool.</pre>st1nc1ty: <pre>We should downvote this comment, not the one above.</pre>RagingAnemone: <pre>My guess the downvotes are because the use of the word 'perfectly' is very fanboyish. I haven't used it, so I'm in no position to judge, but it's hard to imagine a 1.0 release would be 'perfect'. Of course, there isn't any software anywhere that I'd call perfect.</pre>st1nc1ty: <pre>That's completely ridiculous.</pre>MALE_SHOEGAZE: <pre>The guy is declaring, completely unqualified, that .net works perfectly on linux. That's absurd. He's also being a dick about it. Are you under the impression that "maybe you should actually try to to deploy .net core" is a thing people say in good faith? Because it isn't. So he's wrong, and he's a dick. I don't really feel bad for calling him out on it. e: christ I just took a gander through my own comment history and I think I might be a dick.</pre>metamatic: <pre>Right, but since that's just console apps, what's the advantage over Go?</pre>jewishobo: <pre>Visual Studio, generics, more enterprise integrations.</pre>metamatic: <pre>There's no Visual Studio for Linux, and since our enterprise systems aren't Windows I'm fine with what Go offers.</pre>xiegeo: <pre>If you are not felling any pain points developing in .Net, then I don't see why you should switch. You can just learn Go for fun and not use it for work. For me, I never got to much into the .net platform and don't feel the need to as Go covers my needs. Microsoft does have some very good developer tools, but I'm not going to switch platform just for the tools.</pre>PsyWolf: <pre>I'd call it a matter of preference. .NET can be easy, but go is simple. If you want all the features, in a massive monolithic framework/toolset that insists on doing all sorts of black magic at runtime, like having settings in your applications config file get overridden by some other setting in a machine level config file, then .NET is for you If you want your team to never update their software, because it just works now and when they change the framework, they spend hours trying to get it to build and run again before giving up and going to the one person who actually understands all the subtle differences and breaking changes between each version, then .NET is for you. If you want a magic build button in your ide that just works, but is subtly different than the msbuild job used in your continuous integration, and leaves your devs tearing their hair out wondering why the same exact code results in 2 drastically different build outputs, then .NET is for you. On the other hand, if you want a very small set of orthogonal features that stay out of your way, let you do your job, and provide as little magic as possible, then maybe you should check out Go. Disclaimer: I actually quite like C# as a language, it's just .NET that I have issues with. I know Microsoft lifers who learn enough about .NET to be very productive with it. However, the "ease" of .NET also breeds a whole other, more common class of developers who learn enough to write code, but not enough to actually understand how the tooling builds it and the framework runs it. Eventually, it just gets very hard to maintain. As a polyglot, I want a language that my team and I can pick up and be productive with, leave alone for 2 years, and then pick up where we left off without the ecosystem having totally shifted out from under us. IMO C# has never been that language. Go is.</pre>jocull: <pre>I have probably lost years off my life spending time fiddling with web.config and app.config files. The amount of XML and magic is astounding under the guise of being "easy". More tools should exist that take the ceremony out of .NET development.</pre>SQLServerIO: <pre>my reasons for choosing golang <a href="http://sqlserverio.com/2016/08/17/go-go-golang/" rel="nofollow">http://sqlserverio.com/2016/08/17/go-go-golang/</a></pre>salbass175: <pre>MsSql is one thing from MS I love, trust, and will always defend. It ain't perfect, but it has rarely let me down. I've built so many systems that live on top of it... Let me ask you, do you interface much with sql server from Go? If so, how has that been working for you?</pre>mobiledevguy5554: <pre>I am using this github.com/alexbrainman/odbc for SQL Server in go and its working beautifully. Go is fast and everything "just works" The standard library probably has about 98% of what you would need to build a web app back end. The only real issue i've had is the lack of multiple results sets from SQL Server stored procedure support. This is arriving in Go 1.8</pre>jocull: <pre>Have you touched geometry support with that? That's a weird one I worry about.</pre>SQLServerIO: <pre>I've been using <a href="https://github.com/denisenkom/go-mssqldb" rel="nofollow">https://github.com/denisenkom/go-mssqldb</a> with patches for bulk inserts. I find that it is pretty easy to work with and performs well. I'm trying to make time to finish out some of the bits that are needed for bulk insert to support all data types.</pre>pinpinbo: <pre>I think it depends if the cost-benefit analysis makes sense to you. I don't see anything that .Net can, but Go cannot do. Go language spec is very small, 2-3 weekends and that's it. You are good to go. To me, that's a strength. Also, how's deployment story in .Net Core? Do you need to install a VM on every box? If it's anything like Java, there's an upgrade cost there that you don't have to pay in Go.</pre>mobiledevguy5554: <pre>Prior to the release of .Net core the obvious answer was Go. Now, i'd say it depends. If you have people with .net experience already it makes sense to go to .net If you do a traditional MVC server rendering approach then .Net may also be a better choice. If you are doing most of your front end work in a SPA framework like Angular 2 or React/Flux and your Web App Server is effectively serving up static pages with REST API calls then I think go is an excellent choice.</pre>whizack: <pre>I would pick Go over .Net if there was genuine interest or experience within your team working in a polyglot environment. Go doesn't solve every problem. Some problems are easier to solve in Scala, Python, Ruby, etc. If your team's experience providing valuable code feedback is only in .Net, it'll be a long, uphill battle to get your team to the point where they can provide insight into good idiomatic patterns and behavior for your domain. If the long term desire is to start using other languages to solve problems within your domain, then I'd suggest branching out into solving problems with scripting/dsl solutions first before transitioning core development to a different systems language.</pre>65a: <pre>portability for me.</pre>Sythe2o0: <pre>I enjoy coding Go more than I enjoy coding in .Net myself. </pre>NeverUse-YouPromised: <pre><ul> <li>C# is too Windows-centered.</li> <li><a href="https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=csharpcore&lang2=go" rel="nofollow">Go has better performance on several benchmarks.</a></li> </ul></pre>tscs37: <pre>Go likes being on a distributed (or atleast any) service system like a webserver or a database. That's where Gophers feel at home. Or the command line. C# on the other hand is probably the next best thing to z***** for developing a GUI client. That's atleast my take on it; Go for CLI and Servers, C# for GUI (on Windows).</pre>salbass175: <pre>That's been my experience as well. I've tried building comparable web apps using Go similar to what I've done with the MS stack, and IMO I found it lacking and nowhere near as productive. Templating was particularly ugly. </pre>SYN_SYNACK_ACK: <pre>then that's the answer you're looking for. If you don't like the way go does those things and you feel more productive using something different then maybe go isn't for you?!</pre>Fireynis: <pre>Templating, especially for the web, is nowhere as nice as many other web based frameworks. I use go as everything right now and that is my biggest gripe. I plan on making go the brains of my web app, but have something else do the front end, whether that will be Angular/React/Vue or something like Laravel acting between I don't know yet.</pre>mobiledevguy5554: <pre>There isn't much server side templating going on in a SPA app like Angular 2 though so unless you are doing a lot of server side rendering i'm not sure this is a big deal. Personally, I didnt find the Go templating that difficult to use when I needed to use it.</pre>comrade-jim: <pre>Do people still get paid to build new desktop apps?</pre>tscs37: <pre>No, everyone develops Electron-Apps now.</pre>itsmontoya: <pre>If a particular language can be used to build a requested project in a manner that is performant and maintainable, who cares what language it is?</pre>apocalypse910: <pre>I don't get this - the difference is night and day... I mean you can write perfomant and maintainable code for nearly any task in nearly any language if you know what you are doing but that doesn't mean there isn't a huge difference in the effort involved and the enjoyability of getting there... If the question was just a - "What is better C# or Go?" I could see your position - arguing languages as a whole is rarely useful... But specifically looking for strengths and weaknesses and a reason to invest in a new language or platform seems like an extremely valid question.</pre>jrwren: <pre>.NET Core is ~1yr old. Its base library and the OSS ecosystem around it looks like that of a project of about 1yr. Go is much, much more mature. BUT WAIT! Let me take a step back. Go was not written to solve any of these problems. Nothing in your OP is mentioning the reasons Go was written. The concurrency model is secondary to the two primary Go objectives. 1: compile fast. 2: save programmers from themselves. 1: Is your .net/C# codebase so large that the compile times are a problem? No? Strike one, Go is not for you. (<a href="https://golang.org/doc/faq#What_is_the_purpose_of_the_project" rel="nofollow">https://golang.org/doc/faq#What_is_the_purpose_of_the_project</a>) 2: Is your programming team made up of only average and below average programmers? No? Striek two, Go is not for you. (<a href="http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/" rel="nofollow">http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/</a>) </pre>salbass175: <pre>Um...regarding #2...Really? Great attitude. And quite contradictory being that one of Go's main selling points is how small of a language it is and how easy it is to pick up.</pre>Morgahl: <pre>Yeah honestly not sure why #2 was even included... Go was built to favor simplicity as a function of design. You should be able to look at a any section of code and be able to impliciy understand it. This leads to an interesting dynamic. In Go I find I take about 25% longer to write an equivalent section of code then most other languages, however, I find that time spent maintaining that same code is 2-3 times less expensive. All that simply due to the fact that in Go you tend to be able to hold the full concept of what is happening in your head with room to spare. Go tends to favor simple and clear over clever coding and that is HUGE for million+ line code bases. </pre>Redundancy_: <pre>My experience jives in that I've frequently worked with programmers who were not all experienced geniuses, but I've also worked with academics who couldn't code maintainable (or sometimes even working more than once) code, and some experienced geniuses who could solve any problem, but not necessarily in a way that anyone else could work on. It has sometimes seemed like great programmers who write selfless code are a minority. Regardless of how hot you think you (or others) are as a programmer, I think that you're better off writing code that's easily maintained by anyone who might follow you in the minimum amount of time, and Go can help do that (although not enforce), not just in terms of the simple language, but also in terms of the no hassle code documentation and testing. I quite like the saying "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." and feel like Go helps to point you in the right initial direction for that and good sensibilities and habits can take you the rest of the way.</pre>jocull: <pre>I believe the Go designers even cite junior Google devs as a primary use case for Go. It tried to keep you from doing anything "fancy" in order to minimize foot shooting.</pre>

用户登录

今日阅读排行

一周阅读排行

最新主题