Unity Future .NET Development Status

There's no such thing with standard .net tasks. Wouldn't make sense to add that. Implementations of that could take loads of different shapes. If you need it, better to write your three extra lines of code for your specific circumstance.

 

I just explain "What would it even do?", assume that you don't know.

 

WaitForEndOfFrame

is also not standard dotnet task.

Awaitable

is unity's framework library and it more of reflecting Coroutine than dotnet Task

 

here you go

Code (CSharp):

1. public static class AwaitableUtil
2. {
3.   public static async Awaitable WaitUntil(Func<bool> predicate)
4.   {
5.     while (!predicate.Invoke()):
6.     {
7.         await Awaitable.NextFrameAsync();
8.     }
9.   }
10. }

I don't think this should be part of the

Awaitable

API that Unity ships. The functions in the existing API are just at the level to abstract timing. For example, next frame, end of frame, fixed update, etc.. This is at one level higher because it must necessarily use one of those other APIs to poll for.

Personally, I prefer using an inline

while

loop because it's clearer what timing is being used without requiring some type that specifies the timing.

 

When working with async code in Unity I highly recommend having a look at UniTask https://github.com/Cysharp/UniTask. I also implements a
WaitUntil.

 

nah. Just use Awaitable

 

Am I correct in my understanding that canceling an Awaitable has a non-negligible cost?

From what I can tell, it will cause allocations by creating an Exception and an ExceptionDispatchInfo. And then throw the exception, which will be caught by the "catch" block in the generated state machine (catching an exception is pretty slow in dotnet AFAIK).

Then it will repeat the whole process for each parent/calling async Awaitable method.

Wouldn't it be possible for the cancellation to not throw an exception, and instead just reset and release the Awaitable object and its resources (and all its Awaitable parents)?

I'm asking this because, I think that canceling an Awaitable could be a common usecase (at least for me).

For example, It would be great to be able to use it in a state machine, where each state is an async Awaitable method, that would be canceled on exit.

 

Raising a TaskCanceledException is an established behaviour of pure .net. I do not believe that further deviation would be good. Also in conjunction with awaiting multiple and aggregating their possibly custom exceptions.

 

If the async task starting to become complicate and require more chance to be cancelled, I would like to recommend you to start looking at ReactiveX paradigm

 

Exceptions aren't meant for optimization or memory management: they are meant to throw your program and let you as a developer now the kinks to work out. I would urge you to look into avoiding exceptions altogether instead of trying to find ways to optimize them, any systems developer will give you a solid pass on that and I don't see Unity deciding anything different.

 

I had a look and Awaitable is only available in Unity 2023 correct?

 

To everyone cheering about the source generators support, remember that up until a few years ago, Unity had official support for the Boo language. Boo's metaprogramming is an order of magnitude more powerful than the ugly and extremely limited source generator system the Roslyn team bolted onto the C# language.

Unity team: we'd really love to get Boo support back!

 

I've not found source generators, especially incremental ones, ugly nor limited in any way. You sure you know the ins and outs of them 100% yet?

 

@JoshPeterson with the migration to csproj style, will we be able to natively add in other .net languages like F# or Q# as well, or will that still only be possible by precompiling a dll?

 

Oh, leave it. We made Teslagrad 1 with Boo. It took a full minute to compile the game. Not reload assemblies. Not enter play mode. Compilation alone. One of our programmers made a little script that made the editor play a microwave "ding" sound when it was done compiling, so he knew that his minute of Twitter was over.

So yeah nobody that's actually tried making a real game with Boo wants Boo support back. We want it taken behind the barn and shot.


In more seriousness, the language had cool ideas but required a monumental rework of the entire compiler in order to be useable. Last time I checked, the creator stopped working on it and whoever took over don't care about video games or Unity.

 

Hi, @JoshPeterson are there any plans to support file paths longer than 260 on windows? The bug tracker https://issuetracker.unity3d.com/is...-to-build-in-a-folder-with-too-long-of-a-name is closed as won't fix because of OS limitations, but as pointed out in the comments it is not the case anymore
https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry
Right now, we hit this issue when using submodules with internal packages, but we have also seen people hit this issue with CI/CD setups on build servers. Is there any plan to fix this in the near to mid future?

 

I know exactly what you mean. Here's where I fixed the abysmal compiler performance 6 years ago. It wasn't a monumental overhaul of the entire compiler; it just needed a good profiler run and some highly-targeted TLC, mostly in macro expansion and external name resolution. Compile times are almost 2 orders of magnitude faster now on large builds.

Mainly because he was being paid to work on it by Unity, and they threw him out.

