alt Hacker NewsIntuitive concurrent programming in any language
Comments
I don't really understand what problem this is meant to solve at first glance. It'd be nice to see a simple example program involving concurrency written in plain Python, then a discussion of the annoying bookkeeping involved in avoiding concurrency errors and what traps would be easy to fall into, and then an example of how the same thing would be implemented using Lingua Franca and an explanation of how eliminates the bookkeeping and traps.
The elevator pitch needs work.
"in any language", but then the page says "We currently support C, C++, Python, TypeScript, and Rust."
"Lingua Franca is a coordination language" but then "Not a New Programming Language".
I think I see what this is going for but the descriptions need a lot of improvement.
I think the main example on the landing page is a bit counterintuitive?
Rock Paper Scissors but the graph presents the reveal as a reaction to the observation? In a loop? And somewhere there's a min-delay of a magical 1 sec? Why 1 sec and not 0.1 sec? Can this build up and the players get out of sync? (A bit strange to 'just wait, lol' if the language aims at solving problems in distributed systems).
Overall the example would be better if it separated the game from the players and also split out the repeat loop.
Maybe let both player reveal to a host and then receive a result (and the choices) ~ This way both players can be sure that the choice of the other player is independent of the observation.
(I know that the example is 'correct' in that the choice is made independent of the observation but I think the example could be improved if it solved some of the coordination problems involved in the scenario more cleanly through code architecture).
Overall I quite like the idea of having this polyglot meta language!
If you like the idea and work in robotics try out copper-rs, it works on the same underpinning concept but at compile time in rust + a graph description. The latest addition to the kernel is a profile guided scheduling feature that allows you to optimize the concurrency of the graph still at compile time based on previous timing measurements from its deterministic logs.
Erlang can do these very well. Is there anything LF better? Just asking for opinion.
I wonder, if there is so long research, why you have not come to conclusion that the main problem is not reactor/proactor/event loop, but writing actual asynchronous business logic. The industry has gone mostly coroutine approach, requiring special technology support and usually with lack of fine predictable execution and stack control for mission-critical cases. That's the reason why FutoIn AsyncSteps exists as concept and reference implementation in C++, Java and JS/ECMAScript. It is compatible with foreign reactors by design via AsyncTool interface.
Interesting.
Your use of the word "Reactor" at first confused me since there is a "Reactor Pattern" for event handling (https://en.wikipedia.org/wiki/Reactor_pattern) which is not what you mean.
How does your concurrency model differ from that of Erlang (the poster child for distributed concurrency)? Do you have a paper detailing your model and comparing with other languages?
I recently read Roman Obermaisser's excellent book "Event-Triggered and Time-Triggered Control Paradigms" which seems applicable to your architecture. At the bottom most level you have a global communication network based on a synchronized global clock and "Time-Triggered"(TT) semantics which is deterministic. A "Event-Triggered"(ET) communication channel is then overlaid on top of it which is non-deterministic. That way the system provides both hard real-time (i.e. TT) and soft real-time (i.e. ET) semantics.
Title is incorrect of course, it is: "Intuitive concurrent programming in a separate language than the one you use for the actual work"
... which is not to say it's irrelevant, but still: Why is it worthwhile to have a separate language for this, rather than some library with bindings in various languages?
[flagged]
[flagged]
[flagged]
Good to see flow-based programming (FBP) concepts spreading! Will add LF to the https://github.com/flux-doctrine/awesome-fbp list that I maintain
The award for the worst name goes to...
Seriously, it's long and still common, even in the context of computing, even in programming languages. Why would you choose a long name with two words and then not choose something somewhat unique? Such a horrible decision.
Really sad given that otherwise this seems like one of the more interesting new languages I've seen on HN.
I like that the code example seems to indicate they took the concept of "ports" from flow-based programming, which might be one of it's absolute strongest points:
That is, enabling data flow connections between individual inputs/outputs, and not just between components, which otherwise is too limiting, and typically causes a lot of extra syntax to handle that routing otherwise.Wrote about it in the context of workflow systems way back (https://livingsystems.cc/posts/workflows-dataflow-not-task-d...)
---
Edit 11:12 CET: I realize that “named ports” better captures what I had in mind here, as elaborated in a comment below.