Having just found out that you can use Ruby or Python inside a SilverLight application..
link here
..I wonder if its possible to bypass some of the SilverLight limitations with use of these languages instead of C#.
I know that the Ruby Engine inside the SilverLight application is trimmed down, just as the .NET CLR is, so I would like to know that even without all the functionality of a full Ruby or Python Engine:
Can I still be able to do something
with the use of these dynamic
languages that I wouldn't be able to do
in C# SilverLight?.
If we need to download something built
by the community to extend the cut
down Ruby implementation (to support
Interop calls for instance?), what's
the impact on deployment?.
If not, if you cannot do anything
you wouldn't be able to with c#, with these engines, besides
the typical benefit of a dynamic
language, and not really circumventing
some of the restrictions of the
SilverLight's CLR, why would one
choose to use Ruby in a SilverLight
application?
One of my interest points is use of sockets, socket usage in SilverLight is improving in each version, but it can still be troublesome because of the xml authorization file required on the server side..would ruby be able to make this unnecessary?
Thanks,
Ric
Best Answer
I suspect you won't be able to work around that. Keep in mind that it's not the language imposing the limitations here but the runtime. TO be precise, it's Silverlight itself. Since both C# and Ruby are compiled to CIL in this case you're left with more or less the exact same capabilities (except some differences in the typing system).