Hacker News Reader

Comment by hannofcart | Hacker News Reader

Have been using Godot via the excellent Gdext Rust wrapper. It's all smooth sailing except for one issue: if a Rust signal initiated trigger calls into Godot and that in turn (via callbacks/signals whatever) calls back into Rust, it crashes because of Rust ownership rules.

Of course there are workarounds to circumvent this but they are a bit clunky.

Have been following Miguel de Icaza's work on Swift Godot and am really tempted to switch. Swift feels like an ideal language for game dev: type safe to allow frequent refactoring, a simple but effective (enough) memory management mechanism, good performance...

And de Icaza spearheading this makes it more compelling still. The guy takes on rather tricky engineering problems and sees it to completion.

View on HN

Why not just use gdscript? Or C++

As someone who likes lower level languages (like rust) I find gdscript to cover all my needs (since 2017)

Or C#, that has official support and Slay the Spire 2 is apparently coded with it.

Life's too short to write C#.

How so? C# seems quite a bit more productive than GDScript, to me.

(and is faster by a factor of 10)

Is this still generally true? I thought the 4.1 release sped up gdscript significantly.

Plus most work in gdscript is just calling c++ anyway.

Yeah, I just don’t like C# lol.

It’s worth noting that they ported SS2 from unity to Godot, so it’s likely they were trying to keep as much of their existing code as they could, but tbh they’d probably use c# from the beginning regardless

Yeah, you can totally use both gdscript / C#, as well as C/C++/Rust for targeting performance sensitive objects, like doing heavy simulations, since gdscript / C# will still be often simpler for glue code and light-weight signal handling. I think people misunderstand that this is less Rust bindings for the engine and more so like producing plugins/mods for the engine to import.

For why Rust vs. C++, Rust is often able to handle embedded invariants through the type system, while in C++ you'd need to juggle them in your head, which scales a bit poorly through time or number of people working on the project. That said one thing that doesn't match well is the Godot is very inheritance based, which is a bit of an impedance mismatch for using Rust, but I've found gdext to translate these things into composition well enough.

My worry with Godot-rust is keeping up with Godot updates. It seems to take them some time, which suggests that gdext and friends are quite complex.

I just don’t know if I want to pull in that complexity, yknow?

I’m waiting for bevy’s editor before I go too far into rust land for my games.

Writing an entire complex game in GDScript sounds like an absolute nightmare.

It's a fine scripting language for hobby games or glue code. I would never do serious software development with it.

I'm curious what are the underlying reasons that make you hold this position?

Not OP, and have only ever made hobby games in GDScript, but here are a few I'd be concerned with:

- GDScript objects are very heavy, as the base class of objects are a bit heavy (by their own admission). So having a lot of them can lead to memory/performance issues.

- GDScript is best when you’re using the optional typings, but there are certain operations that make this a pain (e.g., Arrays can be typed such as Array[int], but most functions will return an untyped array, as well complex types such as Array[Array[int]] and Dictionary[String, int] are not supported. Generics are also unsupported.)

- Coming from a Python background, GDScript is just close enough to Python to feel familiar, but just different enough that half the things you’d expect to work don’t. It can be a bit taxing keeping them straight in your head if you try to use both frequently in different contexts.

- The editor itself is missing a lot of IDE creature comforts such as code formatting.

These are just a few off the top of my head. None is enough to make me abandon Godot or GDScript, but would wear on me in a larger project.

What makes gdscript object “heavier” than the c++ classes that implement them? IIRC the docs just mention that creating gdscript objects is an expensive operation, but that’s just as true with C# objects because both have memory allocations.

Modern gdscript best practices call for typing, but tbh I think making a game without types is possible and fine (Lua and JavaScript are used to make successful games for example)

Totally true about python. If you’re used to python, gdscript is like writing code in a funhouse mirror.

You don’t need to use godot’s editor. Godot has a built in LSP, so the vscode extension works well. I think they even added a scene graph view.

I mean use whatever you want to make a game, but personally, I find the Godot specific language features really sell gdscript. (Signal connection syntax, $ and %)

I usually wire up signals is gdscript and write actual work (algorithms and math) in dependency-free gdextensions

Here is the reference for the base Object class in Godot, so every time you instantiate an object (even if you have defined a simple class without a lot of complexity), all of this gets instantiated and allocated. This is MUCH heavier than a C# base object (which wouldn't necessarily have to be based on a Godot class).

https://docs.godotengine.org/en/stable/classes/class_object....

Keep in mind I don't say any of this because I dislike GDScript. It's just not the best tool for all jobs in my opinion.

For sure. No heated debates here!

Rollercoaster tycoon 1 and 2 were written in assembly. Great games can be made from anything.

Normally when I make Godot games, all of my classes are nodes anyway. I really lean into the “everything is a node” idea.

Now if I’m writing some algorithm (A* or marching cubes or whatever) I wouldn’t start with gdscript, so I guess I never really made gdscript objects just off the base Object class before.

“Serious software development” doesn’t really mean anything.

Writing a whole game in gdscript (and godot) seems totally fine.

Imo it’s a better language than Lua, and 100s of games are written in Lua.

Balatro, undertale, hotline Miami (anything in game maker)

> it crashes because of Rust ownership rules

Ownership rules exist only at compile time and are not the reason it crashes at runtime.

Unless it's using e.g. RefCells to enforce them at runtime

Ownership rules describe an invariant that needs to be upheld both at compile time and run time for Rust code to function.

hmmm…

Ownership rules can be arbitrarily violated by unsafe code which may cause a crash, or undefined behaviour but it does not prevent rust code from running.

Many “violates single ownership rules” (eg. Concurrent mutable references) actually dont break rust, because the undefined behaviour on many platforms happen to be “eh, does whatever c does, which is actually fine”.

It would be more correct to say that they must upheld to guarantee rust code functions correctly.

However, segfaults come from memory corruption, which comes from unsafe code; probably use after drop. It doesnt usually come from violating single ownership rules, and usually it’s from “object was dropped because it was owned and you forgot to keep it alive across a callback boundary” just like c++ code with unique_ptr

…but eh, whatever. The point is it crashes, which means the binding isn’t done correctly, whatever you call it. Lay blame where blame is due; the rust wrapper isn’t safe.

"crashing" could also mean a panic! caused by the runtime ensuring you have at most one mutable reference to an object.

For one definition of "don't break". If you are UB, in my books (including the Rust book), you've broken.

As per your comparison to C, you are mistaken, this would do whatever C does when it has incorrect `restrict` qualifiers.

See how the book phrases it for yourself: https://doc.rust-lang.org/book/ch15-05-interior-mutability.h... The way RefCell works is not described as a similar but different set of rules or invariants, but as enforcing the same rules.

Please do not ignore the compiler's assumptions in your own programs...

You said, and I quote:

> needs to be upheld both at compile time and run time for Rust code to function.

That is not correct, in general, even if in some cases, it causes a crash via panic or segfault.

A program that fails under some circumstances is a buggy program. The fact that it doesn't crash under some circumstances is no redeeming quality at all.

I don't know what you are trying to argue here. This thread is already too deep. Ownership rules are not optional. Sorry?

You said, and I quote:

> needs to be upheld both at compile time and run time for Rust code to function.

That is not correct, in general, even if in some cases, it causes a crash via panic or segfault.

/shrug

If you want to argue a different point with someone, do it with someone else.

I’m simply pointing out that you are categorically wrong in your statement.

I've explained and I've linked references, your last two comments say "not correct". If you don't want to argue don't, if you do please present arguments.

You are not "pointing out" anything, you are stating against evidence.

Reply on news.ycombinator.com