Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Farewell to FRP

elm-lang.org

Post reply on HN
Print view View original

141–150 of 246 posts

Re: A Farewell to FRP

#141

Post by rvense »

brightball wrote: post #114
shrugger wrote: post #103

Earlier quoted context omitted.

You might be interested in the Crystal language. It's a statically-typed, Object-oriented, Ruby inspired language. It's Ruby with types, basically. You might also be interested in Elixir which ties in to the Erlang ecosystem, but if you are super into OOP (like me) you might find it slightly more difficult, but since you have experience with static-types, you probably know some FP stuff, and so it's not that bad. Eit…

It's odd how people are in their perspectives on static vs dynamic. I can't for the life of me understand how people tolerate static typing on the web. Every time I've tried it the experience has been so tedious. I just figure, everything is coming in as a string no matter what. It's going back out as a string. The only place it needs to be anything other than a string is something interesting is being done with it a…

You build your system as a box that takes strings in and sends strings out. You then have to do a bunch of checks (as part of your de/serializing) at the boundaries only. Inside the box, all your logic and transformations are type safe, and indeed you can turn some logic issues into mechanically checked type-level issues, which are basically free unit tests.

Re: A Farewell to FRP

#142

Post by jiaweihli »

nilkn wrote: post #93

What I really want is a language with Elm's type system, simplicity, and syntax, but aimed for backend software instead of HTML apps and with strong support for an Erlang-style actor model of multicore, distributed concurrency. Basically something like Elixir, but with Elm's syntax and type safety. In the meantime Elixir will do for me, but I'd really like more type safety without going full Haskell.

Akka[1] is exactly the library you're looking for. It's available for Scala[2], which lets you use both OOP and FP as needed. (It also runs in Java if you have experience with that.)

[1] http://akka.io/ [2] http://www.scala-lang.org/

Re: A Farewell to FRP

#143

Post by notduncansmith »

malandrew wrote: post #140

Since people in this thread are likely to be elm enthusiasts and know what's going on in the ecosystem, what is the largest high quality elm app you know about and what is the largest high quality elm app that is open-source that you know about? I've been doing backend work for a while and I'd like to see what is possible these days with elm.

I think NoRedInk, who employs Evan (author of Elm); they also host Elm meetups in SF and are a really friendly bunch.

On an unrelated note, I haven't found much prior work here but I think Elm on the backend (via Node.js) could be fantastic.

Re: A Farewell to FRP

#144

Post by timroy »

pseudonom- wrote: post #92
timroy wrote: post #50

Earlier quoted context omitted.

Yeah, after the app grew a bit, I had state scattered here and there. re-frame solves this with a big atom, and avoids expensive rendering every time the big atom updates with subscriptions. Subscriptions hold reactions, which only update if the underlying value changes. The re-frame readme is epic and worth reading just for its own sake: https://github.com/Day8/re-frame Not to get off-topic though! I am used to work…

Can you talk a little more about your thoughts on one big atom? I've been looking at Redux and they also seem to follow this approach. The re-frame readme quotes the Elm Architecture as justification, but that same document goes on to describe nesting https://gist.github.com/evancz/2b2ba366cae1887fe621#nesting . I come from a Haskell perspective and having one big blob of state sounds to me like it makes your type si…

So, the one big atom solved two problems for me.

First, in Reagent/FRP, I was updating a view based on the value of an atom. This meant I had different default values in different atoms. The big atom let me unify where I stored values, and reuse values, without a performance hit. Second, the big atom made storing application state trivial: you can just throw the map/record in Redis or something.

However, the big atom is just a big map, and keys can be paired with any value, so it is not enforcing types. From a Haskell perspective (where I understand the program almost falls out of the types you define!), this probably does increase the scope for error.

