In past we know many approaches to create shaders from C# and or IL.
Now Paradox create new one for their engine: http://doc.paradox3d.net/html/index.htm?page=Rendering+System
What you think about ability to write chaders almost using C# using all it benefits, that than in compile time and/or runtime will compile it to platform dependant variant? 
Isn’t syntax practically the same? What benefits are you speaking of specifically?
In past I have see solution entirely build on pure C# and so I have full capabilities of C# + VisualStudio + R#.
Inheritance, any C# logic will work.
Just use one right using Blablalba.ShaderCore and all types will be from there.
I don’t need to write code in Notepad with just syntax highlighting, I just can not make mistake because R# will show it in moment and so no and so on and so on
It doesn’t make sense in my opinion to be able to use C# for shader implementations. There are so many aspects of C# that simply make no sense when it comes to shaders and library wouldn’t be usable as well.
The strengths of C# that you want out of this, would make shaders super-heavy. I’d be surprised if anyone could get remotely decent performance out of a shader that was dragging the .NET architecture along with it.
It makes no sense to use c# for cg. They’re two different languages. They’re quite similar so this is essentially inventing a problem for an existing solution.
I appreciate why it’s done - it’s great for programmers who like this sort of thing, but ultimately the world is moving toward compute shaders and this is something that’s best to keep close to the original specification as possible in order to share resources online etc…
For standard shader models, I would advocate that node based shader editors eventually become optimised enough that one cannot tell the difference in performance between hand-optimised cg and the node based shader editor. With enough care and options it should be possible - and not just for programmers but artists too.
It not true shader will be as fast as possible and maybe even faster No one says that these abbilities goes to runtime it all about compiletime or runtime shader creation and compilation.
This create ability to store just small codebase of shader and create and cache needed combinations on build or start or run time… And many other positive sides, just read what I talk about.
All this can be implemented using graphs but My personal view is that event graph can be written as high level extension around C# shader writing system and get all graph node through reflaction
And you always can write raw shader if you want if you find it in web
For the sake of small similarity I do not want to confuse a great language. Yes, gpgpu is great, passing c# thread in special manner is also great. Two parallelisms are so different from each other. In summery: Coding for cpu and coding for gpu, are two different things.
Cost of minimalistic procedural language introduction is much lower than cost of confusion between contexts.
Yes, it is true. You might be able to get a small subset of C#, but in order to achieve the same degree of speed and flexibility you would lose a lot of the normal functionality that C# offers.
While there has been some work to use shaders for more than graphics processing, they are still designed completely differently from traditional processors. They simply are not made for the same tasks that C# was designed for.
There were some projects attempting to do it, but when I tried looking into them they have either not been updated in years or their websites have completely vanished. If it were truly superior, let alone viable, they would still exist.
I can see some benefit in having all valid shader code also be valid C# code (like how all Cg is valid HLSL). Being able to include the shader file with your data structure definitions in has been a useful technique in C++ for a long time (so you can ensure that e.g. your vertex layout matches on both ends).
Namespace support would be nice as well.
Cg and hlsl can be married, but c#? its different story. Your points of benefit are right. For this, can we try changing unity’s cg implementation? Just a suggestion, in stead of c# for shaders.
Looking at IL2CPP I would like to have IL2HLSL or something like that as well
My thought, too.
I suspect that the shaders the OP claims to have seen written in C# weren’t actually for GPUs. Software-based ray-tracers, for instance? It’d make sense there.
He’s only talking about data structure compatibility, not full language interoperability. Since there’s so much syntactical overlap, he’s saying that you could set things up such that the definitions of shader data are shared between both the engine code and the shader code. The advantage is that maintaining them alongside one another becomes easier because your tools will just natively automate more of the work for you.
http://paradox3d.net/images/blog/ParadoxSession3-BeyonUberShaders.pptx
There what I wrote about and their solution way more simpler and flexible than Unity Uber Shader.
A bit of old topic but I think rather than another language for shader, we need these:
When I write shader, I do not feel like I am programming. I feel like an unsecured type writer.
I don’t care how the shader works behind the scenes so long as we get a visual node-based shader system. 
At least it’s not PHP. That’s an unsecured typewriter that can only be used while riding a monocycle through a minefield.
Without inside knowledge of how shaders work and the overall rendering pipeline and favorably gpu architecture, I highly doubt how would a node based material system would help! 
In my view, such tools help reducing development time for the guys who are already familiar with shader writing from the scratch. When I first meet shaderlab, strumpy shader editor, I did not know what the heck is going on…
Then I educated myself about rendering pipeline basics and a view of general gpu architecture and a overview of how graphics apis communicate with a computer system. Then I learnt how unity implements cg. And now I think a node based system would help me a lot as I will understand them quick. Like I said, I need autocomplete and debugger greater than a node based system.
I considered the idea in this thread [Idea] Unity with C# to GPU power! - Industries - News & General Discussion - Unity Discussions
The concept is that C# parallisable code could be compiled to compute shaders if the user prompts the compiler to do so and the hardware can do it.
There is no reason why C# ‘code’* could not be used to write shaders.
*although the code would be limited by the GPU platform it runs on, so it would be more like a C# flavour of other shader languages.