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

121–130 of 246 posts

Re: A Farewell to FRP

#121

Post by dreamdu5t »

masklinn wrote: post #74
dreamdu5t wrote: post #57

Looks like Elm moved closer to Pux's API by dropping the signals for `Html action`. Check out Pux if you're interested in the same architecture but for PureScript. https://github.com/alexmingoia/purescript-pux

Wow, the buttons demo looks very, very close: http://guide.elm-lang.org/architecture/user_input/buttons.ht... The biggest difference is that the Elm version of "start a simple application" encapsulates more boilerplate, but I guess pux can do server-side rendering?

Yeah, Pux can do server-side rendering, and PureScript can be used with webpack alongside other JS. PureScript also has a much easier FFI.

Re: A Farewell to FRP

#122

Post by GavinMcG »

dominotw wrote: post #49
embwbam wrote: post #44

Earlier quoted context omitted.

Evan wants to design Elm as thoughtfully as he can, and has been deliberately resisting community evolution. Eventually it will get too big and too useful, and he'll lose the ability to make big breaking changes easily. So he's tried to maintain control of the direction of the language and community during these early years while he figures it out. He's trying to reduce the feedback loop and come up with the best pos…

' during these early years' should feature prominently in their docs/website if that is case. If you go to http://elm-lang.org/ they make it looks like its production ready. No mention of breaking changes/beta ect. You have to choose one or the other .

The version number starting with a zero really ought to denote that, notwithstanding the JS crowd's seemingly fast and loose approach.

Re: A Farewell to FRP

#123

Post by bmichel »

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.

Did you try dialyzer for Erlang[1] or Elixir[2]?

[1]: http://erlang.org/doc/apps/dialyzer/dialyzer_chapter.html [2]: http://elixir-lang.org/docs/stable/elixir/typespecs.html

Not sure it helps, it's on my todo list.

Re: A Farewell to FRP

#124

Post by Matthias247 »

appsappsapps wrote: post #119
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…

What typed languages have you used and what aspects do you find tedious? I find that the experience of writing brittle type-checking logic and tests in dynamic languages is rather tedious in its own right.

I find that even the typing experience is faster with static types, since we get better autocompletion/intellisense and there is no need to lookup documentation or other code all the time.

Re: A Farewell to FRP

#125

Post by ShaneWilton »

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…

> 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 system. You can provide meaningful errors to users as early as possible, you can avoid defensive checks nearly everywhere else within your code, and you can just generally trust that invariants about your data are going to hold throughout the rest of your program.

This leads to smaller test suites, more concise codebases, and higher security assurances overall. If you look at the sorts of vulnerabilities that often pop up in Rails for example, many of them simply don't affect you if you use something like Virtus [0] to validate the types of your data as it enters the system.

I don't do much web development, but statically typed web development is the only way I've ever been able to tolerate it.

[0] https://github.com/solnic/virtus

Re: A Farewell to FRP

#126

Post by el_tone »

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.

Have you had a look at F#? fsharpforfunandprofit.com

Re: A Farewell to FRP

#127

Post by musha68k »

Keats wrote: post #9

I like Elm but its development really seems to rely on a single person. I saw this post on elm-discuss which is a pretty good summary of my thoughts https://groups.google.com/forum/#!topic/elm-discuss/AmxE3qAm...

Same here and for that very reason I'll continue playing with Elm (it's fun) but ultimately I'm focusing more on learning Clojurescript as it seems to be the safer "sane" way out of JS/React country, at least for my professional projects.

Re: A Farewell to FRP

#128

Post by Matthias247 »

jlongster wrote: post #24
zachrose wrote: post #19

I haven't dabbled in Elm much, but subscriptions look a lot like ordinary JS event handlers: Time.every second Tick vs. Time.on('everySecond', tick) Beyond baking an event emitter into the Time module and having a nice looking API, is there something I'm missing?

I don't know anything about Elm subscriptions yet. But there is a lot more to this stuff then just event emitters. Things like: * When an event/action/etc comes through, does it always call listeners synchronously? Can you change that and schedule events manually? * How do you compose subscriptions/event handlers? This is usually the hardest part, and where simple event emitters really start breaking * What about the…

Exactly these questions also came to my mind when I read the article. Subscriptions can get very tricky. Sometimes you want events to be synchronously fired, sometimes it's better when they are deferred into another eventloop tick. Unsubscription can also get quite tricky as you said.

I really wonder if Elm got a generic solution that fits all possible usage scenarios.

Re: A Farewell to FRP

#129

Post by Buttons840 »

swaroop wrote: post #117
astrodust wrote: post #110

Earlier quoted context omitted.

Rust has some really good compile-time checking, it really makes you express everything in a completely non-ambiguous way. C++ on the other hand compiles stuff that may or may not work at all, it doesn't care, which can lead to all sorts of undefined behaviour down the road. Compilers are not all created equal.

The new C++ Core Guidelines & Guidelines Support Library and related tools are interesting efforts to specifically solve those problems.

If the issue is that "C++ compiles stuff that may or may not work at all" then I don't see how those guidelines will help the situation. A C++ project may or may not follow those guidelines and then we're back where we started.

Re: A Farewell to FRP

#130

Post by zachrose »

masklinn wrote: post #54
zachrose wrote: post #19

I haven't dabbled in Elm much, but subscriptions look a lot like ordinary JS event handlers: Time.every second Tick vs. Time.on('everySecond', tick) Beyond baking an event emitter into the Time module and having a nice looking API, is there something I'm missing?

`Time.every second Tick` returns a time-varying value it doesn't call a side-effecting callback. It generates a filtered event emitter if you will. Semantically it has almost no relation to your JS version, aside from both being function calls.

Ah, this explanation is the most cogent to me. So does the Elm runtime and/or compiler manage this as an event or callback under the hood?
Post reply on HN