5 ms·

I think you may be thinking of some other language. Gleam adds no overhead to the target platform used and both the Erlang VM and JavaScript runtimes have respe

by lpil 2y ago

I think you may be thinking of some other language. Gleam adds no overhead to the target platform used and both the Erlang VM and JavaScript runtimes have respectable performance. The Erlang VM specifically outcompetes F# for networked services, which is its main use case.

neonsunset 2y ago
This applies to the entire BEAM family. HN loves to sign praises to it yet never looks into the detail nor has performance intuition to know that the use of predominantly interpreted languages is frequently inappropriate (note how Erlang is next to Ruby): https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... With that said, I had no idea it could target JS and will need to look into that, thanks (V8 is surprisingly competent at number crunching if it can inline everything, otherwise still subject to harsh limitations of dynamic nature of JS). Also, F#, building on top of .NET, has rich ecosystem and a set of its own async abstractions with all kinds of actor patterns being popular (within very small F# community that is). It’s fast, and so is its networking stack. Why am I criticizing Gleam? Because we had two decades of programming languages built on slow foundations imposing strict performance ceiling. There is no reason for nice languages like Gleam to be slow, yet they are. I’m not sure why, maybe because of the myth of compiled languages requiring more effort and interpreted languages being more productive to write in?
- scns 2y ago
  Picking Erlang for number crunching is a Bad Idea™. You can use NIFs in C or Rust though for expensive computations. If you play to its' strengths it outshines the competition eg WhatsApp and 99.999999999% of uptime (that is a few seconds of downtime per year). Horses for courses. [Edit] Zero snark intended. https://www.youtube.com/watch?v=JvBT4XBdoUE https://www.youtube.com/watch?v=JvBT4XBdoUE
- h0l0cube 2y ago
  > benchmarksgame/ I suppose if you want to do some distributed mandelbrot in Erlang, you'd just use NIFs to use an actual systems language for compute. > maybe because of the myth of compiled languages requiring more effort and interpreted languages being more productive to write in? Erlang focuses it's ergonomics around distributed processing, dispatch, and communication. Some of that is really in the decisions around the language (e.g., fully functional, hot-swappable and remote dispatchable modules (using message passing), metaprogramming, pattern matching), the runtime (e.g., genserver, the supervisor, lightweight processes with isolated garbage collection), and the core libraries (e.g., ETS, http client/server), but also it's the ecosystem that has built around the Erlang because of its soft real-time flavor. If things like soft real-time, high process count, network dispatch, etc. aren't really interesting to you, and the language isn't your cup of tea, then you aren't the target market for Erlang and its ilk. But certainly it is useful and productive for a number of people/orgs who've made the leap to OTP based on actual business value (e.g., Discord and (historically) Whatsapp)
  - igouy 2y ago
    The benchmarks game website does quote the Erlang FAQ: https://benchmarksgame-team.pages.debian.net/benchmarksgame/sometimes-people-just-make-up-stuff.html#apples-and-oranges https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- lawn 2y ago
  You're not seeing the fundamental trade-off that BEAM is taking. They're not focusing on maximizing througput (number crunching) but on minimizing latency for the 99th percentile (keeping the server highly responsive even under heavy load). You really need to understand the pros- and cons of each tool. Dismissing the BEAM family because of a single attribute strikes me as a bit ignorant.
