4 ms·

Well ok. The topic of generics were strangely absent from the channel discussion. That is an alternative solution to the type issue. Adding those is like killin

Well ok. The topic of generics were strangely absent from the channel discussion. That is an alternative solution to the type issue. Adding those is like killing a mosquito with a bazooka, but there are languages (like crystal) that has generics and therefore use them for this. As for the proposal itself, it seems to lack the recognition that channels + ability to spawn fibers/threads has not shown themselves to be sufficient in practice. Most of the time people don't want unbounded and unknown lifetimes on the executors, but instead want to be able to see that directly in the code. In go, that resulted in wait groups, and in other languages (java, swift, kotlin etc) a thing called structured concurrency is talked about, see https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g... for the article that started that.

Rochus 3y ago
Oberon+ already has generics and they should play well with my present proposal: https://github.com/oberon-lang/specification/blob/master/The_Programming_Language_Oberon%2B.adoc#generics https://github.com/oberon-lang/specification/blob/master/The... > Most of the time people don't want unbounded and unknown lifetimes on the executors, but instead want to be able to see that directly in the code. You mean something like join? This can easily be done by adding a channel on which each thread of the interesting group sends when finished. Thanks for the link, I will have a look at it. EDIT: Ok, after looking through the referenced article I can confirm that it is about join and that there is a solution with channels as described. Unfortunately I don't have an example in Oberon yet, but here is one from my C library: https://github.com/rochus-keller/CspChan/blob/6867c1a28e1443633bb99b65652bf58f033f5bb9/test.c#L445 https://github.com/rochus-keller/CspChan/blob/6867c1a28e1443.... What is called a "Nursery" in the article is just a procedure here (testSieve2) which initiates threads in a similar way like Go, passes an eof channel to them an then waits until it receives on this eof channel.
- yxhuvud 3y ago
  > Oberon+ already has generics and they should play well What I meant was, channel types is something you get for free if they are implemented in terms of generics, without having to resort to custom syntax. Example, in Crystal: `channel = Channel(Int32).new`, which would then only accept and produce Int32. > You mean something like join? I meant an obligatory join, that no fibers or threads can be created without knowing where in the code it will have ended. > This can easily be done The problem is that this is both repetitive and very easy to get wrong. Hence the need for wait groups and/or nurseries.
  - Rochus 3y ago
    > without having to resort to custom syntax But this requires extensive casting features which we don't have in Oberon+. Here is a discussion about this: https://github.com/oberon-lang/oberon-lang.github.io/blob/main/_posts/2023-12-25-towards-concurrency.md#types-of-implementation https://github.com/oberon-lang/oberon-lang.github.io/blob/ma... > I meant an obligatory join This is how it was solved in Occam, Joyce or SuperPascal. It's just another language philosophy, and also less flexible than the detached go routines. Using Go (or Oberon+ in future) requires another way of thinking and architecture. Requiring wait groups or other features from the sync package seem like an indication of a mismatch between the architecture and the language philosophy. I'm actually very interested in what things really don't match the Go (or Oberon+ so far) language philosophy and cannot be solved satisfactorily in Go.
    - yxhuvud 3y ago
      Wait groups is a feature that was added to go quite long ago, so the claim that it doesn't match the language philosophy seems more than a little bit strange. Or were you just talking about making them obligatory? I've seen claims though that it is best practice to always use wait groups but I can't judge the quality of those claims as I don't actually program go.
      - Rochus 3y ago
        If it wasn't part of Newsqueak, then it's very likely not part of the original language philosophy. A lot of things seem to have been added with hindsight to ease migration and support programmers coming from previous thread libraries. > I've seen claims though that it is best practice to always use wait groups Is this from the original authors? Can you provide a reference, please?
        yxhuvud 3y ago
        > A lot of things seem to have been added with hindsight to ease migration Or perhaps a lot of things were added because it makes the language easier to write and read and less prone to failures, when solving real problems. Pragmatism wins, every time. Frankly, Go doesn't seem like a language that would add stuff to ease migration or to simplify for people coming from other backgrounds. > Is this from the original authors? No, random forum posts by seemingly experienced developers.

Rochus 3y ago

Oberon+ already has generics and they should play well with my present proposal: https://github.com/oberon-lang/specification/blob/master/The_Programming_Language_Oberon%2B.adoc#generics https://github.com/oberon-lang/specification/blob/master/The... > Most of the time people don't want unbounded and unknown lifetimes on the executors, but instead want to be able to see that directly in the code. You mean something like join? This can easily be done by adding a channel on which each thread of the interesting group sends when finished. Thanks for the link, I will have a look at it. EDIT: Ok, after looking through the referenced article I can confirm that it is about join and that there is a solution with channels as described. Unfortunately I don't have an example in Oberon yet, but here is one from my C library: https://github.com/rochus-keller/CspChan/blob/6867c1a28e1443633bb99b65652bf58f033f5bb9/test.c#L445 https://github.com/rochus-keller/CspChan/blob/6867c1a28e1443.... What is called a "Nursery" in the article is just a procedure here (testSieve2) which initiates threads in a similar way like Go, passes an eof channel to them an then waits until it receives on this eof channel.

yxhuvud 3y ago
> Oberon+ already has generics and they should play well What I meant was, channel types is something you get for free if they are implemented in terms of generics, without having to resort to custom syntax. Example, in Crystal: `channel = Channel(Int32).new`, which would then only accept and produce Int32. > You mean something like join? I meant an obligatory join, that no fibers or threads can be created without knowing where in the code it will have ended. > This can easily be done The problem is that this is both repetitive and very easy to get wrong. Hence the need for wait groups and/or nurseries.
- Rochus 3y ago
  > without having to resort to custom syntax But this requires extensive casting features which we don't have in Oberon+. Here is a discussion about this: https://github.com/oberon-lang/oberon-lang.github.io/blob/main/_posts/2023-12-25-towards-concurrency.md#types-of-implementation https://github.com/oberon-lang/oberon-lang.github.io/blob/ma... > I meant an obligatory join This is how it was solved in Occam, Joyce or SuperPascal. It's just another language philosophy, and also less flexible than the detached go routines. Using Go (or Oberon+ in future) requires another way of thinking and architecture. Requiring wait groups or other features from the sync package seem like an indication of a mismatch between the architecture and the language philosophy. I'm actually very interested in what things really don't match the Go (or Oberon+ so far) language philosophy and cannot be solved satisfactorily in Go.
  - yxhuvud 3y ago
    Wait groups is a feature that was added to go quite long ago, so the claim that it doesn't match the language philosophy seems more than a little bit strange. Or were you just talking about making them obligatory? I've seen claims though that it is best practice to always use wait groups but I can't judge the quality of those claims as I don't actually program go.
    - Rochus 3y ago
      If it wasn't part of Newsqueak, then it's very likely not part of the original language philosophy. A lot of things seem to have been added with hindsight to ease migration and support programmers coming from previous thread libraries. > I've seen claims though that it is best practice to always use wait groups Is this from the original authors? Can you provide a reference, please?
      - yxhuvud 3y ago
        > A lot of things seem to have been added with hindsight to ease migration Or perhaps a lot of things were added because it makes the language easier to write and read and less prone to failures, when solving real problems. Pragmatism wins, every time. Frankly, Go doesn't seem like a language that would add stuff to ease migration or to simplify for people coming from other backgrounds. > Is this from the original authors? No, random forum posts by seemingly experienced developers.