Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Carp, a compiled Lisp with type inference and a borrow checker

blog.veitheller.de

Post reply on HN
Print view View original

21–30 of 112 posts

Re: Carp, a compiled Lisp with type inference and a borrow checker

#21

Post by im_down_w_otp »

ams6110 wrote: post #16
banachtarski wrote: post #15

Earlier quoted context omitted.

I would argue the immutability is actually not a great thing in Erlang to be honest. It makes it hard to reason about what gets copied, what gets shared in the global heap which may be a source of contention, makes code unnecessarily verbose, etc. I think it's one of those features (like lazy evaluation in Haskell) that language practitioners tend to advocate without necessarily understanding what tradeoffs they are…

It actually makes reasoning easy. What gets copied: everything. What gets shared: nothing.

Except that isn't true in Erlang (or other BEAM languages). Binaries larger than some threshold are managed on a shared-heap. I think a couple other things have been promoted to being managed that way too fairly recently.

Re: Carp, a compiled Lisp with type inference and a borrow checker

#22

Post by nostrademons »

macintux wrote: post #12
sillysaurus3 wrote: post #11

I've been waiting for a non-Clojure lisp to make some headway. Immutability is mostly a fad: look at how incredibly complicated Clojure's implementation is. It's not worth sacrificing elegance just to attract the true believers.

Honest question: is immutability complicated in Clojure because it's hard, or because it's running in a virtual machine with no meaningful support for it? The Erlang VM has immutability deeply baked in, and it just works(™).

Erlang is typically used for problem domains (eg. fault-tolerant servers, network brokers & routers, message queues) where immutability fits the problem domain pretty well. If you want fault tolerance, you typically need to store all your state externally anyway so you can replicate it, and make all your logic stateless so you can restart & re-run it if a node fails.

There are some problem domains - eg. GUI software, web browsers, simulations, many of the more complicated parsing, data extraction, or graph-traversal algorithms - that are inherently mutable, and Erlang is not used very much in these domains. C++ still rules the roost there, even though many of its practitioners hate its shortcomings.

Re: Carp, a compiled Lisp with type inference and a borrow checker

#23

Post by hoosieree »

arximboldi wrote: post #9

I really want to like Carp but I somehow feel that the Rusty memory model does not fit the Lisp philosophy... all the borrowing story comes from a basis mutability. I wish for something more Clojurish based on immutable data. Then one can exploit the power of inferred type linearity/affinity to transparently build safe "transients" and other cool stuff. Maybe some day I should write such Lisp myself on top of my C++…

Your point is solid for most architectures. On embedded systems however, you nearly always need some sort of lifetime/ownership model. If using an RTOS, you have to play by its API rules. If bare-metal C/C++, you have to code it from scratch. But it's always there.

Compiler support for this pattern is a huge plus in my book.

Re: Carp, a compiled Lisp with type inference and a borrow checker

#24

Post by chubot »

slowmovintarget wrote: post #14
chubot wrote: post #10

Earlier quoted context omitted.

It sounds like arrays are mutable in Carp, so it doesn't feel like Clojure to me. As far as I understand, Clojure is also not big on macros, while Carp appears to be.

Aye, that's the one big disappointment. Maybe the first pet project is an implementation of Clojure's immutable collections.

I'm guessing it wouldn't be the same language then. Most languages are pretty tied to their own dataa structures, and that's especially true of Lisps because code is data. After all, Clojure is not Scheme.

You might be looking for C++ :-P As I mention here, it is impressive that you can actually implement these structures are libraries.

https://www.reddit.com/r/ProgrammingLanguages/comments/7cdz5...

Re: Carp, a compiled Lisp with type inference and a borrow checker

#25

Post by mark_l_watson »

thomastjeffery wrote: post #19

Since this is about a pre-alpha language, it would be helpful for future web searchers to have a date in the title.

Sorry to be a little off topic but I think search engines should penalize material that is not clearly marked with date of creation.

Re: Carp, a compiled Lisp with type inference and a borrow checker

#27

Post by s4vi0r »

sillysaurus3 wrote: post #11

I've been waiting for a non-Clojure lisp to make some headway. Immutability is mostly a fad: look at how incredibly complicated Clojure's implementation is. It's not worth sacrificing elegance just to attract the true believers.

Why/how is immutability a fad? Do you just mean in the context of LISPs? What elegance does having immutable by default data structures?

Re: Carp, a compiled Lisp with type inference and a borrow checker

#29

Post by Animats »

mark_l_watson wrote: post #25
thomastjeffery wrote: post #19

Since this is about a pre-alpha language, it would be helpful for future web searchers to have a date in the title.

Sorry to be a little off topic but I think search engines should penalize material that is not clearly marked with date of creation.

The cool kids only give a month and year, because what they have to say will be gone or irrelevant in a year.

Re: Carp, a compiled Lisp with type inference and a borrow checker

#30

Post by ramchip »

im_down_w_otp wrote: post #21
ams6110 wrote: post #16

Earlier quoted context omitted.

It actually makes reasoning easy. What gets copied: everything. What gets shared: nothing.

Except that isn't true in Erlang (or other BEAM languages). Binaries larger than some threshold are managed on a shared-heap. I think a couple other things have been promoted to being managed that way too fairly recently.

You might be thinking of the optimization for constant pool references: https://medium.com/@jlouis666/an-erlang-otp-20-0-optimizatio...
Post reply on HN