First, I don’t mean to criticize anything or anyone. People value such things subjectively, but for me the async/sync split does no good.

Goroutines feel like old-school, threaded code to me. I spawn a goroutine and interact with other “threads” through well defined IPC. I can’t tell if I’m spawning a green thread or a “real” system thread.

C#’s async/await is different IMO and I prefer the other model. I think the async-concept gets overused (at my workplace at least).

If you know Haskell, I would compare it to overuse of laziness, when strictness would likely use fewer resources and be much easier to reason about. I see many of the same problems/bugs with async/await..

▲

thomasahle 2 days ago | parent | next [-]

Comparing to Haskell, I think of "async" as the IO monad. It's nice to have all code that does IO flagged explicitly as such.

▲

raxxorraxor 2 days ago | parent | prev | next [-]

> I think the async-concept gets overused (at my workplace at least).

Problem is it that it self reinforces and before you look every little function is suddenly async.

The irony is that it is used where you want to write in a synchronous style...

	▲	carlmr 2 days ago \| parent [-]
		Yep, this is my biggest gripe with explicit async, all of a sudden a library that needn't be async forces me to use async (and in Rust forces me to use their async implementation), just because the author felt like async is a nice thing to try out.

▲

eddd-ddde 2 days ago | parent | prev | next [-]

Wouldn't the old school style be more like rust async? Simple structs that you poll whenever you need to explicitly. No magic code that looks synchronous but isn't.

▲

tptacek 2 days ago | parent [-]

No, Rust async is new-school colored-functions concurrency.

▲

pkolaczk 2 days ago | parent [-]

The parent comment is right. Rust async is simple state automata structs you can poll explicitly with no magic. Async/await is just some syntactic sugar on top of that, but you don’t have to use it.

An obvious advantage of doing it that way is you don’t need any runtime/OS-level support. Eg your runtime doesn’t need to even have a concept of threads. It works on bare metal embedded.

Another advantage is that it’s fully cooperative model. No magic preemption. You control the points where the switch can happen, there is no magic stuff suddenly running in background and messing up the state.

	▲	jpc0 2 days ago \| parent \| next [-]
		Have you actually tried to implement async in rust from the ground up. It is nothing like what you just described
	▲	tptacek 2 days ago \| parent \| prev [-]
		I didn't say it was good or bad. I said it's new-school colored functions.

▲

sfn42 2 days ago | parent | prev [-]

I always find it strange how people complain about features when the real problem is that they simply don't like how people use the feature.

Async in C# is awesome, and there's nothing stopping you from writing sync code where appropriate or using threads if you want proper multi threading. Async is primarily used to avoid blocking for non-cpu-bound work, like waiting for API/db/filesystem etc. If you use it everywhere then it's used everywhere, if you don't then it isn't. For a lot of apps it makes sense to use it a lot, like in web apis that do lots of db calls and such. This incurs some overhead but it has the benefit of avoiding blocked threads so that no threads sit idle waiting for I/O.

You can imagine in a web API receiving a large number of requests per second there's a lot of this waiting going on and if threads were idle waiting for responses you wouldn't be able to handle nearly as much throughout.