Unity and their API

Hi,
I'd like to discuss about the limit of the Unity API and what should be changed.

Unity API Currently
Currently, you have access to the Unity API only via the C# scripting language. It is possible to write plugins in C for Unity, but it is very limited and not that what I have in mind.

What should change
Unity should expose their API not only to C#, but in general. I think Unity is written in C/C++, so let us write code in C/C++ or other language that compiles to machine language like Rust or Golang!
Rust doesn't even need a garbarge collector it has its own memory management with ownerships!
In this way, I can write fast running code and don't have to worry about garbage collection. I can even write my own scripting language (really, C# is bad as a scripting language!)

The down sides
While compiling directly to machine language it's not possible to write 'once and run everywhere code' like with C#.
I think, that's the reason why the Unity team will never expose their API, because it does not fit in their business concept. Unity is an engine to provide your game to any plattform.

But I think it would be the right choice. I like Unity I really do! But it feels like writing code 10 years behind!

 

Unity used to do three things badly.

Now it does one thing well. This is because over time the burden of supporting 3 languages was eating into resources that could be used to further the engine.

But if you really want to write C++ in Unity this guy might have you covered

https://github.com/jacksondunstan/UnityNativeScripting

 

And your solution to that is to... code like you're 30 years behind?

 

But.... why? Just choose IL2CPP if you want your code compiled to machine language as it is.

 

You can disable the garbage collector if you don't want it to run automatically, and then manually ask it to clear memory.

https://docs.unity3d.com/ScriptReference/Scripting.GarbageCollector.html

 

Maybe these links are of interest...

C++ Scripting
https://jacksondunstan.com/articles/3938

Using F# with Unity
https://jacksondunstan.com/articles/5058

 

For that matter here is an implementation of Lua for Unity that might work as a starting point (if not the code itself, then perhaps the implementation details) for getting another language like Rust or Golang into Unity.

https://github.com/Tencent/xLua

 

I think you guys don't get my point.
Your solutions are well known, but does not solve the current problem.
I don't want my code to transpile to C/C++ or bind to C#, I don't want this extra overhead. I want to have access to Unity via an API. It is possible but only with C#. But I need more control of my memory and may use another scripting language without the overhead of C#.

If it is already possible in Unity, enlight me!

 

What specific limitations are you dealing with? None of this theoretical stuff. What's wrong NOW?

 

I'm pretty sure Unity have embraced the DOTS future and various things that enable all sorts of efficiencies at runtime etc. So they are wedded to enabling people to do stuff in C# that is performant. As such I dont see them investing effort in other languages or alternative, performant things in the years ahead.

 

So my advice would be, read up on the detail of DOTS and if it still doesnt fit and you are wedded to c++, choose a different engine that makes more sense for this.

https://unity.com/dots

And especially this particular article may be of interest: https://blogs.unity3d.com/2019/02/26/on-dots-c-c/

Just one example:

 

What exactly is it your doing that unity is not performant enough to perform in its current version?

Im sorry but it does really sound like your talking about hypotheticals, have you actually tried doing whatever it is you need to do?

I doubt your doing anything that cannot be done currently, so this is probably the age old issue of "over optimisation / micro optimisation" rearing its head once again, through yet another user.

Give us examples of what you tried to do that didnt work and how you did it, more than likely its the way you went about it than a limitation of the engine - and we can help you with that.

If however this is simply because you are a c++ programmer and you have been taught that c++ is super performant etc etc, then I urge you to actually use the engine first for whatever it is your trying to do, and then come back if you actually find its not possible because of performance reasons.

Honestly though I am sure this is not really an issue, just one in your mindset.