www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is .NET 5.0 and C# 9 a "threat" to D?

reply Jack <jckj33 gmail.com> writes:
.NET 5.0 is going to be multiplatform[1] and getting alot more 

bit afraid D can gain less popularity due to that or even make 
people switch. What are your thoughts on that?


[1]: https://devblogs.microsoft.com/dotnet/announcing-net-5-0/
[2]: https://devblogs.microsoft.com/dotnet/c-9-0-on-the-record/
Nov 12 2020
next sibling parent reply IGotD- <nise nise.com> writes:
On Thursday, 12 November 2020 at 15:57:44 UTC, Jack wrote:

 .NET 5.0 is going to be multiplatform[1] and getting alot more 

 bit afraid D can gain less popularity due to that or even make 
 people switch. What are your thoughts on that?


 [1]: https://devblogs.microsoft.com/dotnet/announcing-net-5-0/
 [2]: https://devblogs.microsoft.com/dotnet/c-9-0-on-the-record/


1. Users themselves target .NET to their own proprietary system?
2. What is the license?
3. When you compile to native code, how much extra do you need to 
add in your distribution and what will the total size be.
4. Can you target bare metal targets?
Nov 12 2020
next sibling parent reply Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Thursday, 12 November 2020 at 16:04:21 UTC, IGotD- wrote:

 1. Users themselves target .NET to their own proprietary system?


I fail to parse that question. I'm afraid. Do you mean to ask 
whether .NET users are porting the runtime to other operating 
systems themselves?


 2. What is the license?


Most of .NET is licensed under MIT. It is my understanding that 
the entirety of the cross-platform code is released under that 
license. I do not know whether the Windows Desktop version of the 
runtime includes extra components that are still proprietary.


 3. When you compile to native code, how much extra do you need 
 to add in your distribution and what will the total size be.
 4. Can you target bare metal targets?


Not yet. There's a toolchain in the making that has been 

executables with size less than 1MB. Going from there to bare 
metal should be quite doable, but footprint would very likely 
still be an issue. Unfortunately, I don't have a link to the 
source anymore.

I think most of that work is supposed to be formally released in 
.NET 6.0.
Nov 12 2020
parent reply IGotD- <nise nise.com> writes:
On Thursday, 12 November 2020 at 17:05:52 UTC, Gregor Mückl wrote:

 I fail to parse that question. I'm afraid. Do you mean to ask 
 whether .NET users are porting the runtime to other operating 
 systems themselves?


Yes that is what I meant and if .NET has a MIT license that helps.


 Most of .NET is licensed under MIT. It is my understanding that 
 the entirety of the cross-platform code is released under that 
 license. I do not know whether the Windows Desktop version of 
 the runtime includes extra components that are still 
 proprietary.


You have to be careful with this one. Let's say you some 
proprietary system which which is using .NET and is MIT. Then you 
have unittests that can run on your x86 Windows PC target and 
those link in proprietary MS components, then you must buy a 
license.
Nov 12 2020
parent reply Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Thursday, 12 November 2020 at 18:08:48 UTC, IGotD- wrote:

 On Thursday, 12 November 2020 at 17:05:52 UTC, Gregor Mückl 
 wrote:

 I fail to parse that question. I'm afraid. Do you mean to ask 
 whether .NET users are porting the runtime to other operating 
 systems themselves?


 Yes that is what I meant and if .NET has a MIT license that 
 helps.


Then again, the .NET CLR implementations that I know of are 
massive beasts. Porting them is no easy tasks and I am not aware 
of anyone who is doing that.

This is (part of?) the single static binary compilation project I 
was referring to earlier: https://github.com/dotnet/corert

I believe that an approach like that can be retargeted to 
different operating systems more easily.


 Most of .NET is licensed under MIT. It is my understanding 
 that the entirety of the cross-platform code is released under 
 that license. I do not know whether the Windows Desktop 
 version of the runtime includes extra components that are 
 still proprietary.


 You have to be careful with this one. Let's say you some 
 proprietary system which which is using .NET and is MIT. Then 
 you have unittests that can run on your x86 Windows PC target 
 and those link in proprietary MS components, then you must buy 
 a license.


This is an overview over the licenses for the .NET 5.0 Windows 
Desktop Runtime:

https://github.com/dotnet/core/blob/master/license-information-windows.md

So this is quite a mix and the most worrying part are the two 
libraries under the Visual Studio License. My understanding is 
that these are not free (as in beer) unless you qualify for a 
Visual Studio Community license.

