Unity API vs .NET API and future

When we finally get .NET 4.6 / .NET Core 2.0 / .NET Standard 2.0 (with a preview of .NET 4.6 API in the next release 2017.1):

https://github.com/dotnet/core/blob/master/roadmap.md

There is going to be some really important matters to solve:

1. Do Coroutines still make sense to exist? We will have "async" and "Task" though tasks create threads and cannot access Unity API that it's not thread safe. Are we getting at some point more Unity API thread safe? We still can't make things like create textures, readpixels and so on from another thread.

2. Yield instructions needs to be awaitable and be used like: await WaitForFixedUpdate();

3. As I wrote some months ago about System.Numerics: https://forum.unity3d.com/threads/system-numerics.451073/ Are you going to adopt this API? It makes sense to use it and avoid having a Unity specific API for this that it's already available on Mono / .NET.

4. Serialization. We will have DataContract API available to use. Can Unity get advantage using this in some way?

I don't remember more cases because as I'm so used to use .NET 2.0/3.5 API that Unity uses I don't really know much changes from 2.0/3.5 > 4.6 API that could benefit Unity.

I mean, I think that Unity should adopt more and more API from .NET platform and mark as deprecated o change it's own API in places that makes sense so it can put it's resources in other tasks that are Unity specific.

 

That's not true at all.
You can create your scheduler in any way you like, making it not spawn any threads if you want and always route all execution into the main thread...

Also all this new Task stuff is incredibly allocation heavy.

You want await WaitForFixedUpdate(); as a task? No way, people are getting all worked up about coroutines allocating a few bytes every iteration, and now you want to bomb us with 10x or 100x that much GC pressure per frame? whew...

There's no way that stuff will make it into Unity in its current form.
Maybe people will come up with some new tricks to make more things into structs or maybe even somehow recycle Tasks...


edit:
It may not be clear from the way I worded things, but I'd very much like to be able to await stuff everywhere if it were somehow possible!

It's just that video games need extreme performance.
You know how it is, a "short" 50ms pause to do some garbage collection is just completely unacceptable most of the time.
And as you know we developers have to constantly optimize against allocations just to make sure that doesn't happen too often.

Also tasks have a a lot of overhead, there's tons of code that's getting executed behind the scenes to make it all work. So even if everything was allocation free, you'd definitely pay a few FPS to really make use of Tasks and await

 

You can await anything that is awaitable, not just Tasks. There's no reason await WaitForFixedUpdate would need to allocate anything. In addition, there is ValueTask which does no heap allocation. GC and performance is not a good reason to use IEnumerator-based coroutines over awaitables/Tasks.

 

Don't think of `Task<T>` as something necessarily thread-related. It's rather readonly view for `TaskCompletionSource<T>`, making future/promise pair correspondence. You can combine them with current coroutine approach without creating new threads.

 

I am very impressed on the port work. Async / await works like a charm, especially with existing .net libraries.It will be great to see the UnityWebRequest behave the same and / or having the capability to use HttpRequest with WebGL and other platforms.

 

Note: Async / Await works perfectly on Desktop / Editor including System.Net.HttpClient. I like the fact that it can be used in the same way as WPF, Forms by decorating a method async.

Is it in the roadmap to provide that same level of support on Android, iOS and consoles? Will libraries System.Net.HttpClient become a first class citizen in Unity, and be able to be used across all platforms without changing your code base?

Will WebGl support async? and from my previous question if System.Net.HttpClient is not a first class citizen will Unity classes have async capability as welll as Iterators, so the can be used in conjunction with other .Net libraries?

 

A question from another performance paranoid developer who's striping things out to try to prevent GC pauses...

What will the non-poolable memory implications of all of this? I'm aware there's a non-allocating LINQ implementation. How close to a zero allocation implementation will likely be managed?

Thx

 

Were you able to get System.Net.HttpClient to work? I cannot get the task HttpClient.GetAsync to complete as it would in other .net projects.

 

