<p>I'm a .net developer and want to use Go for microservices for two reasons, single binary and better performance. Recently, someone made a good case to stay with C#. <a href="https://youtu.be/8qjNy8p_TnY?t=16m31s" rel="nofollow">https://youtu.be/8qjNy8p_TnY?t=16m31s</a> </p>
<p>tldr; .net can have single binary and cross compile similar to Go; and faster compilation and runtime now, and of course has generics!</p>
<p>Should I wait until Go has matured with more features such as generics?</p>
<hr/>**评论：**<br/><br/>cdoxsey: <pre><p>C# is an everything and the kitchen sink language. Go isn't and, hopefully, never will be.</p>
<p>Developers need languages that are easy to understand and master. We need a feature set that's sufficient to be expressive and powerful enough to implement efficient software. Go strikes a really nice middle ground here.</p>
<p>Most other languages are focused on doing as much as possible, regardless of the cognitive burden placed on developers. In particular C# has within it radically different programming paradigms: C-like imperative constructs, Java OOP, Generics, standard Threads and the radically different async/await, a completely separate asynchronous mechanism via the now-archaic events, dynamically-typed objects for interoperability with other programming languages, ...</p>
<p>Perhaps the quintessential example is LINQ. They actually implemented an entire DSL within C# so that you don't have to write SQL in strings anymore.</p>
<p>C# is really a dozen programming languages mashed together. As a developer it means understand C# programs in the wild can be quite difficult, and when you're writing them you're left with so many choices you don't know where to begin or the tradeoffs inherit in each approach.</p>
<p>C++ is cursed with this exact same problem.</p>
<p>Go is popular because its a getting-things-done language where developers feel like they can build powerful programs quickly. The simplicity and minimal feel of the language is what makes this possible.</p>
<p>I'm all for features when they make sense, but you've got to assess the cost of them. I'm scared a Go 2.0 will end up killing the golden goose.</p></pre>joaodlf: <pre><blockquote>
<p>Most other languages are focused on doing as much as possible, regardless of the cognitive burden placed on developers.</p>
</blockquote>
<p>Great reply!</p></pre>GabensInventory: <pre><blockquote>
<p>Perhaps the quintessential example is LINQ. They actually implemented an entire DSL within C# so that you don't have to write SQL in strings anymore.
C# is really a dozen programming languages mashed together.</p>
</blockquote>
<p>This is utter bullshit.</p>
<p>LINQ queries <em>can</em> be translated into SQL <em>if</em> you explicitly use an ORM that does this for you like EntityFramework. </p>
<p>Otherwise it's just a handy library of methods that makes common operations like mapping, aggregation and filtering available over <em>generic</em> collections in an easy to use manner.</p></pre>cdoxsey: <pre><p>LINQ is clearly influenced by SQL. It came from a Microsoft research project. Of the many goals of that project, one of them was to introduce type safety into SQL Database interaction: <a href="https://www.microsoft.com/en-us/research/project/comega/" rel="nofollow">https://www.microsoft.com/en-us/research/project/comega/</a></p>
<blockquote>
<p>The current situation with regard to external data is just as bad. Most web-based (and many non-web-based) applications are basically thin interface-generating layers over relational databases (the `3-tier’ model). Yet dealing with relational data from within current languages is messy, error-prone and dangerous. APIs for database access typically construct SQL queries as strings and return results as untyped collection objects which are deconstructed imperatively. This makes code lengthy and unreadable, negates much of the benefit of working in a language with strong static safety guarantees and loses much of the advantage of the underlying declarative query language. Worse still, it is insecure: when query strings are derived from user input, preventing script-injection attacks requires very careful coding.</p>
</blockquote>
<p>Yes LINQ can be used for things besides SQL. Sorry if I wasn't clear.</p>
<p>(FWIW a more go-like approach to this particular problem would be a tool like <code>go vet</code> that can inspect SQL expressions and validate their correctness. Tools can fill in a gap like this without making the language more complex.)</p></pre>GabensInventory: <pre><blockquote>
<p>LINQ is clearly influenced by SQL. It came from a Microsoft research project. Of the many goals of that project, one of them was to introduce type safety into SQL Database interaction: <a href="https://www.microsoft.com/en-us/research/project/comega/" rel="nofollow">https://www.microsoft.com/en-us/research/project/comega/</a></p>
</blockquote>
<p>LINQ has a SQL-like syntax that is <em>entirely optional</em>, and not its main selling point. At its core, LINQ is just a library of extension methods that help reduce boilerplate and verbosity when working with collections.</p>
<p>For example, imagine a JSON array you've deserialized from a web request, you can perform the following operations on it using LINQ but <em>without</em> its query-like syntax:</p>
<pre><code>var results = webRequestResults.Where(item => item.Price < 50.0).OrderBy(item => item.Name).ThenBy(item => item.Price);
</code></pre>
<p>SQL never enters into this, <em>ever</em>. LINQ queries are being performed over generic collections, that's all.</p>
<blockquote>
<p>Yes LINQ can be used for things besides SQL. Sorry if I wasn't clear.</p>
</blockquote>
<p>Sounded more like you read the first page of some MSDN docs and decided that "hey guys, LINQ is SQL in C# lol".</p>
<p>Here's some documentation you should find interesting, and help clear up your misconceptions: <a href="https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/linq/query-syntax-and-method-syntax-in-linq" rel="nofollow">https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/linq/query-syntax-and-method-syntax-in-linq</a></p>
<p>Regardless of your personal opinion, LINQ's SQL-like syntax also does provide a huge productivity boost when working with a multitude of collections where several set operations are required (joins, unions, etc) to obtain the desired result, and where the data isn't coming from a DB.</p></pre>cdoxsey: <pre><blockquote>
<p>Sounded more like you read the first page of some MSDN docs and decided that "hey guys, LINQ is SQL in C# lol".</p>
</blockquote>
<p>I don't think this tone is warranted. It's certainly not appreciated. You know nothing about me or my experience. </p>
<p>In my opinion you are deliberately misrepresenting what I said and implied, so I'm not going to respond except to this, where you stumbled into my main point:</p>
<blockquote>
<p>Regardless of your personal opinion, LINQ's SQL-like syntax also does provide a huge productivity boost when working with a multitude of collections where several set operations are required (joins, unions, etc) to obtain the desired result, and where the data isn't coming from a DB.</p>
</blockquote>
<p>Absolutely. LINQ is a useful and powerful feature. I never said otherwise. On the contrary, I argued that despite their usefulness, we should be cautious about adding features to Go, because there's often an unnoticed cost to adding new syntax, keywords and paradigms to a language. It seems obvious to me that a feature like LINQ would not be in keeping with the spirit of Go, and doesn't satisfy the cost of that trade-off. (and maybe a feature like generics does satisfy the cost... but it needs to considered)</p>
<p>I don't expect C# or C++ developers to share this opinion. Like I said, Go is unusual in this regard. Less is more is fundamental to its design philosophy. If you don't agree with it, maybe you should look into using a different programming language, like C# or Scala. There are certainly plenty to go around.</p></pre>alexbarrett: <pre><blockquote>
<p>They actually implemented an entire DSL within C# so that you don't have to write SQL in strings anymore.</p>
</blockquote>
<p>That was your entire summary of LINQ.</p>
<blockquote>
<p>a more go-like approach to this particular problem would be a tool like go vet that can inspect SQL expressions and validate their correctness.</p>
</blockquote>
<p>This is the problem you think LINQ solves.</p>
<p>His tone is not unwarranted. Go and actually, you know, use it before you start talking about LINQ more.</p></pre>cdoxsey: <pre><blockquote>
<p>That was your entire summary of LINQ.</p>
</blockquote>
<p>It's called rhetoric. Would you prefer:</p>
<p>They actually implemented an entire DSL within C# so that you don't have to write SQL in strings anymore (as well as many other wonderful things you can do with LINQ)</p>
<blockquote>
<p>This is the problem you think LINQ solves.</p>
</blockquote>
<p>This is <em>one</em> of the problems I think LINQ solves. It's also one of the problems Microsoft tried to solve.</p>
<p>I have used C# and LINQ extensively. It solves problems and is useful technology. How many times can I repeat this.</p></pre>PaluMacil: <pre><p>Your rudeness is quite unwarranted. Adult professionals don't go making personal insults while trying to strut their understanding of something. Getting emotionally involved in a technical discussion should be embarrassing.</p>
<p>cdoxsey agrees that Linq is useful, powerful, and is used for SQL and other things. His point is that an additional DSL (regardless if you choose to use it) is another thing to know because you'll come across it and need to understand it. Whether this is always used for SQL is very unimportant to his point. There are countless powerful features in C#, and a lot of them also come with additional language syntax. How many hobby-only programmers pick C#? It's a lot less than other languages because you need to be using it every week to stay on top of new developments.</p>
<p>My team hired half a dozen developers straight out of college in the last year. When they learn the 25 keywords in Go, they can write decent code and understand our codebase a day after learning. We use more C# than Go, but when a junior developer uses C#, they have a ton to learn. ASP.Net, ADO, concurrency, boxing / unboxing, generics, etc burn up a lot of training and code review hours.</p>
<p>To the OP: Go ahead and learn Go. You can use it only once and a while without getting rusty because the simplicity of expression is its biggest strength. I use C# for a lot too, but for single-binary commandline apps, the experience with Go far outshines C#, in my opinion. For micro-services, I tend to use C# and <a href="https://github.com/StackExchange/Dapper" rel="nofollow">Dapper</a> when I'm talking to SQL a lot, and if I can use a memory mapped file for my data store, I use Go with <a href="https://github.com/asdine/storm" rel="nofollow">Storm</a>. </p>
<p>Personally, I love both languages, but I enjoy that C# focuses on a complex, full featureset, whereas Go focuses on absolute simplicity--even when it costs in lines of code and sometimes at the expense of a use case. Neither approach is "better", but I think Go adding complexity to gain more powerful syntax is bad just like I think C# should continue to do so.</p></pre>weberc2: <pre><p>The OP was perhaps less than clear about LINQ; why are you responding like he insulted your mother?</p></pre>brokedown: <pre><p>Do you use generics in your .net microservices?</p></pre>mikerrr07: <pre><p>oh yes, all the time, like for collection classes.</p></pre>Sythe2o0: <pre><p>Do you frequently use more complicated collections than maps and lists?</p></pre>tmornini: <pre><p>Great question.</p></pre>nuunien: <pre><p>I don't know about his use-case, however, the container types I usually find helpful in my projects are arrays, lists, maps, sets, and sometimes even different types of caches (LRU/LFU caches for example), of which, Go only provides generics for arrays and maps.</p>
<p>To get around this, I either use generated code or write the code by hand. For example, when I need unique values, I use them as map keys then iterate, then, if keep order is necessary, there's more code for that.</p>
<p>I agree that the type of generics provided by C#/Java/C++ are overkill for Go. However, having access to simple container types that only need one generalized type would be a godsend.</p></pre>aboukirev: <pre><p>I am a long-time C# developer that uses generics (and LINQ) a lot.
I also have several Go projects - cli, web sites, and services - no generics and loving it.
A lot of C# libraries with generics are overengineered.
I could do without LINQ easily too, although that would result into some more boilerplate code. But I could write more efficient SQL than LINQ.</p></pre>cameronjerrellnewton: <pre><p>Have you ever had to actually maintain someone else's LINQ code? </p>
<p>It's an absolute nightmare.</p>
<p>I wouldn't wish on my worst enemy to have to work in a cookie-cutter .NET shop. </p>
<p>edit: Sorry, I should add, what I mean by "LINQ code" is a .NET developer who makes judicious usage of LINQ everywhere you can just because they can(when they should of just a simple collection and a for each iterator) because it makes them feel like a "real developer" and that they've developed an "elegant" solution, meanwhile it has become impossibly impossible to follow the flow of data through their code.</p></pre>aboukirev: <pre><p>I've seen my share of LINQ used "judiciously". LINQ code can be maintainable and unmaintainable and so can be a lot of SQL strings in code. There was an article on this subreddit about some company practices using <code>sqlx</code> library and maintaining a lot of query strings in <code>go</code>. Edit: found a link <a href="https://www.reddit.com/r/golang/comments/6ew65l/our_go_is_fine_but_our_sql_is_great/" rel="nofollow">https://www.reddit.com/r/golang/comments/6ew65l/our_go_is_fine_but_our_sql_is_great/</a></p></pre>cameronjerrellnewton: <pre><p>thanks for sharing, that's a good article. Love the highlighted quote</p></pre>codingconcepts: <pre><p>If a programming language used to develop Docker and Kubernetes can't be considered mature, I'm not sure much else can :)</p></pre>holyjeff: <pre><p>Docker and Kubernetes cannot really be considered a benchmark. I mean really...docker?</p></pre>codingconcepts: <pre><p>Yeah, it's got something to do with a whale or something. Apparently quite popular...</p></pre>weberc2: <pre><p>Why is docker not a good benchmark? It's a large, widely used code-base. Whether or not it is the best tool for its stated purpose (if that's what you're even driving at) is unrelated.</p></pre>1Gijs: <pre><p>If you like .net then please keep using it. I like Golang and keep using that. I do not think there can be one language that can please all. We need different languages for different people and different use-cases. </p>
<p>Think of cars: if I look outside my window I see many different brands, models and colors. </p>
<p>And if not anything else, people like to be a bit different then the rest ;-)</p></pre>kaeshiwaza: <pre><p>If languages are cars, Go is simple as a bike and so fast in current city from door to door without consuming a lot of energy even with an army of bikers :-)
Please don't put an engine, two wheels more and a top just because in an other life you transported an heavy load on the rain it will become a truck in traffic...</p></pre>mikerrr07: <pre><p>sorry, my intention is not to start a flame war, I just want to understand objectively if moving to Go is justified by the reasons people mention. There are people who make judgement calls against languages that they do not fully understand. For example c# has a rich roadmap. <a href="https://www.infoq.com/news/2017/06/CSharp-7.2" rel="nofollow">https://www.infoq.com/news/2017/06/CSharp-7.2</a> But I am not sure the roadmap for Golang. I guess if we are speaking about bikes vs cars, we can also discuss carbon footprint .. yes a bike is better, but so is a Tesla. However, I'm not sure how this analogy is relevant. But I am not here to ask which language is better. I guess I just want to know if anyone with context and experience with rich languages such as C# have valid reasons to move to Go, since it seems from the video I posted, C# has all the features of Go and more. And no I am not that guy in the video. </p></pre>jeffrallen: <pre><p>Go does not have a roadmap because Go is not about adding. Go is about what's possible today and what will make just that better. So do the Go tour. Read Effective Go. Those will show you show you what Go is good at. If you want to do that then use Go. If not, that's ok too.</p>
<p>Jeff</p></pre>kaeshiwaza: <pre><p>It's me i'm sorry, my english is so poor that it's difficult to make some humor ! I've no doubt your question is valid.</p>
<p>More seriously, what I want to say is that the main goal of Go is simplicity (less is more). For example you can read and understand all the specifications of Go in one day and make your first program the next day. We have <code>for</code> and we don't want to have <code>while</code>, we have <code>if</code> and we don't want to have ternary operator and so on... Not because we are masochist but because we want to read the code of anybody else (can be us in some years) without thinking about a magic feature of the language that we forgot to learn. When i compare with bike it doesn't mean that it's better, it means that the use are so different that it's impossible to compare feature by feature, even if we are on the same road...</p>
<p>To answer your question, yes Go is mature, so mature that it will not change (or very few, just if somebody can show that something is really broken). It's easy to see by yourself, I invite you to just try.</p></pre>shark1337: <pre><p><strong>Learn it if you're gonna use it.</strong></p>
<p>If you came here just to ask if you should use Go, you probably don't need it unless you have a real use case. I'm not trying to stop you from learning Go, at the end of the day, you decide what fits the best for you ;)</p></pre>colezlaw: <pre><p>"matured with more features" is a phrase which will make Gophers very unhappy. Go is mature because it has so few features. Generics are the first thing folks want from other languages. After having programmed in Go for some time, I never miss generics. I don't want or need Go to be more like other languages. The beauty of go is that you can learn all the syntax in an afternoon. And then, almost every program you write will use almost all of the available syntax - you don't have to go look at a document to remember how to use some obscure feature - you used all the features in your last program. </p>
<p>Yes, I've drunk the Go Kool-aid - but it's Go's lack of baggage from other languages which makes it such an elegant language to learn, program, and most importantly, read. </p></pre>shovelpost: <pre><p>Nice find. I actually feel sorry for the guy.</p></pre>mikerrr07: <pre><p>oh wait, what do you mean by you feel sorry for the guy? Are his points about Go in the video not valid? This guy seems pretty smart .. check out this blog post from a year ago. <a href="https://blog.rendle.io/what-ive-learned-about-dotnet-native/" rel="nofollow">https://blog.rendle.io/what-ive-learned-about-dotnet-native/</a><br/>
tldr; "This all means that C# is about to enter Go territory – a cross-platform, natively-compiled, garbage-collected programming language. Except, of course, that C# has modern language features like generics, async/await, etc."</p></pre>shovelpost: <pre><blockquote>
<p>oh wait, what do you mean by you feel sorry for the guy?
Are his points about Go in the video not valid?</p>
</blockquote>
<p>In my opinion they really are not. He is one of the many that doesn't "get" Go.</p>
<blockquote>
<p>This guy seems pretty smart .. check out this blog post from a year ago. <a href="https://blog.rendle.io/what-ive-learned-about-dotnet-native/" rel="nofollow">https://blog.rendle.io/what-ive-learned-about-dotnet-native/</a></p>
<p>tldr; "This all means that C# is about to enter Go territory – a cross-platform, natively-compiled, garbage-collected programming language. Except, of course, that C# has modern language features like generics, async/await, etc."</p>
</blockquote>
<p>I never doubted how smart he is. But that article you just linked confirmed my suspictions. He really thinks that "more is better" while I believe that <a href="https://commandcenter.blogspot.gr/2012/06/less-is-exponentially-more.html" rel="nofollow">less is more</a>. If you read that article carefully, you will also get the answer to your question about if generics would help attract C# developers. </p>
<p>Also I think <a href="/u/cdoxsey" rel="nofollow">/u/cdoxsey</a>'s <a href="https://www.reddit.com/r/golang/comments/6nlc4r/would_generics_help_c_developers_move_to_go/dkafu7c/" rel="nofollow">answer</a> summarized it very well.</p></pre>holyjeff: <pre><p>From what I read CoreRT still has pretty huge performance "problems" as compared to how Go works.</p></pre>Kraigius: <pre><p>I'm a C# developer and I started learning/working with go for small personal projects a year ago. I haven't had to use complex data structure for my projects where generics would have saved me headache and development time.</p>
<p>The only thing that made/makes the learning experience difficult is moving from an OOP language to a <del>functional</del> procedural one.</p></pre>allowthere: <pre><p>Go isn't a functional language. Go is Procedural. Something like Haskell is functional.</p></pre>Kraigius: <pre><p>Shit, sorry you are right. I did meant procedural.</p></pre>smantziaris: <pre><p>Why not C++? C++ can give you single binary and better performance. ;)
If you check <a href="https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=csharpcore&lang2=go" rel="nofollow">https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=csharpcore&lang2=go</a> you can see that the performance is not so different or not different enough to make the change just for performance reasons.
The reason for changing are wrong in my opinion.
You should consider changing the language if the language is more suited for your job.
First you should learn the new language and then decide if it makes sense. Every case is different.
BTW we have a big project (1M LoC) written in C#. It is really hard for me to imagine writing the application in go since:
1. go has no generics and other stuff it would be a lot more than 1M LoC probably 2M LoC
2. Working with VS (debugging etc) is ... you know
3. Dependency management comes OOTB, still waiting for dep which should be present since 1.0
4. I think that go will some time in the future add stuff to it. Generics are in Go 2.0 or was it a hoax?</p>
<p>One observation:
The languages and the developers tend to get smarter. 20 years ago the languages where simple (not easy). Nowadays the languages are getting smarter and give the developer more with fewer lines of code. Language complexity is a problem but we are getting smarter too (or not).
Take for example F# and do not mind about the functional aspect of the language.
1. Pattern matching is a killer feature
2. The advanced type system is fantastic
3. You can make the same program in F# with a lot less LoC, which is the advertisement (less lines of code, less bugs, more code in your screen etc)</p>
<p>If the language can convey more in a easy way with less code i am all for it!
I personally do like complex languages. After a while you get to read complex statements easier and thank god that you do not have to see 5 screens in order to understand how things work.
BTW: Most liked language in a StackOverflow report <a href="https://insights.stackoverflow.com/survey/2017#most-loved-dreaded-and-wanted" rel="nofollow">https://insights.stackoverflow.com/survey/2017#most-loved-dreaded-and-wanted</a> are complex languages. Check top 10 to see.</p></pre>aboukirev: <pre><p>Pattern matching is not so much a feature as a necessity to be able to work with sum types efficiently. And sum types are often a crutch to overcome single return value limitation of functional languages.
Sometimes these features are great but it's not always sunshine.</p>
<p>LoC, while a useful metric, can only apply when you compare apples to apples, so to speak, i.e. code in the same language. Even for the same language, say Perl, one can have very compact code but try maintaining that. Consistent and clear syntax is more important. I am still fond of Pascal and don't mind its verbouseness at all.</p></pre>smantziaris: <pre><p>Pattern Matching and sum types are great, sorry to disagree. Check out this video <a href="https://vimeo.com/97507575" rel="nofollow">https://vimeo.com/97507575</a> where Scott shows how to create a domain model just by using types, making invalid model state unrepresentable with the types he chooses.</p>
<p>LoC was mentioned just that there will be more code to maintain.
Maybe simpler but still more code (which can mean more bugs).
Who would say that the following statement is hard to maintain (C#)?
var list = new int[] { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
var sum = list.Sum();
What would the equivalent code in go be? (At least twice that)</p>
<p>Every language has it's value and every developer has to decide what that is.</p></pre>holyjeff: <pre><p>I think it is not the generics that would make .net developers to switch. .NET/C# has a huge ecosystem going on and a lot of it just does not exist in Go world.</p></pre>lonahex: <pre><blockquote>
<p>for two reasons, single binary and better performance.
.net can have single binary and cross compile similar to Go; and faster compilation and runtime now</p>
</blockquote>
<p>I think you should stick to C# unless you really need something Go has that C# does not or unless you find working with Go more fun.</p></pre>
