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.
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.
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.
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
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/deletein 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.
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 libclangshould work.However, I then got
I will investigate it more.