- seventyone 2y ago
  "Make it work, then make it beautiful, then if you really, really have to, make it fast. 90 percent of the time, if you make it beautiful, it will already be fast. So really, just make it beautiful!" – Joe Armstrong
  - neonsunset 2y ago
    This together with misunderstanding Donald Knuth's quote (it was talking about not hand-writing ASM rather than throwing the baby out with the bathwater) is why we don't have nice things in places we are ought to. You have a set of tools with comparable degrees of features and productivity*, but one of them comes at a steep performance cost, perhaps you might want to pick the one that is snappier and easier to use? * Though one could argue F# offers more in regular niceties at the cost of not having distributed framework built-in, requiring you to reach for Akka. I certainly find F# significantly easier to read and write than Erlang.
    - seventyone 2y ago
      Elixir is one of the most productive languages there is right now. Run into something slow? Replace that small bit with a Rust NIF and move on with your life.
      - neonsunset 2y ago
        Or write it in a language where you don't even have to think about it. (you have to maintain separate toolchain and exports in Rust, to achieve this, and complex types cannot be easily exported/imported - it is subject to limitations of C ABI, and FFI is not free either, even when as cheap as it gets - .NET has that with P/Invoke yet still it is a deoptimization in data-intensive algorithms, which benefit from being rewritten in C#/F#)
        seventyone 2y ago
        Complex Rust types are absolutely supported with Rustler. And with one command I can have Elixir pull a Rust crate and do 80% of the work setting it up for me to be able to use it in a project. https://github.com/rusterlium/rustler https://github.com/rusterlium/rustler
- spinningslate 2y ago
  > HN loves to sign praises to it yet never looks into the detail nor has performance intuition to know that the use of predominantly interpreted languages is frequently inappropriate (note how Erlang is next to Ruby): And you seem singularly focused in your belief that .Net is "the answer" every time a post promoting a BEAM ecosystem language comes up. It's clear you like .Net - good for you. It's solid and has nice features. But you're painting performance as some sort of absolute. It's not. > Also, F#, building on top of .NET, has rich ecosystem and a set of its own async abstractions with all kinds of actor patterns being popular What if I don't want "all sorts of async abstractions", but just one that works well? > Why am I criticizing Gleam? Because we had two decades of programming languages built on slow foundations imposing strict performance ceiling. And those programming languages have been used to develop sites like GitHub, WhatsApp, Facebook and countless other internet-scale apps. Every language and ecosystem imposes some form of performance ceiling. If performance was all that mattered, we'd all be writing assembler. It's about trade-offs: some of them technical, some of them social. .Net is a mature, stable, and performant ecosystem. You do it a disservice by rubbishing alternatives per your original comment ("Impossibly slow, just use F#"). -- EDIT: fixed spelling & grammar
- lpil 2y ago
  I'm sorry, I don't understand what point you're trying to make here, it seems unrelated to Gleam.

by lpil 2y ago

neonsunset 2y ago

This applies to the entire BEAM family. HN loves to sign praises to it yet never looks into the detail nor has performance intuition to know that the use of predominantly interpreted languages is frequently inappropriate (note how Erlang is next to Ruby): https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... With that said, I had no idea it could target JS and will need to look into that, thanks (V8 is surprisingly competent at number crunching if it can inline everything, otherwise still subject to harsh limitations of dynamic nature of JS). Also, F#, building on top of .NET, has rich ecosystem and a set of its own async abstractions with all kinds of actor patterns being popular (within very small F# community that is). It’s fast, and so is its networking stack. Why am I criticizing Gleam? Because we had two decades of programming languages built on slow foundations imposing strict performance ceiling. There is no reason for nice languages like Gleam to be slow, yet they are. I’m not sure why, maybe because of the myth of compiled languages requiring more effort and interpreted languages being more productive to write in?

scns 2y ago
Picking Erlang for number crunching is a Bad Idea™. You can use NIFs in C or Rust though for expensive computations. If you play to its' strengths it outshines the competition eg WhatsApp and 99.999999999% of uptime (that is a few seconds of downtime per year). Horses for courses. [Edit] Zero snark intended. https://www.youtube.com/watch?v=JvBT4XBdoUE https://www.youtube.com/watch?v=JvBT4XBdoUE
h0l0cube 2y ago
> benchmarksgame/ I suppose if you want to do some distributed mandelbrot in Erlang, you'd just use NIFs to use an actual systems language for compute. > maybe because of the myth of compiled languages requiring more effort and interpreted languages being more productive to write in? Erlang focuses it's ergonomics around distributed processing, dispatch, and communication. Some of that is really in the decisions around the language (e.g., fully functional, hot-swappable and remote dispatchable modules (using message passing), metaprogramming, pattern matching), the runtime (e.g., genserver, the supervisor, lightweight processes with isolated garbage collection), and the core libraries (e.g., ETS, http client/server), but also it's the ecosystem that has built around the Erlang because of its soft real-time flavor. If things like soft real-time, high process count, network dispatch, etc. aren't really interesting to you, and the language isn't your cup of tea, then you aren't the target market for Erlang and its ilk. But certainly it is useful and productive for a number of people/orgs who've made the leap to OTP based on actual business value (e.g., Discord and (historically) Whatsapp)
- igouy 2y ago
  The benchmarks game website does quote the Erlang FAQ: https://benchmarksgame-team.pages.debian.net/benchmarksgame/sometimes-people-just-make-up-stuff.html#apples-and-oranges https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