My understanding is that the Linux version is free of these 
constraints.
Nov 12 2020
parent reply IGotD- <nise nise.com> writes:
On Thursday, 12 November 2020 at 19:08:37 UTC, Gregor Mückl wrote:

 This is an overview over the licenses for the .NET 5.0 Windows 
 Desktop Runtime:

 https://github.com/dotnet/core/blob/master/license-information-windows.md

 So this is quite a mix and the most worrying part are the two 
 libraries under the Visual Studio License. My understanding is 
 that these are not free (as in beer) unless you qualify for a 
 Visual Studio Community license.

 My understanding is that the Linux version is free of these 
 constraints.


The question is what "free" means here. If that part contains GPL 
or LGPL parts then it might be even more useless than a 
commercial license. You can always buy a commercial license if 
you want to and if you think the price is fair and then you can 
do what you want. GPL and LGPL puts restrictions on the 
distribution including your product. What is usually the most 
deterring is that you must open up your system for tampering 
which is a no no for many products.

D wins here as it is using the Boost license which is a huge 
benefit.
Nov 12 2020
parent Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Thursday, 12 November 2020 at 19:24:17 UTC, IGotD- wrote:

 On Thursday, 12 November 2020 at 19:08:37 UTC, Gregor Mückl 
 wrote:

 [...]


 The question is what "free" means here. If that part contains 
 GPL or LGPL parts then it might be even more useless than a 
 commercial license. You can always buy a commercial license if 
 you want to and if you think the price is fair and then you can 
 do what you want. GPL and LGPL puts restrictions on the 
 distribution including your product. What is usually the most 
 deterring is that you must open up your system for tampering 
 which is a no no for many products.

 D wins here as it is using the Boost license which is a huge 
 benefit.


I wrote "free (as in beer)" for a reason above. The basic .NET 
framework components don't contain anything that is licensed 
under the GPL/LGPL. It's all open source, but not copyleft. The 
MIT license is very liberal. You only need to reproduce the 
license text somewhere in your documentation and you're good.
Nov 12 2020
prev sibling parent IGotD- <nise nise.com> writes:
On Thursday, 12 November 2020 at 16:04:21 UTC, IGotD- wrote:

 1. Users themselves target .NET to their own proprietary system?
 2. What is the license?
 3. When you compile to native code, how much extra do you need 
 to add in your distribution and what will the total size be.
 4. Can you target bare metal targets?


5. Support for public code generators.


it must support either LLVM or GCC code generators. If not you 
are pretty much in the hands of Microsoft and what they want to 
support. In the future we will see new CPU architecture become 
more popular like RISC V. If MS doesn't want to support that then 

support all the targets LLVM and GCC can.
Nov 17 2020
prev sibling next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Thursday, 12 November 2020 at 15:57:44 UTC, Jack wrote:

 .NET 5.0 is going to be multiplatform[1] and getting alot more 

 bit afraid D can gain less popularity due to that or even make 
 people switch. What are your thoughts on that?


 [1]: https://devblogs.microsoft.com/dotnet/announcing-net-5-0/
 [2]: https://devblogs.microsoft.com/dotnet/c-9-0-on-the-record/


That only threat to D is itself.
There are features that need to finished and implemented.
There are language design issues that needs to be address.
The standard library needs a reviewer to prevent Pull requested 
from getting stale.
D needs to focus on its consumers instead of worrying other 
language development.

- Alex
Nov 12 2020
parent reply rinfz <cherez mailbox.org> writes:
On Thursday, 12 November 2020 at 18:32:59 UTC, 12345swordy wrote:

 D needs to focus on its consumers instead of worrying other 
 language development.


It's been said before and it'll be said again but it'd be nice to 
have more visible and more frequent (i.e. regular) communication 
about language direction and developments from the core 
maintainers. I feel like Atila is even less visible than Andrei 
was when everyone was complaining about this before.
Nov 12 2020
parent reply Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Thursday, 12 November 2020 at 21:45:16 UTC, rinfz wrote:

 On Thursday, 12 November 2020 at 18:32:59 UTC, 12345swordy 
 wrote:

 D needs to focus on its consumers instead of worrying other 
 language development.


 It's been said before and it'll be said again but it'd be nice 
 to have more visible and more frequent (i.e. regular) 
 communication about language direction and developments from 
 the core maintainers. I feel like Atila is even less visible 
 than Andrei was when everyone was complaining about this before.


