death_eternal

You're clearly wrong.

Yeah, you're not really that interesting to be honest.

You can look at the repository to see the differences. The troubleshooting abilities of the program are far superior to lutris already, My experience with lutris is you run the install script, attempt to run the game, it doesnt work and fails silently, the logs are empty, and even if you do capture the logs, the core issue often isn't clear.

Very.

1. It manages memory through deterministic ownership rules and optional arena allocation. Pointers never outlive the allocator that created them, and the compiler performs lifetime checks to prevent use-after-free or double-free errors.

2. Axe does not use C++-style RAII. It employs deterministic cleanup through defer, which allows resources to be released predictably. Also, objects allocated inside an arena are freed as a group when the corresponding arena is destroyed.

3. Not yet. There is an overload system currently:

  overload println(x: generic) {
      string => print_str;
      char*  => println_chrptr;
      i32    => println_i32;
      char   => println_char;
  }(x);

The goal is to not need to write C just to get performant code, especially for things like concurrency and numerics. While Nim can be fast without `ref object`, and you can guide the compiler to autovectorize in some cases, it often requires deep knowledge of both the compiler and backend behaviour. That’s not a good developer experience for many users.

Multithreading in Nim is bad to say the least and has been for a while. The standard library option for multithreading is deprecated, and most alternatives like weave are either unmaintained or insanely limited (taskpools, malebolgia, etc.). There's no straightforward, idiomatic way to write data-parallel or task-parallel code in Nim today.

The idea of the project is to make shared-memory parallelism as simple as writing a `parallel:` block, without macros or unsafe hacks, and with synchronization handled automatically by the compiler.

Course, performance can be dragged out of Nim with effort, but there's a need for a language where fast, concurrent, GC-optional code is the default, not something one has to wrestle into existence.

Like I said, the use case is heavy numerical workloads with, e.g. dataframes, in a context where the data is too big for something like python to handle. Using Nim for this is quite difficult too due to value unboxing overhead. It is easier to optimize for things like cache locality and avoid unnecessary allocations using this tool.

Repo: https://github.com/navid-m/scar

Because of the relatively poor state of multithreading in Nim and the reliance on external libraries like Arraymancer for heavy numerical workloads (also the performance issues with boxed values due to `ref object` everywhere), I started writing a language from scratch, with built-in support for concurrency via parallel blocks (without macros) and a C backend, similar to Nim.

GC is optional and the stdlib will work with or without the GC.

Example:

    int glob_value = 0
    float glob_value_2 = 0.0

    parallel:
        glob_value = some_heavy_task()
        glob_value_2 = some_other_heavy_task()

The idea is to make things like accessing shared memory concurrently a trivial process by automating the generation of thread synchronization code.

Also there are parallel fors, like so:

    parallel for x = 1 to 5:
        print "x = %d" | x
        parallel for y = 10 to 20:
            print "y = %d" | y
        sleep 0.1

    print "Nested parallel for loop completed."

It is not ready for use at all currently, though will likely see further development until it is.

Compiler implemented in Go, originally with Participle, recursive-descent approach. All examples in the examples directory compile.