And this is exactly the point of the coroutines design. If you don’t use threading, coroutines, etc., just the classic code and you need to run one operation after another, then you do:
doSomething()
doSomethingElse()
If you use coroutines and you need to run one operation after another, then you do:
doSomething()
doSomethingElse()
How is this counter-intuitive and it would be more natural to use words like async/await to accomplish the same kind of behavior?
I see it exactly the opposite to you. From your description (I don’t know Swift), Swift focuses on what is happening inside the function, focuses on its implementation details, we need to consider if function is asynchronous or not and use it accordingly. Kotlin focuses on the fact that we called a function and we don’t even have to know if it is asynchronous or not - the code is exactly the same.
Completely agree with you. However, note the Swift design is actually pretty similar, though the async/await terminology is confusing. Adding the async key word to a function is just like marking a function with suspend – it indicates the function suspends/resumes (even the Swift docs describe it this way).
I’m not a Swift expert either, but I think the main difference is that in Swift you as a developer must mark a suspension point with await, OR assign the result to an async let variable which would be similar to using val deferred = async { … } in Kotlin. I’m not positive how async let plays with structured concurrency. I don’t think Swift’s structured concurrency story is as comprehensive as Kotlin’s – see this thread for example.
The Swift approach seems easier to understand for beginners because devs don’t need to worry about things like scopes when doing a basic async/async let, but harder to correctly program a larger application because devs would need to know when to opt out of the implicit behaviors.
You can find people on the Internet confused about pretty much any topic. Shall I search for similar posts about Swift async/await for you?
In the particular case you linked, the questioner is confused about whether the suspend modifier means the function suspends, or if it means the coroutine suspends. This indicates confusion about concepts more basic than coroutines, suspending functions, or async/await. The questioner does not appear to understand that every function in a program is run by threads – functions don’t run themselves somehow apart from threads/coroutines. The suspend is a modifier and it just tells us (and the compiler) something about the function just like Swift’s async modifier does.
The questioner could ask almost exactly the same question about what the Swift “async” modifier means because the Swift documentation states “Asynchronous code can be suspended and resumed later” (my emphasis).
This will likely be my last reply to you because you are not addressing any of the arguments made to you in previous posts. You just keep moving the goal posts, First you started with Unit, then you went on to suspend, and now you’re posting almost random SO’s. Unless you engage with the arguments presented, replying to you is a waste of time. My only consolation is that my posts may help one or two other readers.
I didn’t answer your email because, if I said I understood your point of view oriented on the technical aspect, you don’t understand my point of view that I place on the educative (cognitive) aspect.
The thread I posted reflect the problem I exposed from the beginning.
You say that tone of guys can be “confused about pretty much any topic”. I say that confusion come essentially from inconsistence in semantic usage or knowingness. In a most of the case, an excess of complex words, followed by inappropriate usage of words.
Unit is a technical consequence, not a frontal understandable meaning, except for someone who knows the underlying technic. As a rule, you should limit the biases to have to know the background of something before to start to learn it. What a primary accessor understands with functions is that a function can return a result, or return nothing. The reason why very surely the vast majority of languages choose void — even though technically, in the gut is not so exact.
Suspend is a technical consequence, not a frontal understandable meaning for someone who start with the subject to run some stuffs, on the main, because he needs run some parallels stuffs, not to stuck his UI.
This is probably the reason why some languages preferred to use async/await.
Accessibility is all about my concern. Not the “absolute” truth that could / should / must be given by chosen terms.
Does a “word” help to understand the primary usage or not. If not, I, as UX and Cognitive Science lover, consider it’s an accessibility (and unnecessary) stop.
You can’t hide the cognitive complexity for learners simply by using words that point to simpler concepts, if the simpler concepts lead the learner to the wrong understanding!
It was explained to you that it does not return nothing. Swift also does not return nothing, even though they define Void as a type alias. So perfect example: use of the word void reduced your cognitive load, but left you with the wrong understanding.
Another example of the same problem. It was explained to you that suspending functions do not run stuff in parallel. Your choice (and Swift’s choice) of using async/await reduced your cognitive load because they were familiar to you, but again, they left you with the wrong understanding.
You SHOULD hide the complexity in order to allow the greater number of people to access easily every thing, in order to give them the possibility to improve their skills with the less of barriers. It’s an educative principle.
So on the side of education and accessibility even with all good technical justifications, Unit is a bad choice, and suspend remain discutable.
In the whole discussion about Unit, I still miss some good ideas or recommendations for alternative names or approaches. I personally hate Unit, and still I don’t see a better name. So at least for me discussing why Unit is bad isn’t very productive.
I agree with you that “why Unit is bad” can be counter productive. But sometime to understand the underlying of a “design” allows to understand what this “design” tries to solve.
The process of design is to understand exposed pains or frictions, or origines of solutions to figure out if we are addressing correctly the underlying pains or frictions or if on the contrary we are just facing forefront solutions which have been imposed by some “design processes lead by some considerations”.
When it turns to design a language or any library we are driven by rules of meaning in order to expose rapidly, the most intuitively as possible, what entities are, do, produce…
keywords, function name, param names, types… definitions are driven by that kind of rules.
You can take the rule to expose the most as possible the underlying mechs in the surface semantics, or you can take the one to be the more simple to give a larger access.
It’s true for code, for device, for book, for tech, for everything.
What is pretty true is that “named stuffs” must have an easy meaning, and make application/usage easy especially if they are in a high frequency usage.
It’s noticeable that () exists in other languages but does’t wear name for most.
What did lead the attribution of Unit for () is a very intellectual approach that shouldn’t rise the surface of “for everyone code”.
I practice different worlds in the code universe (I teach to engineers) it’s noticeable to meet some computer science namings (like factory, stateful, pattern…) in the documentation of Android SDK, things you’ll not find in the documentation of Apple SDK.
Like you I don’t like Unit, I would prefer they used Void (in the fact () is a 0 byte stuff, so it’s nothing) and for simpler users, it’s just meaning a function returning nothing and that it.
Try to explain to a newbie that a function that return nothing, in fact something you can’t use, is for him a total confusion, coming in the right line with all the mess he met when he study math functions that are so badly taught.
I understand @Raman who defends the idea to be “technically” true. But I defend the idea to be as accessible as possible, and let to the few specialists the opportunity to be confronted to the underlying mechs.
While recommending this, do you account for the fact Java already provides Void, so while targeting Java we have two distinct Void types, meaning different things and used in different scenarios?
If you like Void instead of Until feel free to create a type alias to use in your own code. But I think it is more confusing with the concept of returning a void. As people keep telling you and you seem to ignore is that returning Unit does not mean not returning anything.