5 ms·

I'll agree upfront that it's been adopted very corporately, but it's worth noting that the Unity game engine uses C# extensively. If you enjoy video-games and o

I'll agree upfront that it's been adopted very corporately, but it's worth noting that the Unity game engine uses C# extensively. If you enjoy video-games and one of them is on this list[1] it was likely written in C#. https://en.wikipedia.org/wiki/List_of_Unity_games#2021 https://en.wikipedia.org/wiki/List_of_Unity_games#2021

torginus 5y ago
Unity's dialect of C# is not really the same as .NET's C#. Even though they've made strides to keep their version of C# up to date, the way of doing most things is not the .NET way. Unity has it's own dependency management, project system, runtime, idea of threading/parallelism, concurrency, networking etc. Usually when one gets involved in some language ecosystem, the language is the small part, getting to know the libraries, and the idiomatic way of getting things done tends to be the emphasis. Here the ecosystems (Unity's and .NET's ) tend to be quite different.
- moritonal 5y ago
  Oh by all means, don't get me started on what they did to IEnumerator or awaits. Plus they _really_ fell into a hole by trying to compete with Unreal from a graphics perspective, forcing them down the route of having to write a compiler xD https://docs.unity3d.com/Packages/com.unity.burst@0.2/manual/index.html https://docs.unity3d.com/Packages/com.unity.burst@0.2/manual...
  - torginus 5y ago
    Unity made tons of strange decisions over its lifetime. Like first, they picked .NET and it's Mono implementation, which wasn't as fast as the original one, but was decent - then they kicked up some stink with the Mono devs, leading to them shipping a Mono version that was at a point a decade out of date, and performed way worse than either Mono and .NET. Their first idea was, instead of updating Mono, what if they compiled .NET IL to C++, resulting in the monstrosity that was IL2CPP. If you are interested in what sort of C++ code it generated, here's a link: https://www.jacksondunstan.com/articles/4654 https://www.jacksondunstan.com/articles/4654 It's full of goto-s, helper method calls, and passing around these weird helper objects to every method. They triumphantly announced their perf gains - compared to their own old impl, which I remember being slower than Python at times. Then came Burst/ECS, like you mentioned, the former of which is working pretty well, but requires you to rewrite your C# code, with Unity-licenced dependencies, so even if you wrote a kickass dynamic tessellation library, it could be only used in Unity, because of said deps. The latter is still in forever Unity innovation limbo. Meanwhile in Unreal-land, they used pretty much standard C++, for a decade, no arcane space-magic ECS found here - and the code has been pretty much stable for that time.
    - oblio 5y ago
      > Unity made tons of strange decisions over its lifetime. Heh. None of those of those decisions seem strange once you view them through the lens of some game devs full of hubris :-)
- mapmap 5y ago
  When one reads .NET documentation, how does one see if that piece is supported in Unity or not?
  - torginus 5y ago
    Generally, API support is not that bad, afaik Unity supports .NET standard 2.0, which is a bit old but not ancient - the chief problem is there's stuff like async/await in .NET which is their standard way of asynchrony, but not really supported in Unity without workarounds. Also the serialization system in Unity tends to interact weirdly with more complex .NET object hierarchies, so expect strange things to happen.
nix23 5y ago
Ah yes the game-industry i far less tech-as-a-cost-centered ;)
Zababa 5y ago
Aren't video games companies a good example of tech-as-a-cost-center companies? Salaries are often not great, working hours terrible.
decafninja 5y ago
Now I'm curious what a typical Unity C# codebase looks like versus your typical .NET enterprise application. Plus I'm sure a typical Unity game dev shop is culturally extremely different from a typical .NET enterprise dev shop.

torginus 5y ago

Unity's dialect of C# is not really the same as .NET's C#. Even though they've made strides to keep their version of C# up to date, the way of doing most things is not the .NET way. Unity has it's own dependency management, project system, runtime, idea of threading/parallelism, concurrency, networking etc. Usually when one gets involved in some language ecosystem, the language is the small part, getting to know the libraries, and the idiomatic way of getting things done tends to be the emphasis. Here the ecosystems (Unity's and .NET's ) tend to be quite different.

moritonal 5y ago
Oh by all means, don't get me started on what they did to IEnumerator or awaits. Plus they _really_ fell into a hole by trying to compete with Unreal from a graphics perspective, forcing them down the route of having to write a compiler xD https://docs.unity3d.com/Packages/com.unity.burst@0.2/manual/index.html https://docs.unity3d.com/Packages/com.unity.burst@0.2/manual...
- torginus 5y ago
  Unity made tons of strange decisions over its lifetime. Like first, they picked .NET and it's Mono implementation, which wasn't as fast as the original one, but was decent - then they kicked up some stink with the Mono devs, leading to them shipping a Mono version that was at a point a decade out of date, and performed way worse than either Mono and .NET. Their first idea was, instead of updating Mono, what if they compiled .NET IL to C++, resulting in the monstrosity that was IL2CPP. If you are interested in what sort of C++ code it generated, here's a link: https://www.jacksondunstan.com/articles/4654 https://www.jacksondunstan.com/articles/4654 It's full of goto-s, helper method calls, and passing around these weird helper objects to every method. They triumphantly announced their perf gains - compared to their own old impl, which I remember being slower than Python at times. Then came Burst/ECS, like you mentioned, the former of which is working pretty well, but requires you to rewrite your C# code, with Unity-licenced dependencies, so even if you wrote a kickass dynamic tessellation library, it could be only used in Unity, because of said deps. The latter is still in forever Unity innovation limbo. Meanwhile in Unreal-land, they used pretty much standard C++, for a decade, no arcane space-magic ECS found here - and the code has been pretty much stable for that time.
  - oblio 5y ago
    > Unity made tons of strange decisions over its lifetime. Heh. None of those of those decisions seem strange once you view them through the lens of some game devs full of hubris :-)
mapmap 5y ago
When one reads .NET documentation, how does one see if that piece is supported in Unity or not?
- torginus 5y ago
  Generally, API support is not that bad, afaik Unity supports .NET standard 2.0, which is a bit old but not ancient - the chief problem is there's stuff like async/await in .NET which is their standard way of asynchrony, but not really supported in Unity without workarounds. Also the serialization system in Unity tends to interact weirdly with more complex .NET object hierarchies, so expect strange things to happen.

nix23 5y ago

Ah yes the game-industry i far less tech-as-a-cost-centered ;)

Zababa 5y ago

Aren't video games companies a good example of tech-as-a-cost-center companies? Salaries are often not great, working hours terrible.

decafninja 5y ago

Now I'm curious what a typical Unity C# codebase looks like versus your typical .NET enterprise application. Plus I'm sure a typical Unity game dev shop is culturally extremely different from a typical .NET enterprise dev shop.