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

Elm and Phoenix/Elixir in Production for France TV

vincent.jousse.org

Post reply on HN
Print view View original

41–50 of 80 posts

Re: Elm and Phoenix/Elixir in Production for France TV

#41

Post by biot »

ggregoire wrote: post #38

Even if you don't like JavaScript, it's really surprising to me that a CTO picks something like Elm that nobody uses and only a few know or are interested in [1]. I'm curious to know how the author will recruit developers, specially in France. My last company migrated all its backend in Node this year, ONLY because it was the easiest option to recruit full-stack developers. The market is completely saturated here (th…

It's no different than listing a Java job vs listing a Scala job. There are many great developers who would jump at the chance to be hired to write Scala (Elm), so you might just end up with better developers who self-select to work on the shiny, new technology.

Re: Elm and Phoenix/Elixir in Production for France TV

#43

Post by ccapndave »

softawre wrote: post #34
ccapndave wrote: post #23

Earlier quoted context omitted.

Its true that you can't currently write a service worker in Elm. However, in practice for any decent size app you are going to end up with a mix of Elm and Javascript with communication happening through ports. Therefore you can write the service worker in JS and then talk to it from Elm. Of course it would be nicer to be able to write everything in Elm, but I find having the majority of your app in Elm with a bit of…

I'm a huge TypeScript fan. Yet I worry about adding Elm to new projects, mostly because it raises the level of developer I need to hire to maintain it. I'm not in SV or in a tech hotspot at all, so maybe I have to think about this more than the average HN reader.

If you don't mind using remote developers, then your location doesn't have to matter. It's true that it might be a bit harder to find a developer (although Elm is getting more popular day by day), but the other side of the coin is that your application is likely to have less bugs and need less maintenance. My experience is that Elm takes a bit longer to write than JS/TS, but once written it tends to work correctly the first time.

Re: Elm and Phoenix/Elixir in Production for France TV

#44

Post by hellofunk »

danenania wrote: post #36
hellofunk wrote: post #14

Earlier quoted context omitted.

At the very least, Elm code should be compatible with Google's Closure compiler (just like Clojurescript). There is no reason the Elm folks should try to re-invent the wheel on this, just harness the power of the Closure utilities by making your emitted JS standardized and compliant. Then you get all sorts of things for free, like dead code elimination, just for starters. The Clojure team realized this from the start…

I disagree. Google Closure is antiquated and complicated to configure and adds a lot of unpleasant baggage to cljs. I love Clojurescript as a language, but using it alongside existing js libraries is awkward and error-prone, and getting the build process to work smoothly takes way more time than it should. Cljs gets a lot right too, but it shouldn't be held up as an example in this regard.

Closure's advanced compilation mode really optimizes the final JS, no?

Re: Elm and Phoenix/Elixir in Production for France TV

#45

Post by kevinastone »

> As a business owner/recruiter, I wanted something with a low entry barrier for my future hirings. Elm has a low entry barrier, the JS ecosystem/fatigue/mess doesn't.

This is nonsense. There's a much greater pool of talent familiar with javascript than Elm.

Using Elm might be marketable ("come work with Elm here!"), but it's a riskier bet for a developer given it's relative immaturity and adoption.

Re: Elm and Phoenix/Elixir in Production for France TV

#46

Post by hellofunk »

Skinney wrote: post #40
hellofunk wrote: post #14

Earlier quoted context omitted.

At the very least, Elm code should be compatible with Google's Closure compiler (just like Clojurescript). There is no reason the Elm folks should try to re-invent the wheel on this, just harness the power of the Closure utilities by making your emitted JS standardized and compliant. Then you get all sorts of things for free, like dead code elimination, just for starters. The Clojure team realized this from the start…

The way Elm outputs JS today, it doesn't really have much to gain from being Closure compliant. Even uglify manages to remove most dead code from an Elm "blob", because Elm outputs javascript with a single scope. An Elm app is smaller than both a Cljs+React(om, reagent) and a JS+React app.

Dead code elimination is only part of the benefits of Closure. The advanced compilation mode does a lot to optimize the final JS.

Re: Elm and Phoenix/Elixir in Production for France TV

#47

Post by qaq »

noam87 wrote: post #37
qaq wrote: post #20

Have not had time to try Elm yet but Elixir is such a pleasure to use, it's painful going back to JS :)

It really is. We're rebuilding our entire backend in Elixir and it's just been incredible every step of the way. I can't recommend it enough. The language and ecosystem are an amalgamation of industry lessons from the past three decades on what it takes to build robust networked applications. It's the most painless programming experience I've had. These days other languages feel like museum pieces when I have to jump…

Good to see industry uptake is picking up. Gives me hope that one day I can have a job programming in Elixir :)

Re: Elm and Phoenix/Elixir in Production for France TV

#48

Post by sotojuan »

kevinastone wrote: post #45

> As a business owner/recruiter, I wanted something with a low entry barrier for my future hirings. Elm has a low entry barrier, the JS ecosystem/fatigue/mess doesn't. This is nonsense. There's a much greater pool of talent familiar with javascript than Elm. Using Elm might be marketable ("come work with Elm here!"), but it's a riskier bet for a developer given it's relative immaturity and adoption.

At this point the "come work with Elm" only works at places that have long-term Elm experts and fans (e.g. No Red Ink which hired its creator, has their lead evangelist, and probably more than half the top Elm people in the world).

Re: Elm and Phoenix/Elixir in Production for France TV

#49

Post by david-given »

danneu wrote: post #35
david-given wrote: post #33

Earlier quoted context omitted.

Yes, but just like the ones in the docs, that's a nearly trivial example, and so doesn't demonstrate the complexity. What I'm concerned about is the case when I want to call a Javascript function from deep down inside, say, a computation function. Do I have to split my computation into two halves, one which sends the event which calls the Javascript function, and another which receives the result of the function? How…

Some interactions with 3rd party libraries (like rendering stuff, leaflet.js, pixi.js) fall along natural event-driven faults, like the game update tick finishing, something managed by Elm being clicked, that sort of thing. In these cases, ports (events) are the obvious fit. Then there's synchronous 3rd party library stuff where you just want to execute a Javascript function, like a math function that you aren't goin…

Ah, right --- I have heard of native modules, but only in the context of things I shouldn't using. I'll look more closely. Ta!

Re: Elm and Phoenix/Elixir in Production for France TV

#50

Post by sotojuan »

leshow wrote: post #29

I hope Elm doesn't get too closely tied with Elixir. It's a great language no matter what backend you choose.

I also don't get why they're coupled a lot... they're very different once you get past that they're both "functional" (and Elixir really just has HOFs and immutability by default, it's very practical). If it makes you feel better, I only see this coupling online. Most people just use server-rendered pages or regular JavaScript.
Post reply on HN