4 ms·

What's the point about using a functional language like Gleam / Elixir for web-server applications? I used the work for WhatsApp in Erlang, and there's a stron

What's the point about using a functional language like Gleam / Elixir for web-server applications? I used the work for WhatsApp in Erlang, and there's a strong use case for OTP / BEAM for messaging apps, but it feels useful for anything else - especially a webserver where frameworks like Rails and Django are so easy / well supported. What do you think I'm missing?

emmelaich 3y ago
> but it feels useful Did you mean "It doesn't feel useful" ?
alberth 3y ago
Since you mention Rails, have you seen https://www.phoenixframework.org/ https://www.phoenixframework.org/ Question: what’s the status of WA open sourcing their typed Erlang project?
- lawik 3y ago
  You mean the type checker eqWAlizer? That is out there. Not sure if they got further on typed Erlang. Ar Code BEAM in Berlin just now there was a presentation on a type system effort much like the Elixir one.
  - worthless-trash 3y ago
    I am reading that right, a type-system like elixir's new type proposal for erlang ? Can you provide more details, Thanks in advance.
    - lawik 3y ago
      This talk: https://codebeameurope.com/talks/etylizer-set-theoretic-types-for-erlang/ https://codebeameurope.com/talks/etylizer-set-theoretic-type... No clue if it will get into Erlang since I don't think it started from inside Erlang/OTP. But from conversations the team seem open to an effort like this.
- worthless-trash 3y ago
  I remember reading somewhere,WA had to go back to do some improvements, so there was going to be a delay. Was it this one https://github.com/WhatsApp/erlt https://github.com/WhatsApp/erlt ?
dqv 3y ago
> especially a webserver where frameworks like Rails and Django are so easy / well supported. [boilerplate response about OTP, pattern matching, LiveView] It's honestly mostly aesthetics, there isn't anything particularly rational about preferring it over Rails/Django. Like it just feels better. You can mostly do what you do in Elixir in other languages, but it's comfortable in my little Elixir project folders. I have nothing against Django or Rails, but I noticed that as soon as I asked the question of "how do I do a task in the background" "how do I keep longrunning state without over-relying on the DB" it got way more complex. Setting up carrot or whatever Django scheduling library was painful. In the BEAM family of languages, as you know, you just spawn a process to do background tasks or keep state. It can always be revisited with something more complex when the time arises. Starting an Elixir application also just feels more robust. It has my back. It's not going to just stop working without putting up some kind of fight. I like that I can do things like start the other application components without starting the webserver. Elixir makes me feel like my code is "alive", like it's an organism with living components. Again, not rational. Oh shit, I made fun of the boilerplate OTP statement, but I do really like the way it prescribes application structure. Being able to think of the application as a tree of components is really helpful for my mental model of what's going on. Ecto is also a big deal for me. Nothing beats the LINQ-style query building, then dropping into plain SQL as needed. If I ended up switching languages, it would need to have something like LINQ in it. So maybe C# lol. Binary pattern matching is always something I miss when I'm not using Elixir. Especially for parsing or converting data. But you're really not missing anything if Erlang didn't seem remarkable when you were using it.
- worthless-trash 3y ago
  One thing that I do miss is the pipe operator, I'm doing LFE now which I can use the arrow operator which seems to get me most of the way there. There is no "ecto" equivalent for LFE yet, that'd be very nice, but probably above my skillset.
