Heck, what’s the catch? I need to try it and find out.
First of all, the install instructions are implicit (you just have to notice mention of CMake and then know how to use it), second, the dependencies are left as guesses so that I finally gave up trying to infer them and build the latest release without failure.
I hope to try again next time I see mention of it, but for casual evaluation, it’s not very friendly.
I managed to build and run it.
So, the catch for me is that there’s no GC. As far as I can tell, any dynamic allocation is handled manually, either by resetting the context/heaps as an embedder, or by unsafely calling new/delete in daScript code.
This is alluded to with “semi-manual memory management”, but I didn’t think it would be that primitive.
So yeah, no wonder it can be faster than languages with actual automatic memory management. It doesn’t seem useful as a standalone language to me. I already have Zig when I want to go fast manually, and it can do the reset trick as well with arena allocators.
git submodule update --init
cmake -GNinja -S. -Bout/release -DCMAKE_BUILD_TYPE=Release
ninja -C out/release # failed
It seems that modules/dasLLVM/CMakeLists.txt uses a strange way to load LLVM’s C library (the author mistook it as libclang). Perhaps ln -s /usr/lib/llvm-14 libclang should work.
ln -s /usr/lib/llvm-14 libclang
However, I then got
% ninja -C out/release
ninja: Entering directory `out/release'
ninja: error: '/tmp/p/daScript/modules/dasGlfw/glfw/lib/libglfw3.a', needed by '/tmp/p/daScript/bin/daScript', missing and no known rule to make it
I will investigate it more.