3 ms·

That's really interesting. Perhaps the gap in my knowledge is the difference between programming model and execution model. But let me ask another question: Wh

That's really interesting. Perhaps the gap in my knowledge is the difference between programming model and execution model. But let me ask another question: What's the difference between yielding from a function and returning? Why is yielding considered concurrent programming and returning sequential? I guess I had associated concurrent programming with threads but maybe multi-threaded programming is better called parallel execution?

Jtsummers 5y ago
Return terminates the function or thread of execution. Yield (may) provides a value but leaves the thread of execution alone otherwise, only pausing it. It’s resumable where a return is not (without a lot of extra bookkeeping). https://blog.golang.org/waza-talk https://blog.golang.org/waza-talk A good talk that expresses the current sentiment and helped establish it. Concurrency may be parallel, but doesn’t need to be. This does go against the common (outside programming) notion of the meaning of concurrent which means it provides a strong potential for confusion.
- gpderetta 5y ago
  Equivalently, both yield and return invoke the calling function continuation, but while return discards the current one, yield saves it somewhere for resumption.
simiones 5y ago
Concurrent usually refers to any kind of control flow in which separate (logical) threads of execution can be interleaved, and where the particular interleaving can affect the final result. For example, event systems are inherently concurrent, even if they are single threaded: the order of events affects normally affects the final state of the system (for example, if you receive a request to SET X=0 and a request to INCREMENT X, the final result may be 0 or 1 depending on the order, even if you have a single thread of execution actually handling the events). In contrast, parallel programming usually refers to program flows where multiple instruction streams can be interleaved arbitrarily without changing the final result. For example, when using mapping a pure function on a list, the execution of the function for each element of the list can be executed in parallel without any concurrency. Alternatively, parallel execution can refer to any case where multiple instruction streams are actually executed in parallel, regardless of their order. Concurrency often has pitfalls even with single-threaded execution models. For example, if two generators share some common state, even if they are executed in a single thread, the final result depends on how they are used and may be unexpected.
nybble41 5y ago
I don't think there is a gap in your knowledge so much as a clash in terminology between different (programming) communities. What the Go community here is referring to as "concurrency" sounds to me like the traditional definition of "multithreading", while "parallel execution" meets the definition I've seen before for "concurrency". This was probably done to distinguish operating-system threads (preemptive multitasking, possibly involving multiple CPU cores) from asynchronous application code (user-mode cooperative multitasking on a single core), but to me a form of "concurrency" without concurrent execution, i.e. operations from different threads executing in parallel at the same time, seems like a contradiction.
chowells 5y ago
A programming model is what the programmer has to think about in order to write a program. Brainfuck probably has the simplest model I can think of - you have an instruction pointer referring to the next byte in the program to execute, and a flat array of memory cells that program instructions may read and write. Every command in the language is about working with those two elements. C has a much more complex model consisting of statements that are stepped through, functions that may be called (including recursively) with parameters, local variables, global variables, static local variables, constness vs mutability, pointer types, names for symbolic access to those things... And probably a lot more that I've neglected. Concurrency is a thing that might be part of a programming model where you are allowed to interleave execution of multiple logical workflows but still write each logical workflow as a single unit of code. The programming model model tells you what properties you are guaranteed to get. An execution model is something that describes implementation of a programming model. A related example is how concurrency is implemented in a particular system. Is it multiple threads running simultaneously? Is it a complex state machine jumping between logical workflows as demanded by their semantics? Is it an even-more-complex m:n model involving both threads and state machines? Execution models aren't irrelevant to programming. They can have a significant impact on performance and edge-case behavior that the programming model doesn't clearly specify. But you should be able to write programs with only the programming model in mind and get correct code in most circumstances. (I'd call it a specification failure if you can't.) A programming model describes the tools the programmers have available, their semantics and interactions. An execution model describes how those things run on the hardware that is present.

Jtsummers 5y ago

Return terminates the function or thread of execution. Yield (may) provides a value but leaves the thread of execution alone otherwise, only pausing it. It’s resumable where a return is not (without a lot of extra bookkeeping). https://blog.golang.org/waza-talk https://blog.golang.org/waza-talk A good talk that expresses the current sentiment and helped establish it. Concurrency may be parallel, but doesn’t need to be. This does go against the common (outside programming) notion of the meaning of concurrent which means it provides a strong potential for confusion.

gpderetta 5y ago
Equivalently, both yield and return invoke the calling function continuation, but while return discards the current one, yield saves it somewhere for resumption.

simiones 5y ago

Concurrent usually refers to any kind of control flow in which separate (logical) threads of execution can be interleaved, and where the particular interleaving can affect the final result. For example, event systems are inherently concurrent, even if they are single threaded: the order of events affects normally affects the final state of the system (for example, if you receive a request to SET X=0 and a request to INCREMENT X, the final result may be 0 or 1 depending on the order, even if you have a single thread of execution actually handling the events). In contrast, parallel programming usually refers to program flows where multiple instruction streams can be interleaved arbitrarily without changing the final result. For example, when using mapping a pure function on a list, the execution of the function for each element of the list can be executed in parallel without any concurrency. Alternatively, parallel execution can refer to any case where multiple instruction streams are actually executed in parallel, regardless of their order. Concurrency often has pitfalls even with single-threaded execution models. For example, if two generators share some common state, even if they are executed in a single thread, the final result depends on how they are used and may be unexpected.

nybble41 5y ago

I don't think there is a gap in your knowledge so much as a clash in terminology between different (programming) communities. What the Go community here is referring to as "concurrency" sounds to me like the traditional definition of "multithreading", while "parallel execution" meets the definition I've seen before for "concurrency". This was probably done to distinguish operating-system threads (preemptive multitasking, possibly involving multiple CPU cores) from asynchronous application code (user-mode cooperative multitasking on a single core), but to me a form of "concurrency" without concurrent execution, i.e. operations from different threads executing in parallel at the same time, seems like a contradiction.

chowells 5y ago

A programming model is what the programmer has to think about in order to write a program. Brainfuck probably has the simplest model I can think of - you have an instruction pointer referring to the next byte in the program to execute, and a flat array of memory cells that program instructions may read and write. Every command in the language is about working with those two elements. C has a much more complex model consisting of statements that are stepped through, functions that may be called (including recursively) with parameters, local variables, global variables, static local variables, constness vs mutability, pointer types, names for symbolic access to those things... And probably a lot more that I've neglected. Concurrency is a thing that might be part of a programming model where you are allowed to interleave execution of multiple logical workflows but still write each logical workflow as a single unit of code. The programming model model tells you what properties you are guaranteed to get. An execution model is something that describes implementation of a programming model. A related example is how concurrency is implemented in a particular system. Is it multiple threads running simultaneously? Is it a complex state machine jumping between logical workflows as demanded by their semantics? Is it an even-more-complex m:n model involving both threads and state machines? Execution models aren't irrelevant to programming. They can have a significant impact on performance and edge-case behavior that the programming model doesn't clearly specify. But you should be able to write programs with only the programming model in mind and get correct code in most circumstances. (I'd call it a specification failure if you can't.) A programming model describes the tools the programmers have available, their semantics and interactions. An execution model describes how those things run on the hardware that is present.