I'm trying to write UWP code in Unity3D by adding the Nuget Microsoft.NETCore.UniversalWindowsPlatform to my Unity3D Visual Studio project but it won't let me. It keeps complaining that I cannot install Microsoft.NETCore.Jit 1.0.3 as my project targets .NET 4.6. How can I set Unity3D to target .NET Core 2.0?

 

I'm sorry for necroing, but cannot find some Unity official response to the questions in this thread: with the .NET 4.6 support, will the .NET stuff like async/await, Tasks, System.Net.HttpClient, etc. treated as first class citizens in Unity (maybe with some limitation on some platforms, like WebGL), or should we keep using the Unity stuff?

I am a newbie Unity developer coming from .NET world. I would like to use the .NET stuff because we have some code with that already. But I am not sure about some possible negative consequences.

 

Thanks for the answer, Josh. So async/await is ok for such tasks like HTTP communication but should be cautions when doing some frequent small tasks.
AFAIK System.Net is not working in WebGL, at least. That's what I miss in doc - some list platforms where some particular .NET API is supported (or maybe a list of excluded platforms, if it's shorter.) Microsoft does it already in their doc.

 

Josh,

async/await

is not working in Unity test runner! See https://forum.unity.com/threads/async-await-in-unittests.513857/

 

Here's the bug [TestRunner] cannot runs async/await tests: https://fogbugz.unity3d.com/default.asp?1129455_2qh1olgn71f7hr6l

 

One more problematic thing is

System.Globalization.CultureInfo.CurrentCulture (CurrentUICulture, InstalledUICulture)

. Many folks report id does not work on iOS, Android, even Windows 7. E.g. see here, or here. Please, document if it's supported, on which platforms it does work and the relation to Application.systemLanguage.

 

But that's exactly, what I expect in doc:
version 2018.3. supported on platforms ....
version 2019.1. supported on platforms ....
etc.
And not to check every platform (we plan to release on 5 platforms) by myself. That's very time consuming.

 

It was not clear from your sentence "was recently corrected for some platforms" that it works on all platforms.

 

It's not fixed for Android :-(

 

Done. #1158381

 

TwoLetterLanguageCode from System.Globalization.CultureInfo.CurrentCulture doesn't work for me too.
Returns VI while language is English.
Huawei P10 Lite (Android), Unity version 2019.2.3

 

This is still a good question today. What is the state of API updates. Since th creation of this thread not a lot has changed. Is Unity working on updating their API to a more .NET standard way?
This doesn't just include async await, but also naming guidelines and general support nullability. With nullable reference types being a things soon, as Unity thought about how to handle that with UnityEngine.Object types?
If I declare a MonoBehavior to be NOT nullable, what will you do then with your custom == implementation?
This needs adressing at some point and the non-standard API has been an issue for over a decade now.
Now that we have the .NET foundation, .NET is moving towards a complete unification with .NET 5 and .NET having moved to Standard 2.1 already I feel this is the time to bring Unity into the .NET economy completely and finally fix some API to make it properly standardized.

Unity has always been about the democratization of development. There has never been a larger .NET developer community out there. Now with .NET core, blazor coming and other developments there's almost no place you cannot go with .NET and C# and Unity is a vital part of that vibrant community. But unforuntately in terms of its API it remains a decade behind and still is somewhat the 'ugly child', which should not be the case.

C# and .NET are moving forward but somehow Unity keeps its eyes on flashy features and performance upgrades and nice render pipelines and such things that go well on conferences. But I have the feeling the actual scripting has always been an afterthought. Sure DOTS and Burst and such have been on the forefront, but the API involved in new things on the scripting side has not exactly been improving.
With so many new exciting development and experts working at Unity on all kinds of features, I think it's time to hire a few people that work on standardizing the C# API and bringing it into 2020 where the rest of .NET lives.

Is that in any way on the agenda at Unity?

 

At this point it is already a lost cause for me that Unity follows the conventions and standards of .NET.

It is supposed that with the packages they had a good opportunity to start following them since they are code made from scratch but you can see how in InputSystem and I imagine that many others that not even in properties follow Microsoft's conventions.

https://github.com/Unity-Technologi...ty.inputsystem/InputSystem/Devices/Gamepad.cs