.NET Core vs. Golang
groups.google.com
groups.google.com
IMHO you must consider nodeJs.
I love node... but it's not always the right fit... dealing with that for something at work now... I'm like if we can break it up through an MQ, awesome, otherwise node will be a very bad fit.
There's also the aspect of typos, or grammatical error that I'm inclined to let slide in one setting and not others. In this setting, I'm less inclined to use leet-speak shortcuts though.
That being said, if there is a future need/want to migrate to Linux, go makes a lot more sense than .Net core simply from the standpoint of Linux support being so new and frankly, foreign to Microsoft. They're doing it to help with Azure, but that doesn't mean it is entirely stable and bug-free. If their developers aren't heavily testing it, why would you want to build production applications using it? If your ecosystem is fundamentally entirely Microsoft based as are the developer teams, switching to golang and its own idiosyncrasies seems like quite the tall order, even if it might result in a better team ultimately.
I have been complaining recently because I am constantly fighting space on my 512GB MBP due to the Linux and Windows VMs and all the Docker usage. My colleagues were smarter and got the 1TB versions to avoid this problem. I guess mine needs to be garbage collected.
That must seem quaint for some readers, but is a strong suggestion of a big shift from 5 years ago and will only continue for this team. Totally agree that you need to live and breath Linux if you want to have a compelling and competitive dev platform for it.
For the code-base itself, the move to nix is not at all new. CLR supported BSD Unix as early as 2000. The source was published for the BSD version through 2005. Silverlight brought new life into the codebase with Mac support (the earlier choice to target BSD was a prescient one). And then, the source did indeed lay unloved for multiple years and was revived again a few years ago. We started where we had previously left off and moved forward, a lot.
Many of the engineers have worked on at least two of our nix projects. A couple have worked on all 3. They are very happy to be working on it again and under very different circumstances.
Main point is that *nix support is not new for the codebase and for a signficant number of folks on the team. Being competitive on Linux is indeed the new thing. No question there! We're very happy to play in that space, in terms of runtimes, libraries, languages, tools and support.
Last, we have moved our web properties (that the team owns) to .NET Core on Linux, some time ago. With Azure supporting containers and orchestration, we will be moving those same web properties to Linux containers as the next step. We also use a ton of Linux in our test infrastructure. We are actively using Linux, happily.
I think one very weak point is the native support/debug tooling, and the lack of communication about the roadmap of those.
- debugging a running app on Linux, - tracing a running app on Linux, - creating a dump of a running process and analyzing it on Linux - profiling a process on Linux - resolving addresses to symbols (for use with tools like perf) - being able to record these data and analyze in visual studio "offline" on a different machine.
It would be important to communicate about these, as these are very weak points for someone new to the platform (and frankly, everybody, even experienced .Net folks are new to this, as the common windows tools are not available, and the Linux tools are not applicable, or unknown how).
These are needed to deploy an actual service on the platform, and must be considered. The Java world offers very strong tooling on these grounds, and I think that is what .Net Core has to compete with in these topics, as that is the most mature cross-platform application platform, way more mature than Go, node, and other hyped platforms.
This very day we found a strange problem in an app running on .net core 1.0.0 in docker on Linux in azure, and we didn't know how to start with trying to trace down the problem, and the lack of information found on the internet was annoying.
Your point on roadmap is also well-taken. We're on the cusp of communicating our plans for the next version, and will be looking for more feedback like this.
Happy to take your issue offline if you'd like. It may help inform our future diagnostic plans. I'm rlander@ms.
Yes, Miguel and I are friends and work together frequently. Usually, he's badgering me, asking me when my team is going to deliver something we promised. We are now starting to adopt more of the Mono/Xamarin tech (in this case, their assembly linker), so the relationship is reversing. Here's a video of us together (where he makes fun of me): https://channel9.msdn.com/Events/dotnetConf/2015/The-NET-Voy...
Haven't started looking at the GNOME ecosystem yet. I'll leave that to Miguel to make suggestions on.
I've used .NET Core after 1.0 expecting it to be "production ready" for a new project, but so far from my expirience the 1.x releases have been like working with RC product and it should have been labeled as that with a clear note that the tooling is not done. RC versions should have been labeled as betas. There are so many moving parts (EF Core, .NET Standard Library vs PCL) and ambiguities (what tooling versions are supported in which VS, how does upgrading to a new preview affect old projects - can I safely use VS2017 and 15 on the same project, when 15 won't support MSbuild integration yet ?) it's a mess and it turns people off, even most .NET devs I know don't have a positive image of .NET core ATM.
A shame because it's doing some really exciting stuff, the communication is kind of disappointing because it makes it harder to convince other people it's actually exciting stuff.
If we were to do it all again with the knowledge we have now, we would skip all the changes and move directly to the final plan. We're sad about the resets, both to our users and because we were not nearly as efficient as we could otherwise have been. We're now on a much more solid plan and are working to land it.
Anyway .NET is too big for this to be detrimental and I'm only complaining because I like the work being done and the situation is turning off more traditional enterprise devs who have different expectations (eg. tooling in VS is still iffy but on 1.0 it wasn't even working when a colleague tried it). You guys still deserve a huge pat on the back - you used to be a pot smoking hippie if you used OSS in the .NET side of enterprise, now those people are contributing on GH, using git on VSO, using CLI tools that can be automated easily, etc.
You may have more enterprise-like experience, thus expectations, but frequent releases based on feedback are usually better for the users than a project manager trying to guess the needs of the users by some magical, or other means.
I rather live with this kind of projects, but I have been a desktop Linux user for half a decade (when it was more painful), so I may be missocialized :D
As stated in another comment, I also think that the communication could be improved, but I'm hoping the best, the new more direct means of communication are really promising for me personally.
Go shines when it comes to serving a webpage, connecting to the database and processing shitloads or buttloads of data.
C#/.NET has been the most pleasant language I've ever worked with hands down no seconds. But it sucks if you want to develop something that runs on a small server or needs to serve shitloads or buttloads of data.
Also C# has Visual Studio and the Form Designer in it, which is probably the best GUI Creator on the market.
Core is not there yet (AFAIK) but making progress.
Quite frankly, convincing and demonstrating to your co-workers that this change will be good is the first thing you should do after you have convinced yourself.
C#, .NET core is cross-platform.