2 ms·

Rust wasn't made to replace C, C is to be there at low level and as a glue code for everything. Rust was made to replace C++ because the language it's a behemo

by anthk 1mo ago

Rust wasn't made to replace C, C is to be there at low level and as a glue code for everything. Rust was made to replace C++ because the language it's a behemoth, it tries to do everything and the syntax it's a Lovecraftan nightmare, full of legacy incompatibilities. For small games such as Cataclysm:DDA I'd use Go (and for system tools and internet services OFC) and for game engines Rust it's or even GC based languages (not Java) can do it well (C# with AOT). Even Common Lisp it's fine (just look up Trial/Kandria) with SDL2/3 and/or OpenGL bindings (Vulkan ones should be somewhere). Pick SBCL for speed, learn CL, learn about SIMD and optimizations. It can beat C on performance. https://www.stylewarning.com/posts/nbody/ https://www.stylewarning.com/posts/nbody/ EDIT: the bindings are cl-vulkan, of course.

xnorswap 1mo ago
There are times that JIT'd C# out-performs AOT C#, so I'd avoid defaulting to recommending AOT. Assuming that AOT is faster is the same trap that C advocates fall into when thinking that other languages can only ever equal C on speed.
- Paul_Clayton 1mo ago
  If a language can produce the same machine code (including dynamic patching) as a second language, that second language can at best only equal the runtime characteristics of the first. The development and maintenance costs can be very different. I am not certain if C (apart from inline assembly) can generate all possible machine code, and some translations can be fragile (autovectorization, e.g.).
  - xnorswap 1mo ago
    Well indeed, which is why I don't really like talking about the "speed" of a language at all. What really matters is the characteristics of the idiomatic usage.
    - Paul_Clayton 1mo ago
      I would guess that rate of benefit relative to divergence from idiomatic purity might also be significant. If a little clutter gains a 50% improvement with language A but only a 10% improvement with language B, language B having a 15% advantage under idiomatic expression may not be that significant. But, yes, terms like "the speed of C" do not seem especially useful. Even "equal effort" ignores the complexity of the effort-to-benefit function as well as maintainability issues and other considerations like finding good programmers who want to use the language. Reality seems to be very complex.

by anthk 1mo ago

xnorswap 1mo ago

There are times that JIT'd C# out-performs AOT C#, so I'd avoid defaulting to recommending AOT. Assuming that AOT is faster is the same trap that C advocates fall into when thinking that other languages can only ever equal C on speed.

Paul_Clayton 1mo ago
If a language can produce the same machine code (including dynamic patching) as a second language, that second language can at best only equal the runtime characteristics of the first. The development and maintenance costs can be very different. I am not certain if C (apart from inline assembly) can generate all possible machine code, and some translations can be fragile (autovectorization, e.g.).
- xnorswap 1mo ago
  Well indeed, which is why I don't really like talking about the "speed" of a language at all. What really matters is the characteristics of the idiomatic usage.
  - Paul_Clayton 1mo ago
    I would guess that rate of benefit relative to divergence from idiomatic purity might also be significant. If a little clutter gains a 50% improvement with language A but only a 10% improvement with language B, language B having a 15% advantage under idiomatic expression may not be that significant. But, yes, terms like "the speed of C" do not seem especially useful. Even "equal effort" ignores the complexity of the effort-to-benefit function as well as maintainability issues and other considerations like finding good programmers who want to use the language. Reality seems to be very complex.