gleam as a game scripting language?

[twuky]

Hi! Discovered gleam a little while ago and while going through the language tour I kept thinking to myself how clean the syntax was, and how much I'd love to do games programming in a language like this. I've been working with rust quite a bit recently and gleam feels pretty similar but is a lot more "fun" to me, if that makes any sense!

I'm not super familiar with the erlang world and the ways it works and differs from other languages but it does seem like gleam is designed around some choices that would make things like games more difficult to do. It sounds like erlang and by extent gleam is pretty server-focused. From what I've seen so far it seems like gleams notion of mutability, how it "updates" records, and its list type would be pretty limiting factors for that kind of application.

Being able to transpile into javascript sounds like lets it get around some of those limitations, though - so maybe there is some opportunity there? I work on a nodejs library that lets you do native graphics on the system with opengl, so it'd be interesting to see if I could set up a project that uses gleam in conjunction there.

I'm definitely not asking for anything like an interpreter for gleam, I'm more just curious, as folks more attuned to gleam/erlang what sort of difficulties or problems you might expect someone to run into if they try to use it for that purpose? What sort of changes or other features would the language need to work better for games as a use-case, and are those sorts of things even in line with the vision of the language?

[lpil]

I think you could certainly use Gleam the language in a game. The APIs would have to be different to what one would normally find given the popularity of OOP and mutability in that world, but you could certainly make functional equivalents.

I think the challenge would be how to run Gleam within your game. The Erlang VM is not well suited for embedding, and talking to it over a network doesn't sound great for in-game code, but it could work very well in a game that is multiplayer and thus already running over a network. There are several games that use Erlang backends.

JavaScript could be a better fit for conventional game scripting, as you say. I'd be very interested in exploring wasm for this too!

[lpil]

Gleam uses persistent immutable data structures so there's no copying when immutably updating data structures. Immutable data structures are often faster than mutable ones because of this, and they work well in performance sensitive applications.

If you want to use mutable data structures you can do so via Gleam's FFI, so both options are available.

Unless you have monomorphisation like Rust does (which is a large part of why their LSP and compiler are so slow) then traits/type classes have a notable runtime performance cost. Even if we had then you likely would want to not use them for this reason.

Firefly is very cool! I've not looked into it in some time but last I checked it wasn't able to compile a typical hello world. I do hope it gets there though! I really like the project.

[twuky]

When I wrote about the 'copying' i figured there was a concept under the hood I probably wasn't aware of, so it sounds like I have some research to do to better understand how the data structures work and their general tradeoffs.

And again I may be misunderstanding something but when I mentioned impl I didn't mean working with traits,
just the syntax sugar for when a function's first argument is of a particular type and meant to be like a 'self'. it would just be about introducing a shorthand I suppose. for instance in rust you are able to do both Texture::draw(my_tex) and my_tex.draw(). so because its a transpiled language it seems like if you did have a way to tag a function as being "on" a type it could do the conversion from short to longhand at compile step. but i guess in gleam it would only support &self. i get why its not necessary in a functional style of programming, though.

Again thanks for the insight here. I may try to work something out with the JS target first and see what a little hello world game looks like to produce

[lpil]

Oh right! Cool :)

If it's just autocompletion, you're interested in that we could probably do something similar in future using the pipe operator. There's enough information available to the compiler to only suggest functions that accept the value as the first argument.

[twuky]

yeah I wouldn't ask for a whole trait system, ahahaha! Yeah I'm mostly just interested in when I have an instance of a type, being able to quickly see different things I can do with it.
So when using the pipe operator if it listed possible functions that accept the type that would be pretty close for me.

Though I also think it'd be nice being able to access certain tagged functions with dot notation would be nice - even if not in an impl block. Where it would at compile time just substitute that code for calling the function from the module and passing the first argument. maybe i'm just not used to the idea of something like my_obj|>action() as a oneliner

The problem it would introduce is that there would be ambiguity about which function to refer to if it were my_obj.action(). I figure the filter logic would be something like this?

• If a certain function is tagged as associated with a type (possibly in doc comments, if compiler parses those? avoids any macro-like syntax that way)
• and the first arg is that type
• and the function name is unique (when tagging on that type)

Maybe it's much more complicated than that - this is why I haven't written a language myself haha.

If it were just a feature of the pipe syntax, the autocomplete would have to resolve the module but it would clear ambiguity. Definitely simpler than a tagging system for sure

[lpil]

We're not going to introduce a method call type syntax, it serves the same purpose of the pipe operator, which is more powerful.

The module will remain a requirement for the pipe operator but we can autocomplete them with the function name when completions are requested for a pipe.

[SichangHe]

It might work if Gleam adds a Lua backend. Lua is simple to generate and simple to embed. Fennel is a Lisp that compiles to Lua, for example.

[bhankas]

Gleam compiler is very nicely abstracted for compiling to dynamically typed languages. There's already glistix showcasing what is possible. If I knew any Rust (or Lua for that matter), I'd have tried making Glua or something like that, but alas.