That would be me, and I most certainly do. That's why I'm trying to get it brought back!

 

no thanks. not to disregard your work, but .net is definitely the right choice now and going forward.

 

If I had to guess, you've never worked in a language with actual metaprogramming? If you have, the limitations are very obvious very quickly.

Source Generators are extremely limited because they're source generators. Anyone who's worked with classical metaprogramming takes one look at this system that operates by creating textual source code and responds with revulsion. Here are some really fundamental metaprogramming tasks you simply can't do with C#'s source generators:

• Define a metaprogramming task in the same project you use it in
• Define, scan for, and raise errors on, a custom condition
  • C# (almost) has this as a different thing called "analyzers," but with metaprogramming 1) there's no need to make it its own entirely separate concept and 2) you have the option to selectively apply it to specific sections rather than the entire project.
• Add new keywords. In Boo, things like

  var

  ,

  using

  , and

  nameof

  are defined in metaprogramming rather than being hard-coded into the compiler, and you can easily add more of your own if you want.
• Replace one piece of code with another. (For example, I once wrote a fairly simple Boo macro that was essentially a parser generator for a very specialized binary file format. I was then able to replace several thousand lines of overly-complicated, repetitive, error-prone manual parsing code with about 100 lines of code describing the data to be parsed, without needing to involve an external tool like ANTLR.)
• Create DSLs. (This is largely based on the last two points.)

Once you've actually worked with metaprogramming and understand what it's capable of, source generators look as silly as a grade-school child wearing their parent's clothing.

 

Boo is .NET. There's so much more to .NET than just C#. That's always been the promise of the CLR: a Common Language Runtime rather than having to invent the entire framework for every new language that came along.

 

I love the power of metaprogramming, but you can kind of shoot yourself in the foot. They're an additional layer you have to learn on top of the language. I'm still a fan of enabling developers to express themselves easier. Haskell has powerful enough abstractions to not need metaprogramming in most cases. F# is not quite to that level, but it's a step closer. Have you tried F#? The .NET upgrade will probably make it much easier to use F# in Unity.

 

Guys can we not discuss this here? As this isn't the appropriate place to do so, and you can easily create a new thread to do so!

 

Speaking of this downgrade in being able to modify TMP C# in the future https://forum.unity.com/threads/future-of-text-at-unity.1356299/#post-8641374

Couldn't Unity ship engine C# as source code instead of dlls? Maybe this problem could be taken into account while working on csprojs integration.

I have custom edits in TMP package meaning I probably won't be able to update my project's Unity version at some point in the future. Same thing happened with UI Toolkit that was a package in the past.

This direction of putting more code in C++ instead of C#, dlls instead of code and thus loss of source access/editability is pretty bad.

 

Welp... you have to consider this...

Sorry for being a prick, but this is the reality of things!
If you want the source code, you WILL have to pay for Pro AND an extra!

They are locking code behind DLLs for this reason probably if I had to guess...

 

Anyone from Unity Technologies who's listening, please keep in mind that Unreal is giving their source code away for free. Meanwhile, you're 1) charging through the nose for it and 2) charging extra for the privilege of being able to contribute fixes back to Unity. This is crowdsourced quality improvements that you could be getting for free, and instead you're putting up massive disincentives to the community participating in it.

Look at the .NET Core project to see just how wildly successful the opposite strategy has been. The .NET runtime and standard library becomes significantly better every year, both in terms of performance and features, by community contributions, by ordinary, individual developers like me who can't afford thousands of dollars in licensing fees, working for free to make the product better. This only happens because they don't have to be able to afford thousands of dollars in licensing fees.

Just some food for thought.

 

Oh I highly disagree on most of your points.
- Any form of good metaprogramming should work on external existing code, rather than the code it is part of itself.
- You absolutely don't need a seperate analyzer to raise errors on custom conditions. Source Generators support the same warning issuing workflow as a standard analyzer, no need to ship a seperate one. That'd be stupid.
- The keyword thing is pretty cool, but this can quickly lead to incompatibility and redundancy.
- Replacing one piece of code with another is bad. The .net team has considered this and have uniformly with the community decided against it. It's a design decision, and a good one at that. Furthermore if that is indeed needed by you, you can easily use the roslyn api's to alter your code in an unsafe way.
- While the inability to easily create DSL's can be a limitation, I don't think you can blame Source Generators nor C# for it, because Roslyn itself is not built to support something like that.

 

Well the thing is in the TMP thread it was stated that the C# code would still be extensible but that *some* C# code would be moved to c++ instead to allow for optimization. It wasn't specified what parts, but any part that will be pretty much loses the ability for custom code changes.

 

