2 ms·

I don't disagree about the convenience of having the Go runtime handle this automatically for you. I do wish core.async could as well. That said, all your prio

I don't disagree about the convenience of having the Go runtime handle this automatically for you. I do wish core.async could as well. That said, all your prior comments seem misleading, at least they confused me because it sounded like you were implying something that didn't feel accurate. Core.async has lightweight processes. The core.async Go macro can yield to other Go blocks and it will be really cheap to do so. You can have hundreds of thousands of them concurrently parked and cooperatively switching between each other, etc. In effect, it means that you can achieve the same scale of concurrency in Clojure as you can in Go. Yes, it will be trickier in Clojure, because you have to manage the async IO on your own, and you have to delegate an OS thread on your own when blocking IO is needed. In ClojureScript it won't be as much an issue since all IO is async, but still not as nice as auto-yielding by the runtime under the hood as Go does.

armitron 6y ago
core.async doesn't have lightweight processes, for any sane definition of these terms. A code transformation spat out by a macro, subject to all the serious drawbacks I've already mentioned, is not a lightweight process. But looking at the number of downvotes I've received, stating the obvious no less, I think I'll stop here. I will however take the completely nonsensical, misleading and downright erroneous responses illustrated in this thread as signaling me to steer well clear of Clojure and its community. Let's not forget that this thread started with someone claiming core.async is better than Go's goroutines.
- didibus 6y ago
  > But given the number of downvotes I've received here If I were to guess, I'd say it's because your comments feel like they come from a place of bad faith. I'll give you the benefit of the doubt here. > core.async doesn't have lightweight processes, for any sane definition of these terms We can argue semantics if you want, but that leads to nothing constructive. I understand very well that the underlying implementation is different. Core.async is a very clever code rewriting machinery. Go actually has a user level thread implementation, with each Go block its own stack, and the Go runtime schedules those over real OS threads. I know all that. The implementation doesn't matter for what I'm saying though. At the end of the day, it means you can pause and resume multiple logical code blocks and cooperatively alternate between which one is given another chunk of CPU time. All while keeping memory footprint low, and with very fast context switches. Thus you can achieve a similar scale of concurrency, and even though they achieve this with a different implementation, Go and Clojure both achieve the same end result. While I totally acknowledge as well that the implementation Go uses allows for a more ergonomic programmer experience.

armitron 6y ago

core.async doesn't have lightweight processes, for any sane definition of these terms. A code transformation spat out by a macro, subject to all the serious drawbacks I've already mentioned, is not a lightweight process. But looking at the number of downvotes I've received, stating the obvious no less, I think I'll stop here. I will however take the completely nonsensical, misleading and downright erroneous responses illustrated in this thread as signaling me to steer well clear of Clojure and its community. Let's not forget that this thread started with someone claiming core.async is better than Go's goroutines.

didibus 6y ago
> But given the number of downvotes I've received here If I were to guess, I'd say it's because your comments feel like they come from a place of bad faith. I'll give you the benefit of the doubt here. > core.async doesn't have lightweight processes, for any sane definition of these terms We can argue semantics if you want, but that leads to nothing constructive. I understand very well that the underlying implementation is different. Core.async is a very clever code rewriting machinery. Go actually has a user level thread implementation, with each Go block its own stack, and the Go runtime schedules those over real OS threads. I know all that. The implementation doesn't matter for what I'm saying though. At the end of the day, it means you can pause and resume multiple logical code blocks and cooperatively alternate between which one is given another chunk of CPU time. All while keeping memory footprint low, and with very fast context switches. Thus you can achieve a similar scale of concurrency, and even though they achieve this with a different implementation, Go and Clojure both achieve the same end result. While I totally acknowledge as well that the implementation Go uses allows for a more ergonomic programmer experience.