What's the difference between it and Common Lisp? Isn't Common Lisp also AOT compiled?
Carp – A statically typed Lisp, without a GC, for real-time applications
21–30 of 139 posts
Re: Carp – A statically typed Lisp, without a GC, for real-time applications
#22Earlier quoted context omitted.
I have not used carp, and janet only briefly. However, other than both using lisp syntax, there are very little similarities between the two. Janet has a garbage collector, no static types, no ownership tracking - the perf. is similar to lua, so is not be ideal for low-level/realtime systems, which carp is targeting.
> the perf. is similar to lua, so is not be ideal for low-level/realtime systems Lua runs on a bunch of low level systems, and not just for hobbyists (it's at the core of VxWorks, for example). Can you expand on why you think the language doesn't meet your performance criteria?
Re: Carp – A statically typed Lisp, without a GC, for real-time applications
#23Anyone who had used or tried Carp and Janet (that was on frontpage the other day)? What are some strong points on Carp vs. Janet?
Re: Carp – A statically typed Lisp, without a GC, for real-time applications
#24"Real-time" has a specific meaning in embedded and computing context. Does it mean that programs written in Carp have any guarantee on their order or duration of execution?
For "real-time", they would need a real-tune OS, datastructures with forward guarantees, non-blocking IO and so on. GC is like the least of the problems.
I think "forward guarantees" (meaning "lock-free"?) can be implemented anywhere. Non-blocking IO can still be slow in my experience, for example a write() syscall on Linux to a non-blocking TCP socket on Linux sometimes took dozens of milliseconds when I measured. I don't have enough experience to know if one can get better timing guarantees with tuning or newer kernels, but maybe it's not a huge issue in all cases.
After all, the OS is only at the outside layers of an application, so one might be able to process the OS I/O in separate threads and allocate sufficiently large buffers there.
GC however, in typical usage means that random internal codepaths could be interrupted by the GC doing OS interaction in places where it's really not affordable.
Re: Carp – A statically typed Lisp, without a GC, for real-time applications
#25Re: Carp – A statically typed Lisp, without a GC, for real-time applications
#26What's the difference between it and Common Lisp? Isn't Common Lisp also AOT compiled?
First of all, Common Lisp is a language with several implementations, some of which offer AOT compilation. Secondly, a garbage-collection (aka automatic memory management) does not exclude AOT.
Re: Carp – A statically typed Lisp, without a GC, for real-time applications
#27Re: Carp – A statically typed Lisp, without a GC, for real-time applications
#28Earlier quoted context omitted.
... or a hash table using RB/AVL trees rather than linked lists for hash buckets.
the doubling of the sizes is an issue. Yet, I'd consider all single threaded datastructures a non-issue. The hard part is multithreading. Flip note: java's hashmap uses red/black tree for nodes when there are too many collisions (and the keys are Comparable)
Re: Carp – A statically typed Lisp, without a GC, for real-time applications
#29Re: Carp – A statically typed Lisp, without a GC, for real-time applications
#30The name is strange. Reminds me of a product-naming story I heard years ago. Papenmeier from Germany was once planning to create a small notetaker with built-in braille display. They originally planned to name it "Braille Assistant", but the US distributors objected on the ground that they can already see users shortening the product name to "Braille Ass". I have a similar feeling with Carp, isn't the obvious transpo…