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

161–170 of 246 posts

Re: A Farewell to FRP

#161

Post by vanderZwan »

junke wrote: post #151
iheartmemcache wrote: post #115

Earlier quoted context omitted.

I'm a huge INRIA fan so I decided to play with Esterel a while back. If people call Haskell an 'academic' language, I have no idea how an average person would describe Esterel. "Thinking in" Esterel is going to be a huge shift for the traditionally trained CS guy who's never touched a circuit. Half the people in our field didn't even go to go to school for CS[1]. Hell, I've got a decent amount of LabVIEW and Verilog…

> Do you have a link to your thesis? There is only a French version: https://tel.archives-ouvertes.fr/tel-00680308/ The context is about using a constraint programming approach (in Prolog) to model Lustre/Scade programs and automatically generate traces of input/outputs that satisfy a given test objective. With the help of my advisers I extended the GATeL tool to introduce what is known as "clocks" in Lustre and inte…

I get the impression that synchronous programming is somehow only really known inside the French PL community, is that correct?

Re: A Farewell to FRP

#162

Post by pedalpete »

notduncansmith wrote: post #143
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.

I've been thinking about this myself. I've been looking at doing some typescript stuff as I can share code between back and front-end still (and I'm moving into doing some IoT stuff in JS). I'd consider Elm if I could run it everywhere, but it feels to me like at the moment it is browser focused.

Re: A Farewell to FRP

#163

Post by lisivka »

SomeCallMeTim wrote: post #135
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.

Huh. I find that when my C++ compiles, it almost always works. Correctly. But I used the language for nearly 20 years, so maybe it's experience and the patterns I've learned? Not that Rust or Elm aren't better options; don't know, really. Despite feeling like I'm an expert in C++, I don't actually like the language much. I've used Go some, and I like it, but I haven't tried Rust or Elm yet.

It is a bug in the compiler. (Old joke).

Re: A Farewell to FRP

#164

Post by marcosdumay »

SomeCallMeTim wrote: post #135
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.

Huh. I find that when my C++ compiles, it almost always works. Correctly. But I used the language for nearly 20 years, so maybe it's experience and the patterns I've learned? Not that Rust or Elm aren't better options; don't know, really. Despite feeling like I'm an expert in C++, I don't actually like the language much. I've used Go some, and I like it, but I haven't tried Rust or Elm yet.

Well, I find that when my C++ compiles

When I first learned Java, still in my undergrad, my first impression (and nearly everybody's) was that when it compiles it works. It was still more work than Perl, Lisp, Prolog, and everything, but didn't require the annoying C debugging cycle.

But, anyway, all that is kids play near Haskell.

Re: A Farewell to FRP

#166

Post by infinity0 »

SomeCallMeTim wrote: post #135
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.

Huh. I find that when my C++ compiles, it almost always works. Correctly. But I used the language for nearly 20 years, so maybe it's experience and the patterns I've learned? Not that Rust or Elm aren't better options; don't know, really. Despite feeling like I'm an expert in C++, I don't actually like the language much. I've used Go some, and I like it, but I haven't tried Rust or Elm yet.

> Huh. I find that when my C++ compiles, it almost always works. Correctly. > > But I used the language for nearly 20 years, so maybe it's experience and the patterns I've learned?

By contrast, I learnt OCaml and Haskell 2 weeks ago, and when my code in those languages compiles, it always works. I expect I'll have the same experience with Rust.

Re: A Farewell to FRP

#167

Post by zem »

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.

pony is worth a look: http://www.ponylang.org/

Re: A Farewell to FRP

#169

Post by ryenus »

FRP = Functional Reactive Programming

> When I started working on my thesis in 2011, I stumbled upon this academic subfield called Functional Reactive Programming (FRP). By stripping that approach down to its simplest form, I ended up with something way easier to learn than similar functional languages. Signals meant piles of difficult concepts just were not necessary in Elm.

Re: A Farewell to FRP

#170

Post by SomeCallMeTim »

vvanders wrote: post #156
SomeCallMeTim wrote: post #135

Earlier quoted context omitted.

Huh. I find that when my C++ compiles, it almost always works. Correctly. But I used the language for nearly 20 years, so maybe it's experience and the patterns I've learned? Not that Rust or Elm aren't better options; don't know, really. Despite feeling like I'm an expert in C++, I don't actually like the language much. I've used Go some, and I like it, but I haven't tried Rust or Elm yet.

You really owe it to yourself to give Rust a shot. A lot of things that you've encoded in convention(as any good C++ programmer should) are right there at the language level. Ownership? You get an awesome sliding scale of Borrow Checker Boxed Rc/Arc Mutation? Covered in Copy+Clone/Cell &/&mut RefCell Thread Safety? Sync + Send guarantee that things which need to stay on a specific thread cannot be shared. Combine tha…

Rust does sound interesting, but it doesn't seem to be focused on the areas that I need right now.

Go has GoRoutines, which are light threads; they can be executed on multiple CPU threads, but by default Go only allocates one CPU thread per physical CPU, even if you allocate tens of thousands of GoRoutines.

For the kind of networking server code I'm writing, light threading is far more efficient than using an OS thread per connection. 25-50x faster at higher server loads.

That's why I've ignored Rust to date; if Rust has light threading built in, but no one is talking about it (haven't found anything but real threads in my quick Google searches), then I'll take a look. Otherwise it will need to wait for me to have a task that Rust would be good for, and I'll stick with Go and TypeScript for the problems I'm solving right now.

Post reply on HN