Hacker News Reader

Comment by convolvatron | Hacker News Reader

its really strange that there are two languages running around together. one which is very opinionated in how to manage memory in a stack discipline and another which just uses reference counts.

they don't quite mix. so you need to be aware of which one you're (implicitly using), and you may need library functions for both colors.

you have to admit this adds some additional mental overhead. but what got me when trying to understand the language was just that there _was_ such a division. I actually tried to apply the lifetime model to asynch objects.

View on HN

> its really strange that there are two languages running around together.

Mmh, I'm not sure I would agree with that. I've been using Arc & Rc for both async and non-async code, and even in single-threaded code. It's less about what flavor of concurrency you're using, than what program you're writing.

Arcs and references can coexist and are useful for different reasons. It would be a tragic loss for me if the language was (re-)adopting garbage collection or reference counting globally -even optionally. They are made to go along one another.

Edit: for example, tree-like or graph-like structures can use Arc and Weak [see arc documentation] in single-threaded code to enjoy reference-counted, cyclic, heap allocations in order to store a reference to a parent or sibling node.

You can do that with boxes, but Arcs have benefits if you want your code to work in a multithreaded environment.

my perspective is that everything I do is asynch and multithreaded. so the whole hierarchical allocation part of the language is largely useless to me.

once i figured that out, its really not so bad. but anytime a collaborator or a library tells me to use lifetimes I just get all churlish.

IME, using reference counts there is also not a good idea. In practice I think it's better to treat async tasks just like goroutines and then use channels to communicate.

I've found that when I've structured things that way in the past I do have some performance issues if the grain is very small.

more importantly to me is that those machines dont really compose that well over larger scales - that is to add a new component I need to look at the overall scheduling and connectedness of the existing components and need to rework them to order to handle a new control flow.

it is a nice model. i think it isn't appropriate for some things, so I tend not to reach for it by default.

By default I think the simplest model is to just use references, that should work if you don't move anything into the async task.

Reply on news.ycombinator.com