bicx 3y ago
There is a strong case to be made that BEAM/OTP is a more natural fit for handling thousands or millions of web server requests. Django and Rails are definitely powerful frameworks, but there have been repeated and justified criticisms of their performance. These frameworks are built upon scripting languages designed for convenience rather than performance. OTP application failure handling and recovery out of the box is also fantastic. Beyond performance though, I think functional languages really fit well into the common unidirectional data patterns used when building out a web app. Typically you're running a request through a pipeline of functions like parsers and other middleware, shaping a response to send back to the user before destroying all used computing resources as quickly as possible. Modern languages like Elixir and Gleam provide some great capabilities (pipes, pattern matching, comprehensive stream-based map/reduce capabilities, etc...) for building these pipeline-style workflows in a very natural way, because it's really a quite functional approach already. There is also no real need for building true OOP-style objects when you're just going to throw everything away in a few milliseconds.
worthless-trash 3y ago
Just to be clear, this is a 'typed' functional language something that erlang is not. Gleams type system has reduced the crashes in my code, however I do still supervise them and distribute tasks across systems (See https://github.com/wmealing/gleam-otp-design-principals/blob/main/gleam-otp-design-principals.org https://github.com/wmealing/gleam-otp-design-principals/blob... ) Non beam languages not get this kind of capability out of the box.
lawn 3y ago
Functional languages map really well for web-servers as all you're doing is receiving a request, transforming it and sending it back, and that's really what functional programming is all about. So I ask you, what's the point of using imperative or object oriented languages for web-server applications?
hmmokidk 3y ago
I am way more productive with Elixir than any other stack i have tried. It’s actually insane. Things that seem almost unimaginable are so easy. Building an application that gets way larger than just a web app is so much more doable too. You’ve got everything you need right there and it’s so easy to organize in a conventional way. Testing every inch of it is so much easier. It’s a brilliant technology. There’s a reason why there are so many evangelists. So many people experience a new found joy of programming when they use Elixir. And there are so many times I think “this would be so much easier” with Elixir when I work with other langs.
nesarkvechnep 3y ago
I find it strange that you, having worked with Erlang, struggle to see a use-case for BEAM languages in the context of web development.
tomekowal 3y ago
Short answer: scheduler. Long answer: web applications have usually tons of independent request. Each request does its own thing, might never communicate with other requests, touches the DB and returns. You have two choices in such scenarios. You can either maximise throughput or minimise latency. BEAM's scheduler choses the latter which is usually what you want for web. More detailed discussion: https://tkowal.wordpress.com/2015/01/27/the-unintuitive-latency-over-throughput-problem/ https://tkowal.wordpress.com/2015/01/27/the-unintuitive-late... With: - per process garbage collection - one BEAM process per request - short lived HTTP processes you might never trigger garbage collection, the whole memory is deallocated at the end of requests. It basically means, BEAM gives you high level languages like Gleam or Elixir that are fast to write and prototype as Rails or Django, but are almost as performant as handwritten memory managed applications written in low level language. This is magic sauce in startups: the freedom to go fast, prototype and iterate with scalibility issues popping up waaay later than in Ruby/Python stacks (sometimes never - if your startup is successful without supporting whatsapp's user base :P) And that's just if you are donig plain old HTTP backend. With new reactive architectures, keeping persistent processes server side and using LiveView instead of JS frameworks can again cut development time. And then, there is support for AI with LiveBook and NX... It is weird how many hard issues BEAM just makes much easier.

emmelaich 3y ago

> but it feels useful Did you mean "It doesn't feel useful" ?

alberth 3y ago

Since you mention Rails, have you seen https://www.phoenixframework.org/ https://www.phoenixframework.org/ Question: what’s the status of WA open sourcing their typed Erlang project?

lawik 3y ago
You mean the type checker eqWAlizer? That is out there. Not sure if they got further on typed Erlang. Ar Code BEAM in Berlin just now there was a presentation on a type system effort much like the Elixir one.
- worthless-trash 3y ago
  I am reading that right, a type-system like elixir's new type proposal for erlang ? Can you provide more details, Thanks in advance.
  - lawik 3y ago
    This talk: https://codebeameurope.com/talks/etylizer-set-theoretic-types-for-erlang/ https://codebeameurope.com/talks/etylizer-set-theoretic-type... No clue if it will get into Erlang since I don't think it started from inside Erlang/OTP. But from conversations the team seem open to an effort like this.
worthless-trash 3y ago
I remember reading somewhere,WA had to go back to do some improvements, so there was going to be a delay. Was it this one https://github.com/WhatsApp/erlt https://github.com/WhatsApp/erlt ?

dqv 3y ago

> especially a webserver where frameworks like Rails and Django are so easy / well supported. [boilerplate response about OTP, pattern matching, LiveView] It's honestly mostly aesthetics, there isn't anything particularly rational about preferring it over Rails/Django. Like it just feels better. You can mostly do what you do in Elixir in other languages, but it's comfortable in my little Elixir project folders. I have nothing against Django or Rails, but I noticed that as soon as I asked the question of "how do I do a task in the background" "how do I keep longrunning state without over-relying on the DB" it got way more complex. Setting up carrot or whatever Django scheduling library was painful. In the BEAM family of languages, as you know, you just spawn a process to do background tasks or keep state. It can always be revisited with something more complex when the time arises. Starting an Elixir application also just feels more robust. It has my back. It's not going to just stop working without putting up some kind of fight. I like that I can do things like start the other application components without starting the webserver. Elixir makes me feel like my code is "alive", like it's an organism with living components. Again, not rational. Oh shit, I made fun of the boilerplate OTP statement, but I do really like the way it prescribes application structure. Being able to think of the application as a tree of components is really helpful for my mental model of what's going on. Ecto is also a big deal for me. Nothing beats the LINQ-style query building, then dropping into plain SQL as needed. If I ended up switching languages, it would need to have something like LINQ in it. So maybe C# lol. Binary pattern matching is always something I miss when I'm not using Elixir. Especially for parsing or converting data. But you're really not missing anything if Erlang didn't seem remarkable when you were using it.