While conveniently ignoring the question I posed before stating them. That makes the answer pretty clear.

I didn't say it should work on itself, I said it should work on code within the same csproj.

Again, not what I said. Yes, source generators can throw their own errors, but they can't analyze your code. And analyzers can't be selectively applied to only one part of your code.

Incompatibility with what? Redundancy with what?

So you never use

using

? Or

foreach

? Extension methods? How about

yield return

and

async

? All of these are things that the compiler internally expands into larger, lower-level code, replacing what you wrote with something else. In the case of async/await the rewriting is massive and very in-depth.

The only difference is, metaprogramming makes this power available to you instead of limiting it to what's hard-coded inside the compiler.

Citation needed, and you'll need a pretty strong one because I personally know the people who set this up and that was not the rationale they gave when I asked about it. Not even close, and "uniform" community input had nothing to do with it either. They crippled source generators specifically out of a desire to not place too heavy a burden on the Visual Studio integration parts of Roslyn (intellisense, etc.)

Yeah, that's exactly my point: this is a very useful thing you can't do in C#.

 

I still disagree on all your points.
And btw, lowering is not the same as metaprogramming.

Here's one source btw (there are more if you look for them): https://github.com/dotnet/roslyn/blob/main/docs/features/source-generators.md

 

After making it abundantly clear that you don't understand the subject matter.

The point in question was about code replacement. Which is precisely the same thing as lowering, except that you get to define it yourself instead of it being hard-coded into the compiler. That's literally the only difference: code replacement/rewriting is building your own custom lowering.

In the same spirit, but possibly a bit more useful, here's a source for you: https://en.wikipedia.org/wiki/Dunning–Kruger_effect

There are more if you look for them.

 

now who's a subject of dunning kruger? because that's simply not true.

 

the passive aggressivity here is stunning... XD

Seriously though... Go open a thread about it and stop behaving like children!

 

OK then, what's the difference? If it's so "simply" wrong, you should be capable of explaining it simply, without misrepresenting or distorting what I've said.

 

yes please. if you dislike the current source generators, then either
- don't use them
or
- open an issue on github

 

Not really as some code may be moved to TextCore precompiled dll that TMP uses. TMP in uGUI package will just be uGUI specific implementation.

 

As I already explained, the Roslyn team is unwilling to fix these problems because they value Intellisense more highly than having a metaprogramming system that's actually any good. Opening an issue would not change that.

 

The .net team isn't required to do anything my guy. But it's open source, so if you're dissatisfied and think 'they are unwilling to fix it', fix it yourself and open a pull request.

 

OK, putting this as clearly as I can so you cannot possibly continue to misunderstand this perfectly clear point: it's not about who does the work. They. Will. Not. Allow. It.

I have been told, personally, by Roslyn team members directly involved with the source generator project, that a working metaprogramming system is fundamentally incompatible with their Intellisense integration performance targets, and that having that those goals not be met is a deal-breaker for them.

 

Great, it's resolved then! Let us never speak of it again.

 

So the question is what is the reason and could it be resolved? I'm guessing that it's some kind of mono integrating as I've seen before stuff like

[MethodImpl(MethodImplOptions.InternalCall)]

or

[NativeHeader("Runtime/Mono/MonoBehaviour.h")]

not working in asmdefs and then in packages.

I guess it could be a big workflow improvement for all Unity packages to be able to use internal calls not to mention all dlls that could be published as C# source code and packages.

Not really, it's already possible to modify all Unity's C# dlls using Mono.Cecil without decompiling that would break TOS, that's what https://forum.unity.com/threads/vector3-and-other-structs-optimization-of-operators.477338/ is doing but it's a pain instead of direct C# access.

Even at Unite 2022 there was a whole presentation about how C# source access allowed V Rising to be made in Unity:

https://unity.virtualeventsite.com/...-why-source-access-to-dots-is-a-game-changer/

 

Hey, that sounds good. Would almost make me consider trying out the language again, but with the amount of hostility you've been throwing around in this thread, I don't think I want to deal with anything you're involved in.

 

This doesn't smell like wholesome .NET talk.

 

Thanks, I opened an issue.

 

I don't really know but I think currently now unity might not have much benefit to close the engine source. If unity just opensource the engine and editor, maybe close only source on the crucial thing like C++ engine, but allow people to access source code and extend editor in various ways. Along with check bug and making pull request for new feature. This might profit unity more than closing source code to the pro package

People who buy pro package I have known don't really ever care about unity source code, instead they more likely want unity support to save their time. And main interest of company is just to build without splashscreen