Elm as competitor to Go for writing micro service architectures?

[Jason Kuhrt]

I work as a software engineer at littleBits leading the cloud team there. I have have a keen interesting in the idea of treating time as a first class value. At littleBits we're focused on millisecond realtime services that have highly unstable client connections with dynamic subscribers that come and go at any time, etc. So we have many of use-cases for robust composition of asynchronous IO operations. It is safe to say that in many instances the compositional requirements are easily on par with what a rich user interface can require.

I haven't seen much talk of FRP outside of UIs but I wanted to know from this community what the stance is. Is there a serious defect of FRP for servers (in principal I cannot see why, perhaps just lack of performant implementations)? I am also curious what Evan's and the general community's priority for non-browser environments is.

We are currently eying a new performant FRP library https://pozadi.github.io/kefir for use in some of our Node/IO.js services.

I make a reference to Go in the title as it has seen considerable uptake respect and success in the infrastructure and service-oriented-architecture communities. Its a high bar to compete with.

Thanks!

Jason

[Ken Carpenter]

I had the same thought as I was learning about elm.  FRP in general seems like a good fit for servers, and thus elm too.

I was sort of surprised to see the Haskell code for the server in the example programs.

I was also looking at Kefir yesterday and it looks very interesting.

My guess is that server side is not elm's initial focus and priority, but that if someone were interested enough to do the leg work, they could probably make that happen.

Reimplementing similar modules like Express, Connect, body-parser, cookie-parser, passport authentication, sessions, JSON parsing, XML parsing, database interfaces, etc. in an FRP style would be a significant undertaking.

Ken Carpenter

[Ken Carpenter]

Incidentally littlebits looks very cool!

Ken

On Tuesday, March 3, 2015 at 6:53:03 PM UTC-8, Jason Kuhrt wrote:

[Jeff Smits]

On Wed, Mar 4, 2015 at 3:53 AM, Jason Kuhrt <jason...@littlebits.cc> wrote:

I work as a software engineer at littleBits leading the cloud team there. I have have a keen interesting in the idea of treating time as a first class value. At littleBits we're focused on millisecond realtime services that have highly unstable client connections with dynamic subscribers that come and go at any time, etc. So we have many of use-cases for robust composition of asynchronous IO operations. It is safe to say that in many instances the compositional requirements are easily on par with what a rich user interface can require.

I haven't seen much talk of FRP outside of UIs but I wanted to know from this community what the stance is. Is there a serious defect of FRP for servers (in principal I cannot see why, perhaps just lack of performant implementations)? I am also curious what Evan's and the general community's priority for non-browser environments is.

I don't know of a serious defect of FRP outside UIs. One of the influences on Elm's flavour of FRP is Real-time FRP, the paper with the same title presents FRP for real-time (RT) systems and embedded software. Much older concepts from Synchronous Programming Languages are also meant for high-performance.
So there is definitely FRP outside UIs. Whether Elm's flavour of FRP is the right one is another question. It's something to try out I guess. I imagine a pain point might be that everything is automatically synchronised in Elm and you pick asynchrony yourself, but in a server situation you may need so much asynchrony that the synchronous-by-default is just annoying if not a bottleneck.

As for just Elm outside of the browser, I think many people have already dreamed of being able to use Elm for native UIs both on desktop and on mobile phones. I personally dreamed more of implementing Elm's flavour of FRP outside the browser to experiment more with asynchrony and possible extensions to generalise state instead of keeping it localised in foldp.

[Jason Kuhrt]

Ah, that is an interesting point about Elm's default synchronous behaviour. That seems like a great concrete point to investigate next. Presumably I would want to be constantly doing async work in the domains I am imagining (well apart from HTTP servers, we're heavy on UDP/TCP/CoAP servers, PubSub systems, ZMQ/gRPC/etc messaging, Web Socket Servers ...) and I'm quite curious how hard Elm would fight back here. I generally do not understand well enough for my taste the signal graph as-is and its relationship to synchronization and opt-in async.

Since the next version of Elm will do away with signals in place of Stream/Varying I will wait for that big change to settle before diving in more I think.

[Jeff Smits]

If you want to know more about signals and opt-in async, I suggest you try Evan's PLDI paper on Elm. Read from the introduction (1) up to building GUIs (4). You can skip the type system (3.2) and functional evaluation (3.3.1), that may save you some time. Most in and after building GUIs (4) is probably stuff you know already. Figure 8 is probably the best overview of what the async keyword does (note that the async keyword is not implemented in the current Elm compiler).

I think it's wise to wait for 0.15 because of changes, but I don't think Stream/Varying is going to be the big change. I think the whole Promises API, which is meant to connect Elm to stuff like HTTP/WebSockets/local databases/cookies/whatever, is going to be a bigger influence on your plans.

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alex Shroyer]

Hey Jason,

I'm a software/electrical engineer supporting psychological research.  Lots of hard-real-time data acquisition mixed with PC-based user interaction (the experiments often resemble mini-videogames).  Though the bulk of the PC-side stuff is Matlab, I evangelize Elm wherever possible.

I think FRP is a great idea for not just real-time systems, but also DSPs and FPGAs.  One thing that attracted me to Elm was its resemblance to analog circuitry*, so I think its semantics would readily map to hardware synthesis.

* In particular, pure functions that transform input look (to me anyway) an awful lot like analog filters, op-amps, etc. You can do a lot with stateless transformations. ;)

[Kim-Ee Yeoh]

On Tue, Mar 10, 2015 at 8:30 AM, Alex Shroyer <ashr...@gmail.com> wrote:

One thing that attracted me to Elm was its resemblance to analog circuitry*, so I think its semantics would readily map to hardware synthesis.

* In particular, pure functions that transform input look (to me anyway) an awful lot like analog filters, op-amps, etc. You can do a lot with stateless transformations. ;)

Not so well-known as it should be is that Haskell has a long tradition of research into hardware description languages (HDL). The one off the top of my head is Lava. Bluespec is another, the compiler of which, like Elm, is also written in Haskell.

So not just analog but also digital circuitry ;)

For those who know some hardware design, those are excellent gateways into FRP because they are products by some of haskell's best minds.

-- Kim-Ee

[Antony Courtney]

Lots of past research involved using FRP for applications outside of web dev.

A plug for a couple of papers from my old research group relevant to the specific areas discussed here:

"Arrows, Robots, and Functional Reactive Programming" ( http://haskell.cs.yale.edu/?post_type=publication&p=175 ) -- A tutorial introduction to the use of Yampa for robotics and other hybrid systems.  The implementation was recently revived and updated to modern Haskell by Ivan Perez.  

"Parallel Functional Reactive Programming" ( http://haskell.cs.yale.edu/?post_type=publication&p=202 ) -- a very early exploration of relaxing the deterministic concurrency model of Fran.  Uses a simple web server as a basic example.

The rest of the group's FRP-related publications are here: http://haskell.cs.yale.edu/publications/#FunctionalReactiveProgramming

Much of this work is over a decade old, so doubtful that the code is still around or useful. But hopefully the papers have a few ideas that might still be applicable to more modern realizations of FRP such as Elm.