alt Hacker NewsRegarding tradeoffs:
I've been working with C# for most of my career, almost 25 years, since .Net 1.0. One of the huge things that I love about Rust is the lack of a runtime framework. I don't need to figure out how to bundle / ship / install a framework at runtime.
(I also like Cargo better than Nuget, but that's a very subjective opinion.)
Which leads to probably the biggest tradeoff:
> Typhon is an embedded...
It's probably hard, (or impossible) to use Typhon outside of the dotnet ecosystem. Granted, it's been years (since the 1.0 days) since I built a .dll that a native application could pull in, there are complications when you "impose" dotnet into an application that isn't dotnet. These don't happen when your library is 100% native, which you get with C/C++/Rust.
Replies
I think the developer is specifically targeting running in game engines in Unity, because that's already a C# capable environment.
Personally I'm not worried about the micro optimization, I'm more a "why are you attempting to compete with sqlite" person.
> One of the huge things that I love about Rust is the lack of a runtime framework. I don't need to figure out how to bundle / ship / install a framework at runtime.
Rust has a runtime, it's just tiny and auto-bundled (for now). Modern .NET's support for self-contained bundling has gotten pretty good. AOT is getting better too, and AOT-ready code (switch Reflection for Source Generators as much as possible, for instance) can do some very heavy treeshaking of the runtime.
Also, yeah native embedding has gotten somewhat easier in recent years depending on the style of API you want to present to native code. Furthermore both Godot and Unity (differently) embed .NET/C# as options in game development. I certainly expect Typhon is primarily targeting Godot and/or (eventually) Unity (when it finishes switching to coreclr to support more of these features) embedding (but maybe also Stride, a fully C# game engine).