A heads down working attitude is very commendable, but - watching 
from the sidelines, mind you - I get the impression that D could 
profit from some more aggressive outreach. That means not just 
talking to the existing community, but also more active advocacy. 
Reaching out to other communities and organizations, pointing out 
that D exists, listening to them to figure out their needs, 
pointing out what it is capable of doing for them etc... To be 
blunt: this part is sales, but different.

It takes a certain kind of character to do this. Technically 
minded people often tend to dislike doing that, in my 
experience*. But let's be honest, we all like to listen once 
someone has started a pitch in a way that made us genuinely 
curious about some aspect of the product.

I wonder now what would happen if the D Foundation could actually 
hire a person who can present such a pitch convincingly, 
especially to the corporate world.
Nov 12 2020
parent reply IGotD- <nise nise.com> writes:
On Thursday, 12 November 2020 at 22:11:33 UTC, Gregor Mückl wrote:

 A heads down working attitude is very commendable, but - 
 watching from the sidelines, mind you - I get the impression 
 that D could profit from some more aggressive outreach. That 
 means not just talking to the existing community, but also more 
 active advocacy. Reaching out to other communities and 
 organizations, pointing out that D exists, listening to them to 
 figure out their needs, pointing out what it is capable of 
 doing for them etc... To be blunt: this part is sales, but 
 different.

 It takes a certain kind of character to do this. Technically 
 minded people often tend to dislike doing that, in my 
 experience*. But let's be honest, we all like to listen once 
 someone has started a pitch in a way that made us genuinely 
 curious about some aspect of the product.

 I wonder now what would happen if the D Foundation could 
 actually hire a person who can present such a pitch 
 convincingly, especially to the corporate world.


Absolutely, D is like a garage project but garage projects don't 
really scale. The biggest Achilles heel of the D project is its 
management or lack of it. The maintainers are technically very 
skilled but they aren't really of the pure manager material. 
Small tech startups when they grow, the smart ones get a CEO when 
they reach certain point. Not only to relieve themselves from 
some work but also the friends that started the company might 
disagree and that's when the CEO steps in order to represent the 
interest of the company. I've seen companies that don't do that 
and they usually just dissolve because of some disagreements.

The D project could need a person like that, a person that work 
for the interest of the D language. Also mitigate what needs to 
be done and what is supposed to be the direction of the project.
Nov 12 2020
parent reply aberba <karabutaworld gmail.com> writes:
On Thursday, 12 November 2020 at 22:31:37 UTC, IGotD- wrote:

 On Thursday, 12 November 2020 at 22:11:33 UTC, Gregor Mückl 
 wrote:

 [...]





 The D project could need a person like that, a person that work 
 for the interest of the D language. Also mitigate what needs to 
 be done and what is supposed to be the direction of the project.


I've said this multiple times this year. I'm not sure if it's 
ever going to happen. Maybe a  question for the Dconf online Q&A.
Nov 13 2020
parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 13 November 2020 at 11:44:54 UTC, aberba wrote:

 [snip]

 I've said this multiple times this year. I'm not sure if it's 
 ever going to happen. Maybe a  question for the Dconf online 
 Q&A.


Easier said than done...
Nov 13 2020
prev sibling next sibling parent reply Siemargl <inqnone gmail.com> writes:
On Thursday, 12 November 2020 at 15:57:44 UTC, Jack wrote:

 .NET 5.0 is going to be multiplatform[1] and getting alot more 

 bit afraid D can gain less popularity due to that or even make 
 people switch. What are your thoughts on that?


 [1]: https://devblogs.microsoft.com/dotnet/announcing-net-5-0/
 [2]: https://devblogs.microsoft.com/dotnet/c-9-0-on-the-record/


Not a "threat", but rather another one "nail in the lid of the 
coffin".

NET5 eliminates several important advantages of D - native 
compilation, fast start, inability to decompile, multiplatformy.

And NET5 is much more stable for the user. I have experience of 
simply recompiling a 14 year old application from NET2.0->NET4.5
Nov 13 2020
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 13 November 2020 at 08:11:17 UTC, Siemargl wrote:

 And NET5 is much more stable for the user. I have experience of 
 simply recompiling a 14 year old application from NET2.0->NET4.5


I would not trust Microsoft to support other platforms than the 
ones they make money of... All it takes is a new CEO...
Nov 13 2020
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 13 November 2020 at 08:11:17 UTC, Siemargl wrote:

 On Thursday, 12 November 2020 at 15:57:44 UTC, Jack wrote:

 .NET 5.0 is going to be multiplatform[1] and getting alot more 

 a bit afraid D can gain less popularity due to that or even 
 make people switch. What are your thoughts on that?


 [1]: https://devblogs.microsoft.com/dotnet/announcing-net-5-0/
 [2]: https://devblogs.microsoft.com/dotnet/c-9-0-on-the-record/


 Not a "threat", but rather another one "nail in the lid of the 
 coffin".

 NET5 eliminates several important advantages of D - native 
 compilation, fast start, inability to decompile, multiplatformy.

 And NET5 is much more stable for the user. I have experience of 
 simply recompiling a 14 year old application from NET2.0->NET4.5


Many developers are sceptical of MS willingness to support other 
platforms long term. All it takes to wipe it out is a new CEO. 
Same with Swift.

The nail in the coffin would be to not fix those issues in D that 
require breaking changes (it isn't possible to satisfy everyone, 
so D has to select which application area to focus on).
Nov 13 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 13 November 2020 at 09:08:27 UTC, Ola Fosheim Grøstad 
wrote:

 The nail in the coffin would be to not fix those issues in D 
 that require breaking changes (it isn't possible to satisfy 
 everyone, so D has to select which application area to focus 
 on).


And just as an example, one "winning" strategy would be to try to 
become the dominating language for gui applications on Linux and 
go 100% with it at the expense of all other "niches". The current 
alternatives are not attractive because they either are corporate 
or lacking (Linux users are more likely to be favourable towards 
a non-corporate entity).

In my view that is not a difficult choice to make given the stiff 
competition for "generic languages". (And I don't even have a 
running Linux box at the moment, so I am not advocating.)

So it is essentially a management issue. Sometimes you just have 
to pick your poison and make some strategic moves, because 
stagnation is the only thing you'll get if you don't make waves 
yourself...
Nov 13 2020
parent Siemargl <inqnone gmail.com> writes:
On Friday, 13 November 2020 at 09:34:08 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 13 November 2020 at 09:08:27 UTC, Ola Fosheim 
 Grøstad wrote:

 The nail in the coffin would be to not fix those issues in D 
 that require breaking changes (it isn't possible to satisfy 
 everyone, so D has to select which application area to focus 
 on).


 And just as an example, one "winning" strategy would be to try 
 to become the dominating language for gui applications on Linux 
 and go 100% with it at the expense of all other "niches". The 
 current alternatives are not attractive because they either are 
 corporate or lacking (Linux users are more likely to be 
 favourable towards a non-corporate entity).


...

