Hacker News Reader

Comment by Fiahil | Hacker News Reader

The article is also conflating synchronous single-threaded, synchronous multi-threaded and asynchronous programming.

Each have their own usage, and no, a multi-threaded program is not the same as an asynchronous one. For example, using threads and channels instead of async/await is not a design flaw if your workload is mostly about large, blocking computations on a read-only shared state with no I/O. In that situation, lifetime and closures will not pose any issue and won't get in the way because you're not mutating anything and communicate with owned messages.

The async ecosystem is evolving and will be better tomorrow than it is today. Saying that Rust programming as a whole is a mess because async/await is harder to use than necessary, is short-sighted. It's like saying you don't like apples, but you only chewed on the branch of the tree.

View on HN

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.

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.

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

Reply on news.ycombinator.com