worthless-trash 3y ago
One thing that I do miss is the pipe operator, I'm doing LFE now which I can use the arrow operator which seems to get me most of the way there. There is no "ecto" equivalent for LFE yet, that'd be very nice, but probably above my skillset.

bicx 3y ago

There is a strong case to be made that BEAM/OTP is a more natural fit for handling thousands or millions of web server requests. Django and Rails are definitely powerful frameworks, but there have been repeated and justified criticisms of their performance. These frameworks are built upon scripting languages designed for convenience rather than performance. OTP application failure handling and recovery out of the box is also fantastic. Beyond performance though, I think functional languages really fit well into the common unidirectional data patterns used when building out a web app. Typically you're running a request through a pipeline of functions like parsers and other middleware, shaping a response to send back to the user before destroying all used computing resources as quickly as possible. Modern languages like Elixir and Gleam provide some great capabilities (pipes, pattern matching, comprehensive stream-based map/reduce capabilities, etc...) for building these pipeline-style workflows in a very natural way, because it's really a quite functional approach already. There is also no real need for building true OOP-style objects when you're just going to throw everything away in a few milliseconds.

worthless-trash 3y ago

Just to be clear, this is a 'typed' functional language something that erlang is not. Gleams type system has reduced the crashes in my code, however I do still supervise them and distribute tasks across systems (See https://github.com/wmealing/gleam-otp-design-principals/blob/main/gleam-otp-design-principals.org https://github.com/wmealing/gleam-otp-design-principals/blob... ) Non beam languages not get this kind of capability out of the box.

lawn 3y ago

Functional languages map really well for web-servers as all you're doing is receiving a request, transforming it and sending it back, and that's really what functional programming is all about. So I ask you, what's the point of using imperative or object oriented languages for web-server applications?

hmmokidk 3y ago

I am way more productive with Elixir than any other stack i have tried. It’s actually insane. Things that seem almost unimaginable are so easy. Building an application that gets way larger than just a web app is so much more doable too. You’ve got everything you need right there and it’s so easy to organize in a conventional way. Testing every inch of it is so much easier. It’s a brilliant technology. There’s a reason why there are so many evangelists. So many people experience a new found joy of programming when they use Elixir. And there are so many times I think “this would be so much easier” with Elixir when I work with other langs.

nesarkvechnep 3y ago

I find it strange that you, having worked with Erlang, struggle to see a use-case for BEAM languages in the context of web development.

tomekowal 3y ago

Short answer: scheduler. Long answer: web applications have usually tons of independent request. Each request does its own thing, might never communicate with other requests, touches the DB and returns. You have two choices in such scenarios. You can either maximise throughput or minimise latency. BEAM's scheduler choses the latter which is usually what you want for web. More detailed discussion: https://tkowal.wordpress.com/2015/01/27/the-unintuitive-latency-over-throughput-problem/ https://tkowal.wordpress.com/2015/01/27/the-unintuitive-late... With: - per process garbage collection - one BEAM process per request - short lived HTTP processes you might never trigger garbage collection, the whole memory is deallocated at the end of requests. It basically means, BEAM gives you high level languages like Gleam or Elixir that are fast to write and prototype as Rails or Django, but are almost as performant as handwritten memory managed applications written in low level language. This is magic sauce in startups: the freedom to go fast, prototype and iterate with scalibility issues popping up waaay later than in Ruby/Python stacks (sometimes never - if your startup is successful without supporting whatsapp's user base :P) And that's just if you are donig plain old HTTP backend. With new reactive architectures, keeping persistent processes server side and using LiveView instead of JS frameworks can again cut development time. And then, there is support for AI with LiveBook and NX... It is weird how many hard issues BEAM just makes much easier.