On the game engine side, probably not a lot until there's more ecosystem built up, but across the board you could look at the niches filled by the Java/Groovy and C/Lua pairings to get a pretty good sense of what's possible— it would be the tools stuff that would most excite me: build/CI/automation frameworks, that kind of thing.
Alternatively, look at a project like ruff— hundreds of linter rules statically implemented in native Rust [1], maybe that would make more sense if the rules could be more tersely expressed as runtime-loadable roto scripts that have access to the Python AST and a toolkit of Rust-supplied functions for manipulating and inspecting it?
In the Java/Groovy space, Jenkins and Gradle are the obvious ones.
I'm less familiar with the Lua world (not a gamedev), but this is an example of the kind of thing I'm imagining— a build system / task runner that's half lua and half C/C++: https://github.com/xmake-io
Having a modern on-prem replacement for Jenkins/Rundeck built in rust and exposing a roto interface rather than yaml definitions sounds like it would be great.
- The best package manager in the world, bar none. Compiling, linking, and platform difficulties disappear. The devops/devexp is next-level sublime.
- "low defect" software without much work. I'm not talking about memory management, but rather Option<T> and Result<T,E>. For the same amount of effort as writing Golang or Java or C#, you can get defect free code.
- Easy deployable to WASM without packaging a memory management runtime for the most intrusive types. Super portable, super fast.
- If you've used Unreal a lot, you've hit build issues, linker issues, segfault issues. A lot. That'll go away.
> The best package manager in the world, bar none. Compiling, linking, and platform difficulties disappear. The devops/devexp is next-level sublime.
I don’t know how are universes split but I’m in the wrong one for sure!
300Gb compile caches, 5 minute compilation, nix flakes with layer and careful adjustments for different arch and deployments, cargo slowing builds by 5 minutes every time because it insist on downloading full repo every time (and occasionally failing). API libraries maintained by some completely anonymous guy or lad from eastern country.
On top of it the bugs don’t get away. If your problem IS memory safety, then sure - chomp away. But I’ve seen u64 truncated to u32 because someone decided to thread it through JSON serialization and macro soup.
Java 8 was released in 2014, since then Optional is in the standard library and a rather common pattern. Like Rust you can use LLVM to compile Java to WASM (JWebAssembly), and there's also TeaVM for turning a project into an optimised WASM application and CheerpJ for running a JVM in WASM.
It was rather messy to use cargo on handheld ARM, it didn't spark joy so I kind of stopped trying after a while. Mostly I use Rust as a dependency I don't need to touch, but when I've programmed in it I didn't feel like cargo was that big of a thing. Maybe I would feel another way if the frame of reference was only like webpack or Pip or something.
It’s also a pleasant language to work in. I love that everything is an expression, I love match statements, I love that structs and enums are full powered, etc.
On the game engine side, probably not a lot until there's more ecosystem built up, but across the board you could look at the niches filled by the Java/Groovy and C/Lua pairings to get a pretty good sense of what's possible— it would be the tools stuff that would most excite me: build/CI/automation frameworks, that kind of thing.
Alternatively, look at a project like ruff— hundreds of linter rules statically implemented in native Rust [1], maybe that would make more sense if the rules could be more tersely expressed as runtime-loadable roto scripts that have access to the Python AST and a toolkit of Rust-supplied functions for manipulating and inspecting it?
[1]: https://github.com/astral-sh/ruff/tree/main/crates/ruff_lint...
So no clear examples?
In the Java/Groovy space, Jenkins and Gradle are the obvious ones.
I'm less familiar with the Lua world (not a gamedev), but this is an example of the kind of thing I'm imagining— a build system / task runner that's half lua and half C/C++: https://github.com/xmake-io
Having a modern on-prem replacement for Jenkins/Rundeck built in rust and exposing a roto interface rather than yaml definitions sounds like it would be great.
2 replies →
- The best package manager in the world, bar none. Compiling, linking, and platform difficulties disappear. The devops/devexp is next-level sublime.
- "low defect" software without much work. I'm not talking about memory management, but rather Option<T> and Result<T,E>. For the same amount of effort as writing Golang or Java or C#, you can get defect free code.
- Easy deployable to WASM without packaging a memory management runtime for the most intrusive types. Super portable, super fast.
- If you've used Unreal a lot, you've hit build issues, linker issues, segfault issues. A lot. That'll go away.
> The best package manager in the world, bar none. Compiling, linking, and platform difficulties disappear. The devops/devexp is next-level sublime.
I don’t know how are universes split but I’m in the wrong one for sure!
300Gb compile caches, 5 minute compilation, nix flakes with layer and careful adjustments for different arch and deployments, cargo slowing builds by 5 minutes every time because it insist on downloading full repo every time (and occasionally failing). API libraries maintained by some completely anonymous guy or lad from eastern country.
On top of it the bugs don’t get away. If your problem IS memory safety, then sure - chomp away. But I’ve seen u64 truncated to u32 because someone decided to thread it through JSON serialization and macro soup.
Every bear looks like a puppy when it’s a cub.
Java 8 was released in 2014, since then Optional is in the standard library and a rather common pattern. Like Rust you can use LLVM to compile Java to WASM (JWebAssembly), and there's also TeaVM for turning a project into an optimised WASM application and CheerpJ for running a JVM in WASM.
It was rather messy to use cargo on handheld ARM, it didn't spark joy so I kind of stopped trying after a while. Mostly I use Rust as a dependency I don't need to touch, but when I've programmed in it I didn't feel like cargo was that big of a thing. Maybe I would feel another way if the frame of reference was only like webpack or Pip or something.
It’s also a pleasant language to work in. I love that everything is an expression, I love match statements, I love that structs and enums are full powered, etc.
> It’s also a pleasant language to work in
I know, practically self-documenting code!
https://github.com/tokio-rs/tokio/blob/tokio-1.45.0/examples...
I'm not trying to pick on tokio, it was just a public link demonstrating that the syntax can get to be a bit much
1 reply →