In the GUI area, Web interfaces seem to have won. So NET is also 
ahead. But ASP.core is not so convenient, so not everything is 
lost.
Nov 13 2020
prev sibling parent reply Kagamin <spam here.lot> writes:
Here's a list of libraries used by a tiny aspnet core application:
Microsoft.AspNetCore.Antiforgery.dll
Microsoft.AspNetCore.Authentication.Abstractions.dll
Microsoft.AspNetCore.Authentication.Core.dll
Microsoft.AspNetCore.Authorization.dll
Microsoft.AspNetCore.Authorization.Policy.dll
Microsoft.AspNetCore.Connections.Abstractions.dll
Microsoft.AspNetCore.Cors.dll
Microsoft.AspNetCore.Cryptography.Internal.dll
Microsoft.AspNetCore.DataProtection.dll
Microsoft.AspNetCore.DataProtection.Abstractions.dll
Microsoft.AspNetCore.Diagnostics.Abstractions.dll
Microsoft.AspNetCore.Hosting.dll
Microsoft.AspNetCore.Hosting.Abstractions.dll
Microsoft.AspNetCore.Hosting.Server.Abstractions.dll
Microsoft.AspNetCore.Html.Abstractions.dll
Microsoft.AspNetCore.Http.dll
Microsoft.AspNetCore.Http.Abstractions.dll
Microsoft.AspNetCore.Http.Extensions.dll
Microsoft.AspNetCore.Http.Features.dll
Microsoft.AspNetCore.JsonPatch.dll
Microsoft.AspNetCore.Localization.dll
Microsoft.AspNetCore.Mvc.dll
Microsoft.AspNetCore.Mvc.Abstractions.dll
Microsoft.AspNetCore.Mvc.ApiExplorer.dll
Microsoft.AspNetCore.Mvc.Core.dll
Microsoft.AspNetCore.Mvc.Cors.dll
Microsoft.AspNetCore.Mvc.DataAnnotations.dll
Microsoft.AspNetCore.Mvc.Formatters.Json.dll
Microsoft.AspNetCore.Mvc.Localization.dll
Microsoft.AspNetCore.Mvc.Razor.dll
Microsoft.AspNetCore.Mvc.Razor.Extensions.dll
Microsoft.AspNetCore.Mvc.RazorPages.dll
Microsoft.AspNetCore.Mvc.TagHelpers.dll
Microsoft.AspNetCore.Mvc.ViewFeatures.dll
Microsoft.AspNetCore.Razor.dll
Microsoft.AspNetCore.Razor.Language.dll
Microsoft.AspNetCore.Razor.Runtime.dll
Microsoft.AspNetCore.ResponseCaching.Abstractions.dll
Microsoft.AspNetCore.Routing.dll
Microsoft.AspNetCore.Routing.Abstractions.dll
Microsoft.AspNetCore.Server.Kestrel.dll
Microsoft.AspNetCore.Server.Kestrel.Core.dll
Microsoft.AspNetCore.Server.Kestrel.Https.dll
Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions.dll
Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.dll
Microsoft.AspNetCore.StaticFiles.dll
Microsoft.AspNetCore.WebUtilities.dll
Microsoft.CodeAnalysis.dll
Microsoft.CodeAnalysis.CSharp.dll
Microsoft.CodeAnalysis.Razor.dll
Microsoft.DotNet.PlatformAbstractions.dll
Microsoft.EntityFrameworkCore.dll
Microsoft.EntityFrameworkCore.Abstractions.dll
Microsoft.EntityFrameworkCore.Relational.dll
Microsoft.EntityFrameworkCore.SqlServer.dll
Microsoft.Extensions.Caching.Abstractions.dll
Microsoft.Extensions.Caching.Memory.dll
Microsoft.Extensions.Configuration.dll
Microsoft.Extensions.Configuration.Abstractions.dll
Microsoft.Extensions.Configuration.Binder.dll
Microsoft.Extensions.Configuration.EnvironmentVariables.dll
Microsoft.Extensions.Configuration.FileExtensions.dll
Microsoft.Extensions.DependencyInjection.dll
Microsoft.Extensions.DependencyInjection.Abstractions.dll
Microsoft.Extensions.DependencyModel.dll
Microsoft.Extensions.FileProviders.Abstractions.dll
Microsoft.Extensions.FileProviders.Composite.dll
Microsoft.Extensions.FileProviders.Embedded.dll
Microsoft.Extensions.FileProviders.Physical.dll
Microsoft.Extensions.FileSystemGlobbing.dll
Microsoft.Extensions.Hosting.Abstractions.dll
Microsoft.Extensions.Localization.dll
Microsoft.Extensions.Localization.Abstractions.dll
Microsoft.Extensions.Logging.dll
Microsoft.Extensions.Logging.Abstractions.dll
Microsoft.Extensions.ObjectPool.dll
Microsoft.Extensions.Options.dll
Microsoft.Extensions.Primitives.dll
Microsoft.Extensions.WebEncoders.dll
Microsoft.Net.Http.Headers.dll
Microsoft.Win32.Primitives.dll
Microsoft.Win32.Registry.dll
Newtonsoft.Json.dll
Newtonsoft.Json.Bson.dll
Remotion.Linq.dll
Swashbuckle.AspNetCore.dll
Swashbuckle.AspNetCore.Swagger.dll
Swashbuckle.AspNetCore.SwaggerGen.dll
Swashbuckle.AspNetCore.SwaggerUI.dll
System.AppContext.dll
System.Buffers.dll
System.Collections.dll
System.Collections.Concurrent.dll
System.Collections.Immutable.dll
System.Collections.NonGeneric.dll
System.Collections.Specialized.dll
System.ComponentModel.dll
System.ComponentModel.Annotations.dll
System.ComponentModel.EventBasedAsync.dll
System.ComponentModel.Primitives.dll
System.ComponentModel.TypeConverter.dll
System.Composition.AttributedModel.dll
System.Composition.Convention.dll
System.Composition.Hosting.dll
System.Composition.Runtime.dll
System.Composition.TypedParts.dll
System.Configuration.ConfigurationManager.dll
System.Console.dll
System.Data.Common.dll
System.Data.SqlClient.dll
System.Diagnostics.Contracts.dll
System.Diagnostics.Debug.dll
System.Diagnostics.DiagnosticSource.dll
System.Diagnostics.FileVersionInfo.dll
System.Diagnostics.PerformanceCounter.dll
System.Diagnostics.Process.dll
System.Diagnostics.StackTrace.dll
System.Diagnostics.TextWriterTraceListener.dll
System.Diagnostics.Tools.dll
System.Diagnostics.TraceSource.dll
System.Diagnostics.Tracing.dll
System.Drawing.Primitives.dll
System.Dynamic.Runtime.dll
System.Globalization.dll
System.Globalization.Calendars.dll
System.Globalization.Extensions.dll
System.Interactive.Async.dll
System.IO.dll
System.IO.Abstractions.dll
System.IO.Compression.dll
System.IO.Compression.ZipFile.dll
System.IO.FileSystem.dll
System.IO.FileSystem.DriveInfo.dll
System.IO.FileSystem.Primitives.dll
System.IO.FileSystem.Watcher.dll
System.IO.IsolatedStorage.dll
System.IO.MemoryMappedFiles.dll
System.IO.Pipelines.dll
System.IO.Pipes.dll
System.IO.UnmanagedMemoryStream.dll
System.Linq.dll
System.Linq.Expressions.dll
System.Linq.Parallel.dll
System.Linq.Queryable.dll
System.Memory.dll
System.Net.Http.dll
System.Net.NameResolution.dll
System.Net.NetworkInformation.dll
System.Net.Ping.dll
System.Net.Primitives.dll
System.Net.Requests.dll
System.Net.Security.dll
System.Net.Sockets.dll
System.Net.WebHeaderCollection.dll
System.Net.WebSockets.dll
System.Net.WebSockets.Client.dll
System.Numerics.Vectors.dll
System.ObjectModel.dll
System.Private.ServiceModel.dll
System.Reflection.dll
System.Reflection.DispatchProxy.dll
System.Reflection.Extensions.dll
System.Reflection.Metadata.dll
System.Reflection.Primitives.dll
System.Resources.Reader.dll
System.Resources.ResourceManager.dll
System.Resources.Writer.dll
System.Runtime.dll
System.Runtime.CompilerServices.Unsafe.dll
System.Runtime.CompilerServices.VisualC.dll
System.Runtime.Extensions.dll
System.Runtime.Handles.dll
System.Runtime.InteropServices.dll
System.Runtime.InteropServices.RuntimeInformation.dll
System.Runtime.Numerics.dll
System.Runtime.Serialization.Formatters.dll
System.Runtime.Serialization.Json.dll
System.Runtime.Serialization.Primitives.dll
System.Runtime.Serialization.Xml.dll
System.Security.AccessControl.dll
System.Security.Claims.dll
System.Security.Cryptography.Algorithms.dll
System.Security.Cryptography.Cng.dll
System.Security.Cryptography.Csp.dll
System.Security.Cryptography.Encoding.dll
System.Security.Cryptography.Primitives.dll
System.Security.Cryptography.X509Certificates.dll
System.Security.Cryptography.Xml.dll
System.Security.Permissions.dll
System.Security.Principal.dll
System.Security.Principal.Windows.dll
System.Security.SecureString.dll
System.ServiceModel.NetTcp.dll
System.ServiceModel.Primitives.dll
System.Text.Encoding.dll
System.Text.Encoding.CodePages.dll
System.Text.Encoding.Extensions.dll
System.Text.Encodings.Web.dll
System.Text.RegularExpressions.dll
System.Threading.dll
System.Threading.Overlapped.dll
System.Threading.Tasks.dll
System.Threading.Tasks.Extensions.dll
System.Threading.Tasks.Parallel.dll
System.Threading.Thread.dll
System.Threading.ThreadPool.dll
System.Threading.Timer.dll
System.ValueTuple.dll
System.Xml.ReaderWriter.dll
System.Xml.XDocument.dll
System.Xml.XmlDocument.dll
System.Xml.XmlSerializer.dll
System.Xml.XPath.dll
System.Xml.XPath.XDocument.dll
214 files, 32mb.
Nov 13 2020
parent Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 13 November 2020 at 14:14:33 UTC, Kagamin wrote:

 [...]


Meaning? .NET now has a linker and AOT compilation, so those 32 
mb are just if one doesn't bother to optimize it further.

Plus it shows one of the current weakness of D, the amount of 
available libraries with similar maturity level.
Nov 13 2020