4 ms·

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 go

by SEJeff 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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.
- SEJeff 10y ago
  Hey thanks for the detailed and long reply, I really appreciate it. Is it safe to assume you work on this team at Microsoft? Would you be ok saying what team in specific you work on? Do you work with Miguel (for instance) on any of the Xamarin stuff? I am a long time GNOME guy and loved to see the merger + integration of that stack into Microsoft.
rubber_duck 10y ago
Honestly the lag between the ".NET core 1.0" and "tools 1.0" is kind of a joke at this point. Why advertise .NET core as 1.0 when it's obviously not production ready (in terms of .NET standards/expectations) almost half a year after the release. Why introduce all those breaking architectural changes in the "RC" versions ? 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.
- runfaster2000 10y ago
  The tools story that you raise is a real challenge, for users and for the team. I agree with you. As we were reaching RTM, we realized we had gotten ourselves wedged, pretty significantly. We had fortune 500 customers in production on our pre 1.0 RTM betas who were pushing hard for a 1.0 RTM runtime stack. At the same time, we came to the conclusion that the tools were not ready and needed significant changes (many of them breaking, as you call out). We decided to ship the runtime as RTM (now twice) and leave the tools in preview. The customers who were pushing hard are now happy (modulo the tools changes) and we're continuing to push forward. 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.
  - rubber_duck 10y ago
    Intrresting, I always assumed that the whole mess was caused by management pressure to ship something ASAP, I just didn't figure it was outside management pressure :) 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.
tracker1 10y ago
Depending on your needs, mono is decent... I've managed to run a few things under a mono-onbuild docker container... Though that does take a little more work.

by SEJeff 10y ago

runfaster2000 10y ago

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 10y ago
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 10y ago
  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.
SEJeff 10y ago
Hey thanks for the detailed and long reply, I really appreciate it. Is it safe to assume you work on this team at Microsoft? Would you be ok saying what team in specific you work on? Do you work with Miguel (for instance) on any of the Xamarin stuff? I am a long time GNOME guy and loved to see the merger + integration of that stack into Microsoft.

rubber_duck 10y ago

Honestly the lag between the ".NET core 1.0" and "tools 1.0" is kind of a joke at this point. Why advertise .NET core as 1.0 when it's obviously not production ready (in terms of .NET standards/expectations) almost half a year after the release. Why introduce all those breaking architectural changes in the "RC" versions ? 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.

runfaster2000 10y ago
The tools story that you raise is a real challenge, for users and for the team. I agree with you. As we were reaching RTM, we realized we had gotten ourselves wedged, pretty significantly. We had fortune 500 customers in production on our pre 1.0 RTM betas who were pushing hard for a 1.0 RTM runtime stack. At the same time, we came to the conclusion that the tools were not ready and needed significant changes (many of them breaking, as you call out). We decided to ship the runtime as RTM (now twice) and leave the tools in preview. The customers who were pushing hard are now happy (modulo the tools changes) and we're continuing to push forward. 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.
- rubber_duck 10y ago
  Intrresting, I always assumed that the whole mess was caused by management pressure to ship something ASAP, I just didn't figure it was outside management pressure :) 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.

tracker1 10y ago

Depending on your needs, mono is decent... I've managed to run a few things under a mono-onbuild docker container... Though that does take a little more work.