
Announcing .NET Core 2.1 - benaadams
https://blogs.msdn.microsoft.com/dotnet/2018/05/30/announcing-net-core-2-1/
======
algorithmsRcool
This is a landmark release for .NET.

The most important since at least framework 4.0 maybe even 3.0.

We are getting:

\- Span<T>/Memory<T> : A 0-copy, unified way of accessing Managed or Unmanaged
memory.

\- Channel<T> : High performance thread-safe queues (like go channels)

\- Pipelines : an async, 0-copy version of Stream

\- In-box support for Array/Buffer pooling (finally!) (MemoryPool, ArrayPool)

\- Better primitives for pointer manipulation and memory marshaling.
(MemoryMarshal)

\- New primitives for high performance parsers and formatters
(System.Buffers.Binary and System.Buffers.Text)

\- Improved support for SSE/NEON via Vector<T>

\- Microsoft.Windows.Compatibility : Windows specific APIs on .NET Core
(Registry, EventLog, NamedPipes...)

\- Tiered Compilation

\- Faster tooling

\- Wider Platform support

If you write code on .NET, you should [Edit] evaluate this release with to see
if it fits your business needs [/Edit]

Doubly so if you care about runtime performance.

~~~
gitgacutils
> If you write code on .NET, you should adopt this release ASAP.

If you require the new features maybe, but if you are writing enterprise code,
you shouldn't rush into things.

> Doubly so if you care about runtime performance.

Everyone cares about runtime performance, but if your software isn't
experiencing performance issues, there is no need to rush into things. Or at
the very least, reach out to your clients to get a feel about their schedules
and expectations.

#1 rule: if it ain't broke, don't fix it.

~~~
carlhjerpe
This is how legacy code is created isn't it?

~~~
Sir_Substance
There are lots of ways you can end up with legacy code.

I've seen legacy code get created by people postponing platform updates for so
long that the upgrade pathways stop being supported, that's one way.

I've also seen legacy code get created by people adopting the platform of the
future super-early, and then being left high and dry when the rest of the
world decided that platform wasn't actually the future after all, leaving them
as the sole maintainers of the entire platform as well as their dependent
code.

If your code currently works on standard .net, there's no reason to be in a
massive hurry to move to .net core. There's not necessarily any reason to
delay, either. It all depends on your business requirements and the investment
required. If it's easy for you to move to .net core then by all means do it.
If it's gonna be a massive project, let the smaller groups go first.

~~~
carlhjerpe
> I've seen legacy code get created by people postponing platform updates for
> so long that the upgrade pathways stop being supported, that's one way.

This is something i've seen many times, when you don't update in long enough
entire API's might've changed or been replaced and there's no documentation or
anyone even remembering the stuff available anymore.

I agree though that one doesn't have to rush new releases, i do however think
there should be a plan to upgrade done as soon as there's a new stable
release.

I've been working with a softphone that's built for .net framework 3.5, if you
want any library you can forget nuget, must get source build and modify
manually. Which is suboptimal.