This can be mitigated with Schema (which I never used effectively), logging changes to the console, and being able to see your default map easily (like, there's a map in one file which I load upfront, so I can see what values are there).

I'd welcome hearing from anyone with a more advanced or precise use of re-frame state.

Re: A Farewell to FRP

#145

Post by timroy »

Morgawr wrote: post #102
timroy wrote: post #7

This looks very cool. In ClojureScript, we have the re-frame pattern/framework, which is built on Reagent, which is a ClojureScript wrapper of React. re-frame is all about subscriptions, using a "big atom" to hold application state client-side. Seeing Elm implement the same subscription pattern makes it look pretty tempting. My understanding is that ClojureScript and Elm have some similarities - functional, pleasant…

I personally use ClojureScript with type annotations from Plumatic (former Prismatic) Schema and it works really well. Obviously it's not the same as an actual typed language, but it gives me a good-enough starting point to leverage some typing information and perform some rudimentary (runtime) type checking. I also feel it's really nice as some kind of "inline documentation" to be able to see the type of your parame…

I have heard only good things about Schema, and I probably should have invested the time to understand and use it more intensively.

Re: A Farewell to FRP

#146

Post by doppioslash »

nilkn wrote: post #107
knewter wrote: post #97

Earlier quoted context omitted.

Then you'll probably be very excited to read about http://package.elm-lang.org/packages/elm-lang/core/4.0.0/Pro...

Well, BEAM has supervisors, supervision trees, loads of support for fault tolerance, automatic usage of multiple cores, and it easily scales to multiple nodes as well. Simple actor-based concurrency is possible in many languages. Also, even if Elm were to get all that stuff, it'd still be compiling to JavaScript and aimed at web apps. (Don't get me wrong, I'm super excited to see Elm getting support for message-passi…

No actually, if you read the announcement you'll find that Elm is keeping platform specific code in the Platform module, to not be locked into being a Javascript-only language forever.

So maybe it would take some time, months, years, but Elm could end up running on the BEAM.

Re: A Farewell to FRP

#147

Post by CuriousSkeptic »

andybak wrote: post #132
biot wrote: post #113

Earlier quoted context omitted.

Give it another year and the new batch of hotshot developers will reinvent static typing and perhaps one or two other features from the 1970s, but it'll have some cool name and only implement 50% of the functionality.

Modern static typing isn't remotely related to typing from the "1970's"

Ok, 1969, but fairly close!

https://en.m.wikipedia.org/wiki/Hindley–Milner_type_system

Re: A Farewell to FRP

#148

Post by WorldMaker »

iheartmemcache wrote: post #106
WorldMaker wrote: post #99

Earlier quoted context omitted.

I think that's my biggest question reading the article here: Has Elm been ignoring the work going on with Rx all this time? These Elm subscriptions sound like "half" of Rx, and from what I can is still 'missing' thus far some of the "higher order" Observable tools such as filter, chain, map, throttle, et al.

After reading the article, I went into their IRC chan to post this question (i.e. are they leveraging all the research from really-smart(TM) PhD's at Microsoft Research & production testing that Rx has behind it). This guy has a doctorate, so I'd imagine there was a reason why RxJS wasn't leveraged, especially since it seems like a natural fit especially with Typed.*. And n general the Elm/Haskell community is way le…

I feel some of this.

I almost had a Microsoft-first shop let me use Haskell when I pointed out how many of Haskell's lead developers worked at Microsoft Research UK.

As for the Microsoft "first party" F# equivalent for the web, that would be Typescript. Typescript's typing isn't yet to the rigor of OCaml, much less Haskell or Elm, but it's getting better every release.

Re: A Farewell to FRP

#149

Post by charlieflowers »

So, is it still true to say, "You wish you could express your business logic with pure functions. But often you can't because the lack of immutability hurts performance in various ways. But ELM creates a 'sandbox' in which you can do so, by letting you write functions which work over time varying streams instead of stateful callbacks."

If not, which parts changed / how would you revise it?

Re: A Farewell to FRP

#150

Post by spdionis »

ShaneWilton wrote: post #125
brightball wrote: post #114

Earlier quoted context omitted.

It's odd how people are in their perspectives on static vs dynamic. I can't for the life of me understand how people tolerate static typing on the web. Every time I've tried it the experience has been so tedious. I just figure, everything is coming in as a string no matter what. It's going back out as a string. The only place it needs to be anything other than a string is something interesting is being done with it a…

> I just figure, everything is coming in as a string no matter what. It's going back out as a string. Maybe so, but that only accurately describes things at the boundaries of your system. Your database tables still have columns that hold integers, dates, or floats. Sure, you could do the type coercions as needed, but at that point you're missing out on the valuable opportunity to validate your data as it enters the s…

You can avoid defensive checks anyway. Just don't writre them! /s
Post reply on HN