ShalokShalom (Jul 24 2025 at 22:26): ShalokShalom (Jul 24 2025 at 22:26):I see that C# is mentioned in the README and other parts of the documentation.
Can I know what makes the implementation exclusive to C#?
As opposed to universally .NET compatible?
I am especially thinking about F#.
(Considering that the language is consciously developed for utmost C# compatibility, even.)
And also Clojure.NET, IronPython, PeachPie, VisualBasic.NET, and so on, should work?
Some may have to adapt to an uncommon, less idiomatic API consumption.
Is there a good, technical reason why C#, and not .NET is mentioned specifically in this case?
I do know that the C# community has the tendency to see its language as synonymous with the platform, for some reason. Casually forgetting that there are also other languages on the platform. :slight_smile:
Thanks a lot for the answer :slight_smile:
ShalokShalom (Jul 24 2025 at 23:51):I made a list
https://gist.github.com/ShalokShalom/3e65320ea50a30ac3c53988248fb80fa
Victor Adossi (Jul 25 2025 at 11:41):Hey @ShalokShalom this would be a great question for the #**C#/.net-collaboration> channel -- you might get a faster answer there
Victor Adossi (Jul 25 2025 at 11:43):I'm not super familiar with C# but the docs for https://github.com/bytecodealliance/componentize-dotnet definitely mention .NET, and I think it's just the generated code that is C#, which means that you'd need to generate C# to use that code directly.
That said, if your language can interop with C# (i.e. bring in the generated code, or you can build that to CLR artifacts that you can reuse and stuff implementation into), and build with the same flags/config, I don't see why you couldn't use any other CLR languages!
Victor Adossi (Jul 25 2025 at 11:43):@James Sturtevant is the right person to answer this question though
Joel Dice (Jul 25 2025 at 15:16):AFAIK, there has been no effort yet to support or test non-C# languages with the existing binding generator, but feel free to try it with your favorite language. It might Just Work, or at least be easy to fix.
James Sturtevant (Jul 25 2025 at 16:26):The code it generates is c# but that could be split out into a library and consumed from another .net based language
Joel Dice (Jul 25 2025 at 16:29):It's possible to write or generate C# code that isn't portable to (i.e. can't be called by) e.g. F#, though right? Are we sure we aren't generating such code?
Joel Dice (Jul 25 2025 at 16:36):I'm referring to CLS
James Sturtevant (Jul 25 2025 at 16:47):Yea it's a good point. I don't think we are doing anything but it has been tested or tried that I know of. Be interesting to find out
Scott Waye (Jul 25 2025 at 21:43):F# is known to have some issues with NAOT. It make work well enough for your use case though. https://github.com/dotnet/fsharp/issues?q=is%3Aissue%20state%3Aopen%20AOT
ShalokShalom (Jul 26 2025 at 16:35):Thanks a lot! May we move this topic to the .NET channel? :slight_smile:
Scott Waye (Jul 28 2025 at 19:45):From the NAOT-LLVM discord, the opinion is that if you use --reflectionfree then it should be fine.
Scott Waye (Jul 28 2025 at 19:46):if there are no trim warnings.
Last updated: Dec 06 2025 at 06:05 UTC