Nim or Rust?

Started by
5 comments, last by swiftcoder 6 years ago
The Nim's readme say "its a compiled, garbage-collected systems programming language which has an excellent productivity/performance ratio. Nim's design focuses on efficiency, expressiveness, elegance (in the order of priority)." Nim include features like a deterministic soft real-time GC that allows for its max pause time and supports manual memory management. Other features, compile to C (C++, Objective C, or JavaScript), strongly statically typed, powerful meta-programming, compile-time execution, easy to read (Python like syntax), and local type inference. It is multi-paradigm supporting,  imperative, minimal object-oriented (encouraging composition over inheritance), functional procedural styles. Some tools like a package manager (nimble), C2nim (C and C++ bindings), and Nimsuggest. Also these a game development framework and are two cons are the bus factor and not release yet.

Rust's website say " is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety." Features include, CFFI, immutability, robust meta-programming, RAII, modern type system, strongly statically typed, compiles to native code,  safe rust by default (you can unsafe too), immutability, fine grained control over memory, and modules. It is multi-paradigm supporting, concurrent, functional, imperative, structured, and generic procedural styles. Some tools like Cargo (a package manager), RLS (Rust Language Server), rustfmt (formating), clippy (lints), and rust-bindgen (Automatically generate C or C++ bindings). Coming features are generators/async/await, SIMD, custom allocators, and compiles to WASM. Also verysus resources and strong game dev community.

I took two intro programming courses well in school ( JavaScript & Python).  Both are memory safe and can do low-level programming and between Nim or Rust which one is more susceptible for game development?

Thank you for the advice. :)

 
Advertisement

Both are questionable choices for someone relatively new to game development simply because they aren't widely in use for gamedev, and there are many fewer gamedev resources available for either, than there are for C++, C#, or even Python and Javascript.

Specifically for Rust, I can tell you that the game development ecosystem is not terribly stable at this point in time. The language is still undergoing significant changes, and the various 3D rendering libraries are also undergoing rapid churn.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

19 hours ago, swiftcoder said:

Specifically for Rust, I can tell you that the game development ecosystem is not terribly stable at this point in time. The language is still undergoing significant changes, and the various 3D rendering libraries are also undergoing rapid churn.

As far as I can tell Rust the language is stable and rang 1.0 over 2.9 years and guarantees stability. (here to) Yes, the game dev is undergoing rapid churn but that is to be expected. Out of both Rust is the most documentation and resources. See here and here. It even two commercial games (here and here).

Quote

Both are questionable choices for someone relatively new to game development simply because they aren't widely in use for gamedev, and there are many fewer gamedev resources available for either, than there are for C++, C#, or even Python and Javascript.

I agree but I'm while to do it. :)

Nim (formerly Nimrod) is undergoing significant changes and the beginner documentation don't exist at all. The manual and documentation be are out of date but there are some resources. :(  Nim interoperability with C/C++ is very good. :)

Thank you for the comments. :)

6 minutes ago, loik_1 said:

As far as I can tell Rust the language is stable and rang 1.0 over 2.9 years and guarantees stability

That's a subtly different definition of stability than I had in mind. They are guaranteeing that existing code will continue to compile (mostly), but not that it will continue to be idiomatic or compatible with new ways of doing things.

As a specific example, the entire situation with respect to network I/O has churned in the past year (with the introduction of futures), and it's about to churn again when async/await lands.

The gamedev front is even less stable (again, in the churn sense). gfx-rs is somewhere in the middle of a ground-up rewrite to become a Vulkan abstraction layer. You can still use the pre-ll branch, but it's not under active development. glium is deprecated, although it's usable for simple stuff as is.

That basically leaves you with the option of writing directly on top of the raw C APIs for OpenGL/Metal/DX12/Vulkan... Which certainly works, but isn't really that helpful in learning how to do things the Rust Way™, and is generally anywhere from somewhat to lot more painful than using each API in it's more-native language (i.e. C++ or Swift).

26 minutes ago, loik_1 said:

It even two commercial games (here and here).

Note that the first one of those is an experienced gamedev team writing significant parts of their game in C++. if you fancy learning C++ and Rust in parallel, more power to you!

I don't have any aim to discourage you, by the way, as I find Rust quite interesting to develop in. But I do want to convey that it continues to be an uphill battle to produce game-like things in this environment (and that's with the benefit of a decade or so of C++, OpenGL, and god knows what else under my belt).

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

5 hours ago, swiftcoder said:

Note that the first one of those is an experienced gamedev team writing significant parts of their game in C++. if you fancy learning C++ and Rust in parallel, more power to you!

God no! :) I do not won't too learning C++. ;) I thought Chucklefish is righting it all in Rust except the UI and some other stuffs?

Quote

I don't have any aim to discourage you, by the way, as I find Rust quite interesting to develop in. But I do want to convey that it continues to be an uphill battle to produce game-like things in this environment (and that's with the benefit of a decade or so of C++, OpenGL, and god knows what else under my belt).

You are not discourage. In Nightly Rust there is a feature called non-lexical lifetimes should help.;)

Quote

That's a subtly different definition of stability than I had in mind. They are guaranteeing that existing code will continue to compile (mostly), but not that it will continue to be idiomatic or compatible with new ways of doing things.

As a specific example, the entire situation with respect to network I/O has churned in the past year (with the introduction of futures), and it's about to churn again when async/await lands.

The gamedev front is even less stable (again, in the churn sense). gfx-rs is somewhere in the middle of a ground-up rewrite to become a Vulkan abstraction layer. You can still use the pre-ll branch, but it's not under active development. glium is deprecated, although it's usable for simple stuff as is.

That basically leaves you with the option of writing directly on top of the raw C APIs for OpenGL/Metal/DX12/Vulkan... Which certainly works, but isn't really that helpful in learning how to do things the Rust Way™, and is generally anywhere from somewhat to lot more painful than using each API in it's more-native language (i.e. C++ or Swift).

I see. Have you seed tomaka's vulkano, or arewegameyet.com, or awesome-rust?
 

 

1 hour ago, loik_1 said:
I see. Have you seen tomaka's vulkano, or arewegameyet.com, or awesome-rust?

I have. There are certainly a lot of fragmented pieces of game development software in rust.

Vulkano isn't useful to me personally as I need to target platforms without Vulkan support.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

This topic is closed to new replies.

Advertisement