lawn 2y ago
You're not seeing the fundamental trade-off that BEAM is taking. They're not focusing on maximizing througput (number crunching) but on minimizing latency for the 99th percentile (keeping the server highly responsive even under heavy load). You really need to understand the pros- and cons of each tool. Dismissing the BEAM family because of a single attribute strikes me as a bit ignorant.
seventyone 2y ago
"Make it work, then make it beautiful, then if you really, really have to, make it fast. 90 percent of the time, if you make it beautiful, it will already be fast. So really, just make it beautiful!" – Joe Armstrong
- neonsunset 2y ago
  This together with misunderstanding Donald Knuth's quote (it was talking about not hand-writing ASM rather than throwing the baby out with the bathwater) is why we don't have nice things in places we are ought to. You have a set of tools with comparable degrees of features and productivity*, but one of them comes at a steep performance cost, perhaps you might want to pick the one that is snappier and easier to use? * Though one could argue F# offers more in regular niceties at the cost of not having distributed framework built-in, requiring you to reach for Akka. I certainly find F# significantly easier to read and write than Erlang.
  - seventyone 2y ago
    Elixir is one of the most productive languages there is right now. Run into something slow? Replace that small bit with a Rust NIF and move on with your life.
    - neonsunset 2y ago
      Or write it in a language where you don't even have to think about it. (you have to maintain separate toolchain and exports in Rust, to achieve this, and complex types cannot be easily exported/imported - it is subject to limitations of C ABI, and FFI is not free either, even when as cheap as it gets - .NET has that with P/Invoke yet still it is a deoptimization in data-intensive algorithms, which benefit from being rewritten in C#/F#)
      - seventyone 2y ago
        Complex Rust types are absolutely supported with Rustler. And with one command I can have Elixir pull a Rust crate and do 80% of the work setting it up for me to be able to use it in a project. https://github.com/rusterlium/rustler https://github.com/rusterlium/rustler
spinningslate 2y ago
> HN loves to sign praises to it yet never looks into the detail nor has performance intuition to know that the use of predominantly interpreted languages is frequently inappropriate (note how Erlang is next to Ruby): And you seem singularly focused in your belief that .Net is "the answer" every time a post promoting a BEAM ecosystem language comes up. It's clear you like .Net - good for you. It's solid and has nice features. But you're painting performance as some sort of absolute. It's not. > Also, F#, building on top of .NET, has rich ecosystem and a set of its own async abstractions with all kinds of actor patterns being popular What if I don't want "all sorts of async abstractions", but just one that works well? > Why am I criticizing Gleam? Because we had two decades of programming languages built on slow foundations imposing strict performance ceiling. And those programming languages have been used to develop sites like GitHub, WhatsApp, Facebook and countless other internet-scale apps. Every language and ecosystem imposes some form of performance ceiling. If performance was all that mattered, we'd all be writing assembler. It's about trade-offs: some of them technical, some of them social. .Net is a mature, stable, and performant ecosystem. You do it a disservice by rubbishing alternatives per your original comment ("Impossibly slow, just use F#"). -- EDIT: fixed spelling & grammar
lpil 2y ago
I'm sorry, I don't understand what point you're trying to make here, it seems unrelated to Gleam.