I'm not the OP, but I'll explain why I personally avoid core.async and what I do to get features that are roughly equivalent to async/await today.
My first issue with core.async is that you have to be very careful on the producer-side to handle exceptions properly. If you drop an exception, at best you'll get a stack-trace dumped to the console that often won't have a single line that traces back to your code. Instead, you'll get a pile of generated library code that you have no experience with. I ran into this when JSON.parse throws an exception inside cljs-http, which in my opinion is just the kind of run-of-the-mill exception that should be easy to debug (but isn't). The second issue is that there are still a number of bugs with core.async surrounding exception handling. As I was trying to fix the above issues, I ran into one of them. https://dev.clojure.org/jira/browse/ASYNC-73 In short, my basic problem with core.async is that it adds a lot of complexity (and size) to your code, which I'd rather avoid if there are better alternatives. The three non-callback ways of dealing with async code in javascript are (1) promises, (2) generators, (3) async/await. The first two are es6. The last is es-2017. Because these are now built into the language and are widely relied upon, the tooling support (e.g. browser and node) are excellent and all the corner cases have been worked out. Async/await is sugar that you put on top of generators. The feel of async/await is exactly like go-blocks, where "async" is "go" and "await" is "<!". Both allow you to write code that looks synchronous but is actually event-driven. Neither can cross function boundaries. And I believe the underlying implementation is roughly the same idea: chop the synchronous bits up into chunks, turn the transitions into a state machine, and then keep track of where you are. Check out this generator transpiler: http://facebook.github.io/regenerator/ So far, though, I've found that async/await is mostly useful in javascript because of the fact that you have side-effecting statements and complex syntax where it is convenient to be able to throw an "await" without refactoring your code. In clojurescript, you tend to write code in a non-side-effecting expressions, so I don't find that I need something that general. For simple things, I find that just relying on plain promises (using the promesa library) is enough. You can do this: (-> (promise-returning-call) (then (fn [response] ...)) (catch (fn [error] ...))) This is simple, it is very close to the host language, and there are no corner cases that I know of to surprise you. Sometimes you need to thread the results of an earlier async call to later calls, which can be clumsy. I think async/await was largely driven by solving this problem, but I don't think you really need that generality in this language. I have found that as long as you write "clojurescripty" code, the alet macro from the promesa library is all you need. (alet [a (get-a) b (get-b a) c (get-c a b)] (do-something c)) Setting all that aside, the clear advantage of being able to target async/await (or maybe just generators) is that you get the native implementation and don't have to do all of this code manipulation in user space. The tooling is going to be better, the code will be smaller, and the edge cases are going to be handled. Maybe you could even write a core.async fork without all of the IOC helpers (i.e. just translate directly to async/await). By the way, I hope I'm not coming off as being critical of the core.async authors. This stuff is very hard to get right and not everyone is going to have the same design requirements. On Thu, May 24, 2018 at 6:25 AM Nikita Dudnik <[email protected]> wrote: > Sorry for answering with a question but I have to second Andrew. What's > wrong with core.async and more importantly how'd you implement async/await > in clojurescript in terms of syntax? > > - > Nik > > > On Thursday, May 24, 2018 at 6:44:06 AM UTC+2, Philos Kim wrote: >> >> I wonder when the async/await feature in ES8 will be introduced in >> ClojureScript. >> >> Of course, I know there is core.async in ClojureScript but I hope that >> the async/await feature in ES8 will be supported in ClojureScript as soon >> as possible. >> >> Does anyone know when it will be supported? >> > -- > Note that posts from new members are moderated - please be patient with > your first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/clojurescript. > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/clojurescript.
