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

171–180 of 246 posts

Re: A Farewell to FRP

#171

Post by SomeCallMeTim »

infinity0 wrote: post #166
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.

> 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.

Funny. I managed to get Haskell to crash within about 20 minutes of first trying it out.

OCaml is supposed to be pretty fast, but so far Haskell hasn't impressed me with performance either.

Re: A Farewell to FRP

#172

Post by vvanders »

SomeCallMeTim wrote: post #170
vvanders wrote: post #156

Earlier quoted context omitted.

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 thre…

Ah, sounds like Erlang/Elixir would be a better fit since the BEAM is the king of lightweight threads/processes.

You said C++ so that's why I suggested Rust, generally a GC tends to preclude spaces where C++ excels which is why I would think you'd want to try something other than Go.

On the Rust side there's things like mio for fast io but coroutine/light threads aren't really a focus afaik. I would still think you could get solid performance (and much better memory use, see Dropbox's replacement of Go) with an event based Rust system although that's not really my area of expertise :).

Re: A Farewell to FRP

#173

Post by mgold »

lisivka wrote: post #163
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.

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

I thought it was a bug in the specification? (Older joke.)

Re: A Farewell to FRP

#174

Post by mgold »

timroy wrote: post #52
ccapndave wrote: post #43

I moved from React/Redux/Typescript to Elm a few months ago, and I'm now on my second serious project with it, making mobile application with Cordova. I've found it an absolute pleasure to use, and I especially like that you can be pragmatic about it; if there is something that is annoying to do in Elm then you can simply drop into Javascript/Typescript using ports. Coming from languages like Actionscript/Javascript/…

"if it compiles, then it just seems to work" Man, now that is tempting. Also, how easy are the ports? In ClojureScript you can use JavaScript pretty directly, but I often got a bit hung up translating the syntax (it's not that hard, it was just me).

Apparently a human-readable homoiconic language is still an unsolved problem...

In 0.17, commands and subscriptions mean that, not matter how deep you nest components, you can still send and receive messages to/from the outside world (i.e. ports).

Re: A Farewell to FRP

#175

Post by taneq »

outworlder wrote: post #139
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.

> But I used the language for nearly 20 years, so maybe it's experience and the patterns I've learned? It definitely is. This is not the usual C++ experience. You are probably sidestepping all sorts of undefined behavior due to experience alone.

This matches my experience with C++. My code has improved hugely in simplicity and robustness as I've learned which C++ features are productive and which are just minefields.

Re: A Farewell to FRP

#176

Post by taneq »

biot wrote: post #113
christophilus wrote: post #56

Earlier quoted context omitted.

>> if it compiles, then it just seems to work This. I spent the first 14 years of my career in statically typed languages and only this year began working professionally on a Rails app... I really miss the compiler.

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.

"This will be the sixth time we have reinvented basic programming, and we have become exceedingly efficient at it."

Re: A Farewell to FRP

#177

Post by platz »

hkjgkjy wrote: post #60
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…

Elm is typed, Clojurescript is homoiconic. 2 great features. Wondering if you could make a lisp where `lambda` or `fn` required type annotations, such as (defn add [int -> int -> int] ;; type annotation [x y] ;; arguments list (+ x y)) Then it would be homoiconic - something that has saved me hundreds of lines of code (and the less code, the less bugs as a rule of thumb). Then every function down to the very basic li…

   \* add.shen *\

   (define add
      {number --> number --> number} \* type annotation *\
      X Y ->                         \* arguments list  *\
      (+ X Y))

Re: A Farewell to FRP

#178

Post by curried_haskell »

jiaweihli wrote: post #142
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/

But Scala is far from a simple language and Akka makes it even less so.

Re: A Farewell to FRP

#179

Post by Gaelan »

SomeCallMeTim wrote: post #171
infinity0 wrote: post #166

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? 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.

Funny. I managed to get Haskell to crash within about 20 minutes of first trying it out. OCaml is supposed to be pretty fast, but so far Haskell hasn't impressed me with performance either.

What code did you write?

Re: A Farewell to FRP

#180

Post by Gaelan »

taneq wrote: post #176
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.

"This will be the sixth time we have reinvented basic programming, and we have become exceedingly efficient at it."

What is that a reference to?
Post reply on HN