Hacker News Reader

Comment by rphln | Hacker News Reader

I think it'd be interesting to compare against F#, especially since Godot already has first-class support for .NET. When the bindings get fully fleshed out, what will OCaml bring to the table to warrant the extra hoops for the user that has no prior preferences for either languages?

View on HN

Godot uses source generators to fill out C# partial classes, so it doesn't quite have native F# support. You'd at least need C# shims for your types that inherit from Godot classes.

This is why I haven't done f# with godot yet, haven't felt like building out the shims.

Bummer, I had no idea about that. But I guess that, at least for turn-based games, it wouldn't be super annoying if you manage to split the logic (F#) from the UI glue (C#), right?

(I never got around to that point though, I usually start making games as libraries and then get nerd sniped into reading about game theory for the AI before I make them playable for humans.)

Is it first-class support? I hear lots of godot devs saying "I can't use X because I'm using C# instead of gdscript"

C# support is great. But yes, if you need to call a library/extension written in gdscript from the C# code, you'll need to write some C# bindings to make it practical.

It is first-class support, as far as I know everything is accessible from C#. I developed YKnytt, an open source game, fully in C# and never had the issue of something not working in C# as it did in GDScript.

The only thing not available in C# in godot 4 is web exports - they'll come whenever upstream support arrives.

Using C# actually nets you more features, not less.

> the extra hoops for the user

The idea of Godot is "extra hoops."

Can you elaborate on that? I thought it was a fairly batteries included game engine, if you use gdscript at least.

Reply on news.ycombinator.com