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.
Interesing idea. I am wondering what are the use cases on top of your head? I am asking because in my understanding people who care concurrency and parallelism are often those who care performance.
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.
death_eternal|6 months ago
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:
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:
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.
ljchen|6 months ago
death_eternal|6 months ago
renox|6 months ago