
.NET Core vs. Golang - vikas0380
https://groups.google.com/forum/#!topic/Golang-nuts/_6K8SpMFsTM
======
0xmohit
The best message [0] in the thread:

    
    
      IMHO you must consider nodeJs.
    

[0] [https://groups.google.com/forum/#!original/Golang-
nuts/_6K8S...](https://groups.google.com/forum/#!original/Golang-
nuts/_6K8SpMFsTM/TITjtP5jBwAJ)

~~~
tracker1
There are some things that node is great for... even some automation tasks...
not sure that a web scraper is an ideal example... pretty much anything
dealing with huge streams isn't a great fit, and getting the back-pressure on
streams right in node is sometimes hard. A lot of db's for example may not
expose cursors for being able to do a record at a time, so you'll get it
shoved in... and before you can process the million records, node will crash.

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.

~~~
pitaj
Holy... ellipsis... Batman...!

~~~
tracker1
I tend to write conversationally, closely to how I speak. I wouldn't write the
same way if this were a white paper, research or other types of instruction.
In more casual conversation I will pause to think... Then continue speaking, I
do the same when writing online in casual settings.

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.

------
SEJeff
That was a pretty amusing way of getting the conversation started, but
fundamentally they are two entirely different things. The IDE tooling for .Net
is very good, but .Net Core is still super new and not really "production"
grade yet. It doesn't even fully integration with MSBuild if I recall
correctly.

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.

~~~
runfaster2000
You are correct that Linux is new to many folks on the .NET team. For another
set of folks, it's a return to an old friend. Some team members have switched
to a favourite Linux distro as their primary computing environment, even at
home. About half of the team is now using MBP as their main computing device.

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.

~~~
kodfodrasz
This may be slightly off-topic, but I'd like to grab the opportunity to give
some direct feedback to a member of the .Net Team.

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.

~~~
runfaster2000
Great point. I agree with you. We know that this is a weakness. We had a
planning meeting yesterday where we discussed this very scenario and want to
shore up this space significantly.

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.

------
dodyg
If you are checking out ASP.NET Core, my project would be useful for you
[https://github.com/dodyg/practical-
aspnetcore](https://github.com/dodyg/practical-aspnetcore)

~~~
oldmanhorton
This is fantastic! ASP.NET Core documentation has definitely been lacking for
some things, and I learned a ton from this.

~~~
dodyg
I am glad you like it

------
tscs37
IMO the best choice depends on what you want to do. Like always.

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.

------
KirinDave
It really seems like the question is all about "I'd like to use this new thing
but I'm afraid I cannot convince my co-workers."

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.

------
FrancoDiaz
_We want to switch to something crossplatform and stick with it for all new
projects._

C#, .NET core is cross-platform.

~~~
tracker1
In the near term, you'll be targeting mono, .Net core isn't baked all the way
yet.

------
UK-AL
Being go forum, I doubt it's going to be balanced argument.

------
tmitchel2
It's great news for MS that these are even being compared. However, more
importantly...let the flame wars begin!

------
sremani
What realistic framework do we have if we have to convert a asp.net project to
go-lang based solution.

