I've dabbled with Céu for some toy programs, which is a modernized Esterel of sorts[0]. I wish more people picked it up; it's a tiny language, currently mostly

I've dabbled with Céu for some toy programs, which is a modernized Esterel of sorts[0]. I wish more people picked it up; it's a tiny language, currently mostly developed by one professor in Brazil, but quite fun! I think it would be a great environment to teach Arduino in, if I'd ever do that again. A year ago I wrote a comment on /r/Arduino giving an example snippet[1], which I'll copy here: #include "arduino/arduino.ceu" input int PIN_02; // button input output int PWM_05; // LED outputs, remember that pins 5 and 6 output int PWM_06; // have a higher PWM frequency on the UNO // a code block that concurrently fades an LED in and out // `pin` the output pin of the LED // `min` min value of the fade // `max` max value of the fade // `delay` ms to wait between `analogWrite` updates code/await Fade_forever(var u8 pin, var u8 min, var u8 max, var uint delay) -> void do loop do var int i; loop i in [min->max[ do // fade in loop if pin == 5 then emit PWM_05(i); else/if pin == 6 then emit PWM_06(i); end await delay ms; end loop i in [min<-max[ do // fade out loop if pin == 5 then emit PWM_05(i); else/if pin == 6 then emit PWM_06(i); end await delay ms; end end end loop do //endless loop // if *any* of these three code blocks (trails) end, // all of the remaining trails in a `par/or` are // aborted and code resumes (in this case, the outer // loop restarts). By comparison, a `par/and` // would require *all* of the trails to terminate. par/or do // if a button is pressed, reset the loop await PIN_02; with // fade the LED at pin 5 quickly between 64 and 192 await Fade_forever(5, 64, 192, 5) with // fade the LED at pin 6 slowly between 0 and 256 await Fade_forever(5, 0, 256, 20) end Pretty simple and readable code, don't you think? (Note the use of Bourbaki interval notation for [min -> max[ - how often have you seen that in programming languages?) Now imagine what the plain C version of this would look like. What I also find fascinating about it is that it has almost no memory overhead per trail - a handful of bytes IIRC. Compare that to the kilobytes required for green thread solutions elsewhere. OTOH, computationally the concurrency doesn't really scale with large numbers of trails - I think you could compare it to insertion sort: unbeatable for small arrays due to low overhead, but then that O(n^2) takes over. One might envision having many small Céu programs with only a handful of trails each, asynchronously running in their own threads and interacting with each other. From what I gather, programming in this model is called using the GALS principle: Globally Asynchronous, Locally Synchronous. For the intended environment for Céu (embedded programming), you kind of "naturally" get this: asynchronicity just kind of "happens" due to separate pieces of hardware interacting. Anyway, it kind of feels like the "missing element" in reactive and concurrent programming paradigms to me. I hope more languages will start picking it up eventually. [0] http://ceu-lang.org/ http://ceu-lang.org/ [1] https://www.reddit.com/r/arduino/comments/5qzv12/c%C3%A9uarduino_structured_reactive_programming_for/dd3hjs5/ https://www.reddit.com/r/arduino/comments/5qzv12/c%C3%A9uard...