There is a module in gamelib [0] which will automatically clone, build, and link raylib to your program. There are several other third party libs there as well, including SDL2 and Curl.
I have a Surface Pro 2 running with the linux-surface kernel [0]. It feels like it has some rough edges - you have to decide between having pen support or having touch screen support, and suspend can be unreliable. These issues may be fixed now. Also, I encrypted my Windows partition, and now it requires the key each time to boot up, so I recommend against doing that.
Overall, I do agree that the hardware feels quite nice, and besides those issues I listed, the Linux experience is quite good. I was very happy to not be forced to use Windows.
I'm not sure why you say it's a "quite safe" assumption that most games are written in C#. Unity's beginner-friendliness gives it a disproportionate presence online, while the vast majority of AAA games are still solidly C++.
If we eliminate all games with less than 1000 sales or something, I think it would be a very low confidence estimate.
Yes, they are compiled just like the final exe, only they become dynamic libraries that I load with libdl. On subsequent builds, they are loaded again, unless the macro changed.
While I can't speak for any experimental new garbage collectors, I did analyze the SBCL generational GC's implementation. I encourage anyone interested in performance to look over GC code and realize how much work they are doing.
That GC in particular has to stop the world, traverse the entire fresh heap, guesses whether something is even a pointer (and can guess wrong, causing a memory leak!), and does all this at arbitrary times, unless you do non-idiomatic things like manage your own memory in preallocated arrays, or use C/asm-powered memory mapped buffers [0].
Nothing comes for free, and some domains can't pay the price for GC (and choose to spend those resources elsewhere). Games, in my opinion, are largely still in that category.
The big distinction to me is that there is a final executable that eventually gets created, whereas Lisp programs can continue to generate code and self-modify at runtime.
Cakelisp differs from Zig in that arbitrary code modification is supported, which is a step closer to the modifiable environment of Lisps. Very few languages besides lisp allow you to do things like "iterate over every function defined and change their bodies, and create a new function which calls them". Zig does not support that. It's extremely useful for some tasks (e.g. hot-reloading code modification, mentioned in the article)
Jai isn't out yet, but I was inspired by many of the comptime ideas.
I agree. Templates make some tasks easy (type specialization and generic containers) but become tangled messes with other tasks (function bindings, serialization).
I used something similar to your technique for compile-time variable destruction. The compiler doesn't know the type, so a macro generates a callback which deletes a casted version. These callbacks are named with the type so they can be lazily added and reused.
Carp requires writing bindings to call C functions or use types. Additionally, code modification isn't possible in Carp.
When I say seamless, I'm going for as close as possible, I.e. it should feel even easier to use C from Cakelisp than from C itself. The build system especially makes this possible.
I do wish the C compiler was as fast as e.g. SBCL's compiler in terms of compile time, because multiple rounds of dependent macro compilation eats up a lot of time.
I think Lisps tend to optimize for throughput, but games have very strict latency requirements. Garbage collection pauses could cause frame pacing issues (not that C solves that completely, but it is at least not a built in disadvantage of idiomatic use of the language)
Thanks! It is a bit different, and does require more typing, but I like how unambiguous it is. It also simplifies code modification by making type parsing and changing easier, because you can recursively unwrap multiple pointers, or pointer-ify things easily.