5 ms·

> 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 gene

> 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

> 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.