------
MarkSweep
This does not mention my favorite new feature:
BindingFlags.DoNotWrapExceptions. It lets you prevent exceptions from being
wrapped in TargetInvocationException when invoking methods using reflection. I
wrote about this feature here if anyone is interested:
[http://www.awise.us/2018/04/25/do-no-wrap-
exceptions.html](http://www.awise.us/2018/04/25/do-no-wrap-exceptions.html)

~~~
CodeCube
wow, this is huge for some use cases!

------
kgwxd
Just a reminder, telemetry is opt-out:
[https://news.ycombinator.com/item?id=17177241](https://news.ycombinator.com/item?id=17177241)

Be sure to check your environment variables are set properly. Also, be sure to
check that they haven't added additional opt-out settings, or remove the
ability to opt-out all together. If you haven't opted-out on purpose, be sure
you're still OK with what they're collecting.

------
nlawalker
Humble request: can anyone explain whether or not Span<T> is interesting if
you mostly work with application code (as opposed to, say, low-level or
framework code) and never work with unmanaged/native code, and why?

From my perspective, it seems like something that'll be used in the guts of
ASP.NET and the rest of the base class library that will benefit the
performance of my code, but I'd never really use it directly.

~~~
zamalek
Span (safely refers to data anywhere) and Memory (safely refers to data on the
heap only) have a much nicer API than arrays. ArraySegment has had a facelift
but to nit: ArraySegment is a pain to type. Also, unlike arrays, there are
read-only variants - which are good for rich type checking. In addition you
can easily reinterpret cast between blittable types (the new 'unmanaged'
generic constraint) for when you are participating in mortal sins such as
directly serializing byte representations.

Tons of reasons to use them besides performance. We use them for those reasons
and if there is a performance boon, great bonus!

~~~
nlawalker
This appears to imply that for brand new code with no dependencies, arrays are
essentially obsoleted by Span/Memory. Is that a fair statement?

~~~
zamalek
Mostly, yes.

------
alexeiz
Is there any data on the size of the .NET Core user base? It was my impression
that .NET Core was unsuitable for production deployments so far. Also, .NET
Core is primarily targeted at Linux users, right? Why would you even consider
using .NET Core on Windows when you can utilize a fully featured .NET
Framework?

~~~
runfaster2000
Few points:

\- Deployments:
[https://www.microsoft.com/net/customers](https://www.microsoft.com/net/customers)

\- Monthly engaged developers is >500k for NET Core.

\- >50% of developers are on Windows.

~~~
sjellis
Note that some of the pull quotes on that site don't specify .NET Core, and
probably predate it (e.g. the Stack Overflow story dates back to 2014, and
refers to Framework).

We know that .NET Core is generally liked by Microsoft developers (with good
reason), but I have no idea what corporate adoption is like, and would love to
see indicators that people are actually migrating production systems. The
existance of Core makes Framework that bit more annoying to deal with, and it
would be nice to see that things are moving.

~~~
oaiey
Stackoverflow team contributes to .NET Core itself since pre 1.0 dates. It is
a pretty safe bet that they use it in production.

Corporate adoption is very good afaik. For .NET developers, .NET Core is a lot
of fresh air and also a long overdue defence against Node. They want to
continue to work with C# :)

~~~
pjmlp
> For .NET developers, .NET Core is a lot of fresh air and also a long overdue
> defence against Node.

Really?! US .NET developers or what?

I never worried about Node ever, with so many nice languages in .NET and Java
worlds to chose from.

------
runevault
Anxious to finally play with this, been wanting the full library/stack update
for span<t>/memory<t> to get a feel for actually using them to optimize code.

~~~
algorithmsRcool
I've been moving some libraries over from T[] to Memory<T> and Span<T>.

I've found it's a little tricky to get used to calling Slice() all the time.
But it opens up so many doors for allocation reduction and perf improvement.

Also, it is so nice to not have to pass (array, offset, length) around
everywhere

------
shock
I'm most excited about the added SourceLink support. This will allow us to see
and navigate library sources right in the IDE and also allow us to step
through library code when debugging.

------
parvenu74
I wonder if it was on purpose or accident that the LTS release of .NET Core
coincides with the LTS release of Ubuntu...

~~~
runfaster2000
No relationship to the 18.04 LTS, but we were following that release closely.
We started testing on 18.04 at the start of the year, and offering Docker
images for it at around the same time. We're also watching the Alpine 3.8
release closely.

~~~
parvenu74
Any chance .NET Core is going to be supported on FreeBSD/NetBSD/OpenBSD in the
near future?

~~~
tybit
As part of Google Summer of Code a participant is looking at porting .net core
to FreeBSD
[https://github.com/dotnet/coreclr/issues/18067](https://github.com/dotnet/coreclr/issues/18067)

------
scott00
One benefit caught my eye, but was not explained:

"Much easier to manage platform dependencies in project files and with self-
contained application publishing."

Anybody know anything about this? I frequently deal with applications that
have platform specific components, and it's a real pain. Sometimes the
platform specific code is a platform-specific native dll that gets called from
the same P/Invoke wrapper, sometimes it's two different managed
implementations of the same interface, sometimes it's both. It'd be great if
this sort of thing got easier to do.

~~~
runfaster2000
Sorry! Poor wording on my part.

I updated the wording to: "Much easier to manage .NET Core and ASP.NET Core
versions in project files and with self-contained application publishing."

The thing that you are talking about still needs to be improved. Sadly, that
didn't happen in this release.

------
ksec
And I just realise, .Net Core is MIT licensed..... that is far too good to be
true right?

Given the immense engineering hours went into CoreCLR, why aren't more
languages built on top of .NET runtime?

~~~
oaiey
Why more if you have good oo, procedurel and functional contenders :). C# and
F# are top contenders in their areas.

Language alternatives show up by need (not given here) or specialization
(niche you never heard of).

------
yummybear
Does anyone else experience high CPU on mac when running dotnet run?

------
hnrodey
Any idea about required VS versions? The announcement makes no mention of
Visual Studio (or maybe I missed it?) but the download pages says it requires
a preview version of VS2017 which is unfortunate.

~~~
algorithmsRcool
So the .NET Core SDK and command line tools do not require VS at all. VSCode
works fine or whatever editor you like that supports omnisharp.

But if you are using VS you will need to update to 15.7 to take advantage of
some of the features/

~~~
vonseel
What is the best setup for coding .NET core on Mac? Rider? Asking because you
seem to know what you’re talking about.

~~~
jen20
Rider is definitely the best IDE for .NET, regardless of platform.

~~~
pjmlp
I very much doubt it, given how InteliJ works on my laptop versus Visual
Studio 2017.

Also where are Blend, the GUI tooling and rich debugging features from VS?

~~~
mythz
It is, I use both frequently and use Rider whenever I can and VS 2017 when
working on projects Rider doesn't support. Although I don't use Designers so
if you're building .NET GUI Apps VS 2017 would be better, but Rider is better
for Web Apps, esp. Single Page Apps.

VS 2017 is the most unstable I can recall in recent memory, with constant
crashes and White Screens of Death.

~~~
naasking
> VS 2017 is the most unstable I can recall in recent memory, with constant
> crashes and White Screens of Death.

Hmm, opposite of my experience. VS 2010 was the worst, and VS 2017 is actually
pretty nice. Very frequent updates though, which is a little annoying.

~~~
megaman22
2017 gets to be a little bit of a problem if you've got the Git tooling and
ReSharper both going at the same time. On bigger solutions you're going to be
hammering your disk swapping, so better hope you've got your code on an SSD,
and that you've got exceptions in your antivirus to avoid real-time scanning
those locations.

~~~
vonseel
Thanks for the info all above posters. Sounds like dislikes for Rider are
mostly from Windows users or people who need GUI support. I'm on Mac and have
a lot of experience with Jetbrains IDE's so that's probably my best option.

------
ryanmarsh
What is the difference between Core and Framework?

~~~
dustinchilson
Core is a portable re-implementation of the Framework

[https://docs.microsoft.com/en-us/dotnet/standard/choosing-
co...](https://docs.microsoft.com/en-us/dotnet/standard/choosing-core-
framework-server)

~~~
ksec
So basically a renamed Mono?

~~~
oaiey
It is the runtime from the Silverlight Project, which evolved over the years
for their Windows Phone and later UWP platforms. .NET Core is a very old
platform already. It shares the jitter and the garbage collector with the full
framework.

It is actually the opposite of your statement. Mono is massively adopting .NET
Core source code but without loosing their own benefits (portability and
factoring).

------
snake_plissken
Where is the source for this or is it not up yet? Jones'n to dive into
Channel<T> to see what's going on in there.

~~~
halter73
For Channel<T>, you can take a look at
[https://github.com/dotnet/corefx/tree/v2.1.0/src/System.Thre...](https://github.com/dotnet/corefx/tree/v2.1.0/src/System.Threading.Channels/src/System/Threading/Channels)

------
yread
Anybody knows how much improvement can you expect from tiered compilation? And
are there any drawbacks - is it stable?

~~~
runfaster2000
It depends on your app. We've seen _massive_ improvements for webservers and
long-running apps. Short-lived apps don't benefit. We'll be posting more on it
soon. Give it a try!

~~~
algorithmsRcool
This guy works on dotnet his answer is much better than mine.

