<p>I like Go and I want it to succeed, but the playing space just got a bit more competitive.</p>
<p>.NET is going cross-platform. Go has been one of the best platforms with GC that's available on Mac, Windows, Linux and FreeBSD. I think Android is there as well. With .NET entering the same space and its excellent set of libraries, the might be less motivation to use Go and all the motivation to use .NET due to its great developer support (Visual Studio, Debugging, profiling, etc).</p>
<p>Will and why Go maintain its relevance now?</p>
<p>Thanks</p>
<hr/>**评论：**<br/><br/>beefsack: <pre><p>Go sits in a different niche in my books, there's space for both to be successful.</p></pre>devsquid: <pre><p>Lol, but this is the tech scene. There. Can. Only. Be. One. 0.0</p></pre>vorg: <pre><p>The backers of Go, .NET, and Java seem to think so anyway, as is the way with big software corps like Google, Microsoft, and Oracle. Every decision they make wrt the respective languages is to better compete with each other for developer mindshare.</p></pre>jp_fielding: <pre><p>Go is about low complexity in development, windows dev has always been anything but. Apples and oranges.</p></pre>anoobisus: <pre><p>Be careful before you speak.</p>
<p>In a pair of commands you can have a fully functioning CoreCLR environment running on your machine[. With your next command your app is running with hot-reloads (without a full AOT compilation step).</p>
<p>No xml in sight. A couple json files declaring my nuget dependenices. That's it. Nothing else. In a few days it won't require mono at all on the box. Everything is open source.</p>
<p>Shit is changing. I don't think it poses a threat to Go, even remotely... but this is a new world.</p></pre>Saucysauce: <pre><p>I think <a href="/u/jp_fielding" rel="nofollow">/u/jp_fielding</a> was saying that <em>low</em> complexity (edit) is the goal. What you described doesn't sound "simple", but it does sound powerful. Can you explain why you think what you described is simpler?</p></pre>anoobisus: <pre><blockquote>
<p>What you described doesn't sound "simple", but it does sound powerful.</p>
</blockquote>
<p>... how?</p>
<p>It's virtually the same extact steps from nothing to running for Go and the new .NET stuff on Linux. One extra step because they baked in version runtime management from the beginning.</p>
<p>Go:</p>
<ol>
<li><p>install go</p></li>
<li><p>godep dependency file + golang source + go get + go run = running web app</p></li>
</ol>
<p>(ASP).NET5:</p>
<ol>
<li><p>Install dot net version manager (dnvm)</p></li>
<li><p>Install execution environment (versioned) (dnx)</p></li>
<li><p>project.json + Startup.cs file + dnu restore + dnx . web = running web app</p></li>
</ol></pre>Saucysauce: <pre><p>I'm unfamiliar with most of the steps you listed, which is why I was asking. Go doesn't require a project file, a startup file, etc. I'd say Go is inherently simpler given the steps you listed (just my opinion).</p>
<p>Putting aside 3rd party code and the initial install (which are pretty universally the same in all languages, albeit more complex in some), your steps in Go are :</p>
<ul>
<li>Source code</li>
<li>go run</li>
</ul>
<p>That still strikes me as the simplest build cycle in a modern language. What you described includes more.</p>
<p>Honestly, I don't really care about .NET, as I have no use for it at all, and I was just trying to clarify a minor point. I don't think it's useful for us to compare what we think is simple ; I was mostly curious and it appears we disagree. Thanks for posting!</p></pre>anoobisus: <pre><p>Startup.cs is just a convention. main.go. project.go. whatever. It's just the entry point.</p>
<p>A good go project will have vendored dependencies or a Godep file. I doubt you'll find a serious, non-library application that lacks vendored dependencies or a Godep file. That's all project.json is. But, I mean, you can get away without Godep, so there's that... otherwise, very, very similar.</p>
<blockquote>
<p>I was just trying to clarify a minor point. I don't think it's useful for us to compare what we think is simple</p>
</blockquote>
<p>IMO, it's not a minor point. The new runtime and literally 30-seconds-from-nothing-to-running development environment is the reason that I'm happy with the .NET stack. It's the reason I wrote this comment.</p>
<p>It was also apparently enough for the top comment to dismiss the entire article by saying "eh, probably still too hard/too much cruft"</p>
<p>I hate the abomination that is MSbuild and Visual Studio and all that jazz. I understand. I understand the desire to fallback on assumptions based on years of Microsoft legacy, but it's borderline FUD when it's parroted by people who admittedly have no experience with the new stack.</p></pre>Saucysauce: <pre><p>Thanks for clarifying! Yeah, given that, I'd agree, they're fairly equivalent.</p>
<p>Hmmm. I get the idea that people should look at this stuff with an open mind, and I agree. Frankly, I am shocked that I would ever utter the words "Wow, MS is really doing cool/useful shit lately".</p>
<p>But I wouldn't confuse that with people's desire to stick with what works. While I personally investigate a ton of things that have nothing to do with my current work, I can personally attest to having worked with hundreds of developers who don't feel that way.</p>
<p>I will also say that, while you may not have personally suffered from Microsoft's behavior and choices over the years, I have and it will take more than a quick burst of awesome to overcome that. We're talking years of good behavior and adoption of non-MS platforms.</p>
<p>Admittedly, what they're doing is awesome. It just needs to bake for a while. It seems reasonable for people to pass over things that come from an untrustworthy source.</p></pre>anoobisus: <pre><blockquote>
<p>I will also say that, while you may not have personally suffered from Microsoft's behavior and choices over the years, I have and it will take more than a quick burst of awesome to overcome that. We're talking years of good behavior and adoption of non-MS platforms.</p>
</blockquote>
<p>I have. I do. I curse Windows and Visual Studio on a daily basis. Have you seen any of the stuff announced at BUILD? How can you say that with a straight face? Like literally, they just announced Obj-C, iOS, Android runtimes for Windows and recompilation of existing apps for Windows platforms. They've open sourced major debugger components. On and on. You can look it up if you're really, truly interested.</p>
<p>Azure/Linux folks have been out in the open for years, that's where Satya comes from... even by conservative counts this new OSS push is almost already a year, even being out in the open the naive public.</p>
<p>Dunno what you want. They turned their entire model for .NET on it's head in order to produce the DNX that allows for first party alternative implementations of the .NET runtime. Hope that you aren't saying "I just need more time" in another year :/</p></pre>Saucysauce: <pre><p>Were you trying to quote yourself with that first sentence, then are responding to it? I'll assume that's true.</p>
<p>I'm not sure which part you mean with a straight-face, so I'll try and answer the options :</p>
<ul>
<li>How can I say you have not personally suffered? I was interpreting your wording to mean that you suffer as part of your job, which I am not trying to downplay. I mean Microsoft's larger behavior with bullying, market manipulation, and the whole monopoly thing.</li>
<li>How can I say they're not adoption non-MS platforms? Sorry, that is a wording error. What I meant was, MS will have to behave well for years. Behaving well specifically includes non-MS platforms. They're off to a great start, but it's not enough for me yet. (I do follow their releases and was a huge fan of MS Research for years).</li>
</ul>
<p>I'll specifically say that they need to do pretty much everything close to "right" for years. Probably 5. I'm sorry if that disappoints, but they were pretty shitty to the companies I worked for and it made my life difficult. That's not easy to overcome.</p></pre>anoobisus: <pre><p>I mean, I don't care if you take 5 years to get over your grudge but 5 years ago no one knew wtf golang was, so don't mind me if I find it a bit absurd because ... do you plan to just ignore the entire ecosystem until, I guess maybe ~4 years from now? That's disappointing, and it doesn't really matter to me one way or the other. :(</p>
<p>Anyway, sorry you were burnt so badly.</p></pre>RagingAnemone: <pre><p>God, I hope so. I'm just starting a C# project (coming from Java) and the amount of configuration is unreal. Most of it is handled by the IDE, but still, there's lots of stuff to wade through when you touch files directly and fuck it up like I did. Part of the reason I like go was because a lot of the Spring magic was gone.</p></pre>brentrowland: <pre><p>.NET has been cross-platform for years, through Mono. Java has been cross-platform even longer. Both have great stories if you're comparing checklists of features. If the experience of actually using either platform doesn't convince you of the merits of Go, then that platform may be ideal for you and/or your use case. For some of us, Go is a welcome refuge from some of the anti-features of those platforms.</p></pre>Raiyni: <pre><p>Not really. Mono is not .NET, it is an implementation of the Common Language Infrastructure while .NET is Microsoft's implementation. Also, Mono is usually behind on new features. </p></pre>bmurphy1976: <pre><p>We've been running Mono in production for 9 years now. Mono is slow, buggy, memory inefficient, poorly integrated, and constantly out-of-date garbage. </p>
<p>It has some good engineering, but it also faces serious engineering challenges. It was <em>never</em> going to have a quality level of support. The community never bought into it and Xamarin never had the resources to properly support such a broad and complicated platform.</p>
<p>Unfortunately I feel Microsoft releasing CoreCLR is too little, too late. We started migrating away from .NET years ago and I see no reason to reverse that trend. Sure, some of our legacy apps may live on life support for the foreseeable future, but in terms of future investment? No thanks.</p></pre>mwholt: <pre><p>For many, it will come down to preference and needs, as usual. But indeed, .NET just got more competitive.</p>
<p>But I still think it's easier to use concurrency in Go.</p></pre>jamra06: <pre><p>Dotnet has a nice pattern with async/await that is pleasant. </p>
<p>The issue with dotnet lies in nested inheritance that increases complexity. </p>
<p>The threading is also not as minimal as go routines. </p></pre>bmurphy1976: <pre><p>Think about this for a minute: All Microsoft has released so far are some speculatory code dumps and a lot of wishful thinking. Turning that into a robust foundation that you can reliably build your business on is going to take a lot of work. At least two years by my reckoning.</p>
<p>How much is going to change in the next two years? How much will Go change? How much will other platforms (Haskell, Scala, Rust, Python, Ruby) change?</p>
<p>Another important question: will the community embrace this? Why should we expect that to change now? I mean, sure, this is the <em>new</em> Microsoft, and that's great, but that by no means guarantees the community will embrace this platform. </p>
<p>There are so many unknowns you should remain skeptical (always a good thing). If Go is working for you, great. The community has embraced it so it so it's going to stay. I see little reason why this new .NET would change Go's velocity.</p></pre>izuriel: <pre><p>I don't think there is any correlation. Mono has existed for a while - it has it's own slew of problems, I know - and anytime I've used it I've not missed any major feature from .NET proper that I couldn't do in Mono (I know there are examples, don't need to show them to me). </p>
<p>Right now the "cross platform" .NET things depend on Mono to some extent so it's probably not going to be made irrelevant soon. </p>
<p>Basically, the environment has already been on those platforms. I don't see this new push as any thin that would be threatening. It's also important to point out that Go is compiled natively while .NET languages are only IL on top of a runtime. There is a little more overhead there depending on what kinds of applications you plan on writing. </p></pre>icholy: <pre><p>I've been having similar thoughts. I really liked C# during the limited time I used it and never really felt comfortable depending on mono for production use (I base this on absolutely nothing). Go is awesome, but .net is more mature (and it has generics :p).</p></pre>devsquid: <pre><p>Aside from Mono, .NET on the Linux is not as 'mature'. It has only recently been announced. I am sure it will be a viable solution in a few years, so long as Windows Licensing doesn't weight it down in some way. That said, I view c# as being more of a language you write UI applications in while Golang for servers.</p></pre>nosmileface: <pre><p>Well in reality Go will beat .NET in performance. There is one major problem with C#. While it provides value types and .NET platform supports them, their use is very limited. For example you can't take an address of an existing List<T> (basically a dynamic array in C#) element if it's a value type. And it's not just about arrays, in Go you can take an address of a struct member and store it in a pointer. In C# you don't even have a pointer type (unsafe doesn't count). Aside from all the syntax sugar, that's the major difference between languages and the way you write code in them.</p>
<p>So in summary: In C# you have value types and structs, but you kind of avoid them and people suggest you to do so. In Go structs and value types are the way you write things by default. At the end Go programs end up generating much less garbage in memory and data locality is much better.</p>
<p>Go is a young language, we need to see what authors decide to add in Go 2.0 to really tell if it has bright future or not. </p>
<p>C#/.NET definitely stays as a valid choice for many projects.</p></pre>mgutz: <pre><p>Not always true. JVM currently beats Go in performance. No reason why CLR could not.</p></pre>
