5 ms·

I'm really looking forward for Hamler lang to become mature and popular https://github.com/hamler-lang/hamler https://github.com/hamler-lang/hamler It's based

by k_bx 6y ago

I'm really looking forward for Hamler lang to become mature and popular https://github.com/hamler-lang/hamler https://github.com/hamler-lang/hamler It's based on PureScript, which has a great reputation, but adds all the benefits of Erlang.

brightball 6y ago
Running on the Erlang VM and all the benefits of Erlang aren’t the same thing. Erlang itself is based on a very carefully constructed set of trade offs. You don’t add something without giving up something else.
- dnautics 6y ago
  As long as you give an escape hatch to access the Erlang VM, the rest is somewhat superficial. I am way more productive in Elixir than I am in Erlang, but that's probably because of the way my brain is wired. > very carefully constructed set of trade offs But also the VM has changed since 1980 (for example there are maps now) and the programming ecosystem has changed (we know what drives productivity in terms of how to effectively test, document, deploy, good documentation > separate header files), we also know more about things like how lexical metaprogramming is maybe not the best idea for IDEs or language servers, it's really tough to say that Erlang got everything right for time immemorial. And on some things Erlang hasn't moved yet (thankfully it seems like there's movement in documentation).
  - brightball 6y ago
    True, I’m mainly talking about stronger types. It’s something people have asked for a lot and generally the trade offs aren’t taken into account. Elixir aimed for 100% Erlang compatibility.
- k_bx 6y ago
  Sorry, I mostly meant the VM/platform, not the Erlang language. I assume it'll give all the great features like process trees (with dependencies), introspection, logging, discoverability and other tools that make it great for distributed programming.
  - brightball 6y ago
    The language itself brings most of that. The biggest thing that the BEAM provides is a preemptive scheduler to ensure that you can run millions of concurrent processes without any one of them dominating the CPU resources, ensuring consistent performance regardless of load. It also provides minuscule overhead for each process so that creating a supervising process for every item isn't really a cost. When you start talking distribution across nodes and hot loading code, that's where static typing starts to really bite you back because you don't have any way to enforce it across nodes or during a hot loading transition.
    - k_bx 6y ago
      > When you start talking distribution across nodes and hot loading code, that's where static typing starts to really bite you back because you don't have any way to enforce it across nodes or during a hot loading transition. I agree, the status quo is that static typing often gives you more of a headache than profit. But I think that it actually could be the other way around, we just need to start thinking backwards-compatibility-first static typing, and it looks like an exciting area to explore.
cpursley 6y ago
There's a few neat projects moving in this direction: https://github.com/purerl/purerl https://github.com/purerl/purerl https://github.com/gleam-lang/gleam https://github.com/gleam-lang/gleam https://github.com/wende/elchemy https://github.com/wende/elchemy
- k_bx 6y ago
  Nice! I don't know Erlang world very well, but the person I know (N2O author) for some reason puts his money on Hamler and says that the author is known for successful projects including https://github.com/emqx/emqx https://github.com/emqx/emqx Other than that – whoever wins :)

by k_bx 6y ago

brightball 6y ago

Running on the Erlang VM and all the benefits of Erlang aren’t the same thing. Erlang itself is based on a very carefully constructed set of trade offs. You don’t add something without giving up something else.

dnautics 6y ago
As long as you give an escape hatch to access the Erlang VM, the rest is somewhat superficial. I am way more productive in Elixir than I am in Erlang, but that's probably because of the way my brain is wired. > very carefully constructed set of trade offs But also the VM has changed since 1980 (for example there are maps now) and the programming ecosystem has changed (we know what drives productivity in terms of how to effectively test, document, deploy, good documentation > separate header files), we also know more about things like how lexical metaprogramming is maybe not the best idea for IDEs or language servers, it's really tough to say that Erlang got everything right for time immemorial. And on some things Erlang hasn't moved yet (thankfully it seems like there's movement in documentation).
- brightball 6y ago
  True, I’m mainly talking about stronger types. It’s something people have asked for a lot and generally the trade offs aren’t taken into account. Elixir aimed for 100% Erlang compatibility.
k_bx 6y ago
Sorry, I mostly meant the VM/platform, not the Erlang language. I assume it'll give all the great features like process trees (with dependencies), introspection, logging, discoverability and other tools that make it great for distributed programming.
- brightball 6y ago
  The language itself brings most of that. The biggest thing that the BEAM provides is a preemptive scheduler to ensure that you can run millions of concurrent processes without any one of them dominating the CPU resources, ensuring consistent performance regardless of load. It also provides minuscule overhead for each process so that creating a supervising process for every item isn't really a cost. When you start talking distribution across nodes and hot loading code, that's where static typing starts to really bite you back because you don't have any way to enforce it across nodes or during a hot loading transition.
  - k_bx 6y ago
    > When you start talking distribution across nodes and hot loading code, that's where static typing starts to really bite you back because you don't have any way to enforce it across nodes or during a hot loading transition. I agree, the status quo is that static typing often gives you more of a headache than profit. But I think that it actually could be the other way around, we just need to start thinking backwards-compatibility-first static typing, and it looks like an exciting area to explore.

cpursley 6y ago

There's a few neat projects moving in this direction: https://github.com/purerl/purerl https://github.com/purerl/purerl https://github.com/gleam-lang/gleam https://github.com/gleam-lang/gleam https://github.com/wende/elchemy https://github.com/wende/elchemy

k_bx 6y ago
Nice! I don't know Erlang world very well, but the person I know (N2O author) for some reason puts his money on Hamler and says that the author is known for successful projects including https://github.com/emqx/emqx https://github.com/emqx/emqx Other than that – whoever wins :)