Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There's another power when using the same underlying runtime environment as well: no bridging overhead. If your specific problem set involves a lot of boundary crossing bridging overhead can easily dominate all else.

Long ago I integrated IronJS (written in F#) into a project written in C#. IronJS at the time was a very primitive JS compiler though it was a real compiler using the runtime machinery to emit Expression objects that were JIT'd into native code.

I was very excited about switching to V8 for the vastly improved performance. To my shock and horror once I got it working the performance was worse. It turned out most scripts called our API a lot (the equivalent of the DOM in a browser). Bridging between CLR types and V8 (C++) types completely erased V8's superior performance. No amount of lazy bridging and zero-copy abstractions were enough and I eventually abandoned that branch.

It was a humbling experience that I learned a great deal from.



There is a nuance I love to bring up: .NET biggest strength in the apps market today is the best support for native interop. Bridging .NET to Swift/Objective-C or .NET to (Android) Java. Every time there are layer in between, you loose. Either by loosing performance (your case) or by loosing capabilities (like the typical Cordova, React Native or Flutter Plugin).

Btw, work of Miguel de Icaza via the Xamarin acquisition.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: