I have a question, if IL2CPP still uses Boehm GC, is there a significant performance difference in GC between JIT and AOT?
1 Like
I’m going to use “I” here and respond directly to the frustration that I see expressed by some of you in this thread and the previous one.
First and foremost, I completely get the frustration about not having CoreCLR in Unity yet. It’s honestly frustrating for me as well, especially seeing all the great things happening in .NET Core+ that we’re still missing out on in Unity. I’ll admit, even I don’t enjoy using Unity sometimes because of this - can you imagine?
That said, it’s important to understand that this frustration is only a fraction of the challenges (and yes, sometimes frustrations) we’ve faced internally to make this happen.
When I joined Unity to develop Burst, I also immediately started pushing for upgrading the .NET runtime, and I actually made the first prototype of Unity running with CoreCLR back in 2017. It took a huge amount of effort just to get the ball rolling. It wasn’t until I was able to form the .NET Tech Group at Unity - bringing all the .NET-related teams and allies together - that we could fully put this vision into motion. I’m honestly humbled to be working with several talented engineers at Unity, like @joncham above, to make this shared vision a reality.
So, what kept me going through this long journey?
Firstly, a wise piece of advice someone gave me at the start: “you need to be patient.”
Secondly, a strong belief in this vision - that C# and .NET are a fantastic programming foundation to enjoy developing games.
Thirdly, as the co-founder of the Stride C# Engine (previously known under other names), which had its own cool features, I truly believe Unity is in a far better position, as a more mature engine, to bring this vision to life.
Yes, in an ideal world, all this work should have started much earlier - we’re aware of that, and we feel your frustration. But we’re here now. The past is the past, and focusing on negativity won’t help any of us. What keeps many of us enthusiastic is that it’s finally happening!
One last thing, as others have mentioned: Even without CoreCLR, passionate developers around the world are still creating amazing and successful games with Unity. And, hey, working with constraints often pushes you to be more creative than you’d expect. CoreCLR isn’t going to be a silver bullet on its own - it’s your passion and dedication that really bring your dreams to life.
I know this message won’t magically take away the frustration, but I hope it helps you understand the bigger picture. I won’t lie, bringing more positivity and support here is what really helps keep our teams motivated. 
81 Likes
Thanks for the insight, I can’t imagine how complex a change this would be to manage across such a complex product. Has there been any consideration of biting off a smaller piece of the pie and releasing editor tooling support first, then platform by platform or is it a one in all in type situation?
Very appreciate your response and this actually relief some of my frustration even not all
This is something I can totally imagine because I am not enjoy unity specifically about this. But the more frustrating things is people who have no idea about this frustration at all trying to argue with me that we can wait because we would be alive in the next 20 years or something. It was recurring argument I hate to hear so much. It now frustrate me more than the delay itself
This is the reason I totally frustrate because it lure me to stuck with unity and trust that unity will deliver C# experience properly. And the exact reason of frustration admittedly came from I have too much trust on unity so my expectation are too high from reality
What I try to point out now is that currently it still not enough. My complain is not about you and the engineering team but on the unity company itself. Unite 2023 and 2024 is the evidence of resource management that they always have very shiny new graphic feature to show. Development in the area that visually look good are always their first priority of the engine instead of core system and scripting that was underlyingly can made impact to everything
And I want this voice to be heard to the CEO that I want you people to have more resources, more salary, more team member and more support from every other team of the unity engine. So that your work can see the light of production stage as soon as possible
I wish you and your team will got every good things possible so that you can have less effort to overcome any obstacles and challenges. So that we can get Unity 7 beta even before the GDC if possible
3 Likes
I’m not new, I’ve been a Unity developer for 8 years, I’m just more patient than you are apparently lol, and this time it seems different, since they promised we will see it in a Beta next year I have faith they’ll do that, they never promised before that it’ll be in any version of the engine.
3 Likes
They just announce on Unite as Next release generation not a specific version of the engine. And I don’t recall that it was announced to be next year, beta or not
1 Like
They did mention an open beta next year in the keynote around the 1:36:00 mark
3 Likes
Asking for a feature to be released before it’s ready because you think you’ll die young is next level.
14 Likes
open beta next year
It not clear which beta. It maybe 6.1 beta or 6.3 beta. And not promise next major release to be 7 beta
At this rate I am not even sure 7 beta will include .net modernization. Now unity even cannot say that the version name of next release generation would be 7
As I have been said from the start. I wish I could be optimistic about this, optimistically it would be as you assume. But even the slide “Unity 6.1” “Next release generation” are look to be misleading. I am seeing that slide and also misled to think “Next release generation” is “Unity 6.1” and as more info are investigated now I am even more skeptic
1 Like
I need to mention this because there is a person who think they can wait for any years because they are not 60 yet
1 Like
We’re actually proceeding almost like this internally - there’s really no other way to do it. 
For example, IL2CPP with the .NET 8 BCL isn’t yet fully running on just Windows or fully tested in Unity.
There are a lot of pieces that need to come together. For instance, while the editor is already running with CoreCLR, we still can’t fully use .NET 8 but only netstandard2.1 because IL2CPP doesn’t support it yet, and we can’t just disable IL2CPP tests for all platforms during such a long transition. That’s just one example of how these things are interconnected.
So, you can imagine the complexity of sequencing all of this. We have many moving parts, and not just within the .NET Modernization. Some things are working well, but plenty still aren’t. If we released a public version of what we have right now, people would understandably be upset about all the things that are still broken (though I’m sure some folks would be thrilled to just play with CoreCLR here 
). But you get the point - we can’t satisfy everyone with all the constraints we’re dealing with. It would be unacceptable, especially for our partners (like consoles), if a public version of Unity, even in beta, didn’t fully support their existing platforms.
21 Likes
FYI, my argument is not just on dotnet but also about all other feature such as ECS
And animation
This similar pattern of “Next release generation” is somewhat concerning about the word “beta in next year”
2 Likes
Like many, I mostly read and don’t usually comment, but: Me and my team are loving the effort you put in to make this a reality!
I know it takes time, our own games also take years to develop. Keep going, keep improving. Keep the eyes on the prize. When it does release, all the efforts will have been worth it.
Look at burst. So much great engineering. Seemingly took forever to develop fully, but now we are reaping the rewards every day.
14 Likes
Utter nonsense, people here are waiting because it is our only option, voicing frustration and being annoying will not make Unity work overtime to satisfy us, they are developers just like us, but unlike most of us they are taking on a monumental task, we should support them and be patient and respectful.
15 Likes
I kind of get the feeling we (somehow) aren’t working from the same information here.
Here’s a snipped up transcript of the Unite 2024 keynote starting around 1:30:44.
So, what’s next? We’re already rolling additions to the solid foundation of Unity 6 into an update which we’ve slated for early 2025 and we’re calling the Unity 6.1 update. We’ll make it easy to bring your Unity 6 projects to the update when it ships next year, and all of these enhancements are built on the core capabilities that we are shipping with Unity 6. We’ve been hearing about them today. Graphics, multiplayer services, and platform support. We are extending and adding even more value to these key areas, and we’re going to going to be supporting this release for a long time. You can look forward to features like support for foldable and larger screen formats, Deferred+ rendering in GPU resident drawer, and new build targets for Facebook Instant games, and a new build profile for Meta Quest.
But, well we’re already working on the Next Generation after Unity 6. In fact, we’re already over a year into development, and we’re really excited about what the new capabilities are going to bring you. We’re a ways out yet, but today, we want to give you just a taste of where things are headed and what that will help you to do.
Our vision for this release is driven by your feedback. We hear that you need a simpler experience with improved tooling for rendering and better iteration speed, and the power to build games of ambitious scale. You tell us that there are too many systems to choose between, and this adds risk and uncertainty to your project planning since you have to choose a UI system, a rendering pipeline… We want to remove this complication. To solve these pain points, we’re planning a new release generation that marks a fundamental shift in our thinking and approach. It will dig deep into our core and bring you greater speed and simplicity across systems.
DOTS is an integral part of our efforts to streamline and improve performance across the Unity engine, so we’re bringing ECS, the Entity Component System, into the very heart of the Unity engine, and we’re integrating Entities with GameObjects. This shift will bring tremendous benefits even to those of you who don’t typically pick up DOTS features to use in your projects. It will accrue performance gains even in GameObjects based design, as well as hugely increasing the accessibility of Entities so that you can tap into that power and scale at any skill level.
The content pipeline is moving to a new approach that emphasizes iteration time, taking many import tasks and running them in the background while you’re working, which means that you’ll spend less time waiting and more time working on projects. And beyond this, we are creating a new world building system built on top of DOTS. So you can create large detailed worlds across platforms including an overhaul to the end-to-end workflow, virtual texturing and advanced tessellation to maximize details, non-destructive workflows for greater flexibility, and Shader Graph integration for terrain service, the ability to seamlessly blend in meshes.
We’re also introducing an all-new animation system that offers tools and workflows that are designed for a new generation of games, including production flexibility, animation at scale, and performance across platforms.
Now, we also know that scripting is one of the most important parts of your creation experience. So we have been working on moving all Mono functionality to CoreCLR. This will keep you up to date with the latest .NET advancements, and it will bring big performance gains both to the editor and to the runtime.
So, I think you can see why we’re already so excited about this big release, even though it’s a ways off. And we will continue to support and enhance Unity 6 so that your projects can stay on track, and you can make the jump whenever the time is right, so you can start taking advantage of these benefits.
Now last thing, we want to get this right. So we’ve started sharing and pressure testing the next major release with a few developers. We’re actively soliciting feedback to ensure that what we are building will truly make an impact on how you use Unity every day. Next year, we plan to open up wider feedback through an open Beta. We’ll have a lot more to share about the future of the Unity engine at our roadmap session here at Unite.
My point: the screenshots of the slide with “Unity 6.1” and “next release generation” make sense / aren’t misleading if you actually watch the presentation. As one American said, “everything is in context.”
Other gaps you can fill in if you think like a reasonable person:
It ultimately doesn’t matter if it’s 6.2, 6.3, 7, 69, 1944. We’ve been told they plan on a beta of the “next generation release” next year.
They call it “next generation release” because they haven’t yet decided how they want to proceed with naming going forward. Whatever.
7 Likes
It’s not just me you know
And yes, the version number is actually not important, what we argue right now is the hint about “beta” that people assume will actually contain the “next release generation”. Some already assume it would be next year. I just trying to point out is that it not actually confirmed. The number 7 (or 6.1 6.2 6.3) is just one of the hint
Is there a reason to NOT disable compacting GC?
It seems like in a game settings it’s not that helpful and also can introduce stutters + unneeded background load to analyze heap fragmentation. Also compacting GC requires to rewrite a lot of API code, and for gamedevs to pin managed objects when using some optimizations strategies.
IMO the value of compacting GC for gamedev is net negative.
1 Like
The keynote states their intent. Please read/watch it again and tell me exactly what logic brings you to say they are not planning to have an open beta of the next release generation next year.
1 Like