This wasn’t “from the executive’s order” - it was a decision from the engineers. It became clear that under the old strategy we’d never end up shipping something that people could actually adopt.
I get that you are frustrated that it’s taking so long. I don’t think there is anything that anyone at Unity can say to you that is going to change that, the only meaningful thing is to put a build into your hands. That’s OK, we’ll get there as soon as we can.
soon as we can was being used for such times. I need to cope with the fact that soon in unity is not in timescale of mere mortal
Does CoreCLR solve the (artificial) problem that Apple disallows JIT languages on their phones?
There’s something called “Native AOT” but that appears to not even be officialy production ready by microsoft.
Finally significant multithreading is still done better by Burst.
Therefore I’d tend to believe they won’t stop supporting that one either.
I don’t think it will, as Unity stated they will still support it via IL2CPP. But it will still help you on Android - where you can run .Net directly (like you could with Mono) and thus will get perfect stack traces.
Burst has good multithreading if you need short lived threads, but if you want to do a bigger calculation in the background .Net Threads should be better suited
I think apple was relax that requirement a bit in recent years
Still as other said, most likely unity would still use IL2CPP for mobile platform
I don’t know about the MS but I’ve been using the Native AOT apps in production for at least year and half and didn’t have any problems with them.
IIRC they stated that they’ll not move (as for now) to the Native AOT, because 1. They have total control with IL2CPP how the code is generated (with all its quirks and optimization) and 2. Native AOT isn’t supported on every platform Unity runs on
Thank you so much for your reply Richard, I’ve been away for a while (moving, finding a new job, etc.) and was interested in the state of Unity’s .NET Modernisation.
I would like to ask what the best way would be for me to keep up with the modernisation. It’s not mentioned in many blog posts and as far as I know there’s no more official threads about this. I am very interested in this topic and would like to stay up to date and informed!
Is this a reference to the scripting backend player option? Is the plan to have an option for CoreCLR, and existing options (Mono/IL2CPP) are now maintained instead of removed?
We’ve been discussing this a bit internally; whether we make a new thread like the old one, write Technical Article posts, or something else. To be totally honest, I am not convinced that ‘status update’ posts are particularly helpful - I feel like there’s probably quite a lot of people who are sick of hearing “we’re working on it” - and I’d rather we find ways of sharing updates that actually offer a more meaningful way to contribute, like sharing design docs or specs for the community to review and offer feedback on.
When we figure out what we’re doing, I’ll try and make sure you hear about it!
Waste of time. I’m still thinking decision to move away from one big breaking change in unity 7 was a big mistake.
So, kinda.
On the Player side, yes, we expect to leverage the Scripting Backend option in the PlayerSettings, and for CoreCLR becomes a third choice alongside Mono and IL2CPP. They’d coexist for a while, and then at some point later we’d remove Mono as a choice. (As @Trigve noted, we have no plans to remove IL2CPP, as we don’t expect CoreCLR to ever offer the breadth of platform support we need).
The Editor is harder. Multiple scripting backends in the Editor isn’t something we have ever supported before, so it’s not like just adding another option to a dropdown; and we have to do it without breaking Mono behaviour or performance in the process. We do have a strategy for how we can do this, but it’s a tricky needle to thread.
Yeah guys spend you time trying to make useless compatibility mode while you can just rip out Mono and everyone will be happy
There was one suggestion many people have ask is to have multiple track of editor. Difference build altogether. Instead of have to support switching inside editor
You can name it Unity.NET or anything to let we download it in separate version. Unity version just never shared anything even in the same track anyway
Another thing is what we want to hear is not “we’re working on it”. Yes we are so sick and tired of it. What we want to hear is honest situation that what are you doing, what is the roadblock and we could estimate when it should really be released. Not a dreamy hopeful “as soon as we can” or “need some times” that we so sick and tired to hear about and misguided us to believe it will be last year. Or this year. Or next year. And we felt betrayed by it
This is what we always say and you people dodge with the same repeated phrase “we can’t have ETA” and blahblahblah. No we don’t ask for ETA we ask for what is the current state of the dotnet modernization
That’s actually the plan.
It’s clear that the depth of this problem goes a lot deeper than we get told, even from an engineering perspective. It’s very easy for us to look at the problem and be handwavy about it, and that’s a major reason why this is extremely frustrating to watch. I can understand why we often see silence, as past statements have repeatedly changed, and there’s no timelines that can be committed to, but it’s not proving to be good community management.
Personally I’ve fundamentally disagreed every time I’ve seen a step away from a hard breaking change, but every time an engineer says something concrete regarding the reasoning behind decisions I find myself learning something and often agreeing in isolation.
I can see something like this being a successful way to communicate. While the progress blogs (e.g. how you’re interfacing the new GC against the old native API expectations) have been interesting, they’ve not spoken to the overall state of progress in a way that’s satisfying. It would be nice to hear about the challenges that underly development direction, even if they’re non-technical in nature.
I think the most demystifying communication has proven to be effective to me. Learning about the issues with the package-based ecosystem and how that stymied turnaround times, how the mono repo was a part of the solution and what that meant for the future, for example.
That’s so incredibly exciting! I wish you and the team continued success.
As a Unity Assets Store publisher delivering big breaking changes to my tools has always scared me, and that led me to postpone multiple updates until the accumulated features were worth a new version of the tool…
Here we’re talking about Mono (decades of code) being reworked to the new CoreCLR, change is scary, breaking people’s projects is I’m sure something that terrifies your collogues, but I think clear communication and telling people hey, this new editor is the most major rework we’ve done in decades, and you back it up with meaningful performance gains and modern C# support and all the countless systems that are currently being modernized by other Unity teams, I think people would understand. But if you can do both, deliver the most groundbreaking change and a seamless transition that’s a noble goal.
Silly suggestion but instead of calling it Unity 7 you can call it Unity 7 Next-Gen which would make it sound as fancy as it is under the hood, instead of just Unity 7, which signals yet another incremental update, once these major reworks of the engine are done I think Unity would focus on delivering new features again so those versions can be called Unity 8, 9 again just fine.
Make compiling and iteration times faster and any heads up on writing current code to be compatible for future changes. That is what I care about, is that even likely to happen?
I’ve often found myself in the minority when it comes to the idea that breaking everything and starting from scratch is the best approach. In my view, that path risks undermining existing business relationships and makes it harder to deliver a reliable product.
Coordinating teams around a future version of Unity that doesn’t yet exist is incredibly challenging. Incremental refinement over time has the potential to deliver meaningful product updates more quickly.
I appreciate that many developers disagree, and I understand there is value in either approach if executed well.
Even when there is no reason to have an ETA, setting a milestone will get you to complete work 10x faster - that is also true for personal projects - i imply you to try it.
The main problem that all Unity Teams are facing is never setting concrete milestones. As soon as a concrete milestone is promised the pressure increases, but that ultimately leads to results (even if it is sometimes unpleasant)
I just recently watched an awesome GDC talk, and it also kind of had a nice finding - when you set milestones you start to work smarter, so you can reach the goal in time. Thus also freeing you and your team members up to do new and exciting stuff once this milestone is done. And potentially also allowing for extra free time.