Live data from Hacker News

Carp – A statically typed Lisp, without a GC, for real-time applications

github.com

21–30 of 139 posts

Re: Carp – A statically typed Lisp, without a GC, for real-time applications

#21

What'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

#22
post #6
post #4

Earlier 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?

I think this is LuaJIT, or? Iiuc Janet is comparable to non-JITed Lua. But I actually have no clue.

Re: Carp – A statically typed Lisp, without a GC, for real-time applications

#23

Anyone who had used or tried Carp and Janet (that was on frontpage the other day)? What are some strong points on Carp vs. Janet?

Last time I checked, Carp doesn't have a REPL that can interact with a running process. In Janet you can do things like change functions during runtime.

Re: Carp – A statically typed Lisp, without a GC, for real-time applications

#24
post #11

"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.

Not an expert at all here, just a few thoughts and experiences.

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

#26
post #21

What'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.

See also the Boehm GC, a garbage collector for C and C++.

https://en.wikipedia.org/wiki/Boehm_garbage_collector

Re: Carp – A statically typed Lisp, without a GC, for real-time applications

#27
The 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 transposition an issue? :-)

Re: Carp – A statically typed Lisp, without a GC, for real-time applications

#28
post #16
post #15

Earlier 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)

but java's hashmap still resizes when breaching the loadfactor. so any similar implementation, even for singlethreaded cases can't achieve (soft)realtime. I am not aware of any linear hashing or similar approach for in memory hash tables to mitigate such latency spikes.

Re: Carp – A statically typed Lisp, without a GC, for real-time applications

#30
post #27

The 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…

Doesn't seem to happen to the Common Address Redundancy Protocol too much.
Post reply on HN