-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
CspChan
A pure C (-std=c89) implementation of Go channels, including blocking and non-blocking selects.
> 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/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.
[2] https://9fans.github.io/plan9port/
Oberon+ already has generics and they should play well with my present proposal: 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.
I've updated the paper and removed the SELECT, CLOSE and CLOSED procedures as discussed.
I still think a close feature which - in contrast to Go - would just signal all waiting threads and abandon communication could be useful. I implemented this in the C library I use for experiments: https://github.com/rochus-keller/CspChan
> the proposal for it to take a timeout, which could then be detected via execution of ELSE?
It could still be added in future, e.g. as an additional parameter to SEND or RECEIVE, but in a similar way to CLOSE it makes things more complicated, and there is an alternative solution with a separate thread sending after a delay a over a channel which receives in a WITH statement where the candidate channel waits.
> have you considered asking Dr Wirth for feedback?
I have qualms about bothering him with this in his well-deserved retirement, especially as he has demonstrated with Oberon-07 in which direction he would develop the language (see also https://oberon-lang.github.io/2021/07/16/comparing-oberon+-w...).