6 ms·

Elixir is decent and I've worked with it a fair amount in production systems... Mostly Rubyists seem to really click with it. And ruby idioms are all over it -

Elixir is decent and I've worked with it a fair amount in production systems... Mostly Rubyists seem to really click with it. And ruby idioms are all over it - you can taste its history and proximity to ruby's ecosystem. As a scala dev that ended up working with elixir for a couple years, my opinion is that a typesafe elixir-like language would really bring BEAM back into the mainstream. Akka is alright but it's shoehorned onto the JVM. BEAM is good as long as you don't need to do heavy computation, but lack of type-safety (need to use dialyzer?) means that shit breaks in prod that the compiler would have caught. And yes, you can mitigate this with boatloads of testing and data-validations with ecto or whatever. But every time we broke shit that a compiler would have caught I cringed. It's a great path for rubyists to move to Elixir/BEAM and every rubyist should give it a whirl! I'm back working on scala and akka.

thomasfortes 6y ago
As someone that uses elixir for webapps and ocaml/reasonml for frontend work, I hope that https://gleam.run https://gleam.run gets traction, seems like a nice BEAM language with types that is evolving quickly.
QuinnWilton 6y ago
I want to echo Gleam [0] as a project to watch out for. It's still very early, but it's evolving quickly, and has a big focus on providing ergonomic tooling. It's an ML inspired, statically typed language that compiles down to Erlang, and supports interop with the existing ecosystem. This means that you get access to ADTs, type inference, etc, while still being able to lean on OTP for your concurrency primitives. There's also examples of calling it from Elixir, so there's the option of falling back to statically typed Gleam for an especially gnarly piece of code, and calling it from your Elixir application [1]. I wouldn't necessarily recommend this for commercial apps yet, but Gleam today is about as usable as early-Elm was, in my opinion. The project is also very welcoming to new contributors, and Louis (the language's creator) does a great job of curating a list of beginner friendly issues to tackle in the compiler. I've been spending my evenings learning Rust by adding onto the language, and it's been a ton of fun. If you want to help out, there's a fairly active IRC channel on Freenode, in #gleam-lang :) [0] https://gleam.run https://gleam.run [1] https://dev.to/contact-stack/mixing-gleam-elixir-3fe3 https://dev.to/contact-stack/mixing-gleam-elixir-3fe3
- anhari 6y ago
  I’m rooting for Gleam as well. I do wish it adopted the syntax styling of Ruby/Elixir/Crystal though. Either way, it is very compelling.
- deleted 6y ago
  [deleted]
Scramblejams 6y ago
The older I get the grumpier runtime errors make me. I want ReasonML (language!) and Erlang (OTP!) to have a baby, and I want it birthed by the Go runtime. (Go? Yeah, Go. I don't love the language, but I am a lover of low latency and garbage collection, what can I say?) Yes, there's Gleam, but if something's based on BEAM, the throughput generally won't impress. :-( Would seem a shame to do all that static typing, and then not reap the speed benefits. Relatedly, I think there's a sweet spot for a language that accepts mutability inside of actors, but only allows immutable objects to be sent as messages, with an escape hatch available if needed. (Pony explored this space, would love to see it evolve.) Combine that with OTP for happy-path programming, and an ML so you catch most of your errors at compile time, and you could end up with great throughput, low latency and great ergonomics, all at the same time.
- danielscrubs 6y ago
  I have assumed BEAM has similar latency to Go and is garbage collected? Here is some benchmarks where Erlang beats Go in throughput: https://timyang.net/programming/c-erlang-java-performance/ https://timyang.net/programming/c-erlang-java-performance/ https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixir/ https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixi...
  - Scramblejams 6y ago
    That first link is from 2009. A lot's changed since then, so I didn't read it. And maybe I missed something in the second link, but Go showed very similar I/O performance to Elixir, while consuming a boatload less CPU doing it. That's what I'm after. Open to being told I missed something, though.
    - adelarsq 6y ago
      > Open to being told I missed something, though. The Bean keep using CPU even with no work to be done, so avoid context changes. We can't compare about CPU values.
PascalW 6y ago
This 100%. Dialyzer helps a bit but is difficult to work with due to really cryptic errors. Also the workflow of having the typechecker run as a separate process not part of the compiler feels really cumbersome; it's easy not to notice you have a type error somewhere (often miles away from where the error originates!).
rapind 6y ago
I would argue that if you're looking for a simpler way to build CRUD apps, just skip the middleman and use postgREST. I've been playing with Elixir and Phoenix, and while they're pretty great I like postgREST much better. You eliminate an unnecessary (in most cases) abstraction and backing onto the grown up postgresql authorization and authentication is invaluable for securing your app. For non webapp stuff I've been happy using golang.
- moreaccountspls 6y ago
  I'd love to hear your opinion on liveview if you've played with it at all. The two ways forward for the industry I see are something like hasura/postgrest with heavy js in the frontend, or something like liveview/blazor. I'd expect the more decoupled approach to win long term, but demos like this: https://github.com/moomerman/flappy-phoenix https://github.com/moomerman/flappy-phoenix are extremely impressive.
  - ldd 6y ago
    I commented elsewhere, but I made a quick quirky game with full source code using LiveView. [0]:https://hn.lddstudios.com/ https://hn.lddstudios.com/ [1]:https://github.com/ldd/hn_comments_game/ https://github.com/ldd/hn_comments_game/ Not to share my views or anything, and I have nothing to sell about it, but I thought I would share it with people anyways

thomasfortes 6y ago

As someone that uses elixir for webapps and ocaml/reasonml for frontend work, I hope that https://gleam.run https://gleam.run gets traction, seems like a nice BEAM language with types that is evolving quickly.

QuinnWilton 6y ago

I want to echo Gleam [0] as a project to watch out for. It's still very early, but it's evolving quickly, and has a big focus on providing ergonomic tooling. It's an ML inspired, statically typed language that compiles down to Erlang, and supports interop with the existing ecosystem. This means that you get access to ADTs, type inference, etc, while still being able to lean on OTP for your concurrency primitives. There's also examples of calling it from Elixir, so there's the option of falling back to statically typed Gleam for an especially gnarly piece of code, and calling it from your Elixir application [1]. I wouldn't necessarily recommend this for commercial apps yet, but Gleam today is about as usable as early-Elm was, in my opinion. The project is also very welcoming to new contributors, and Louis (the language's creator) does a great job of curating a list of beginner friendly issues to tackle in the compiler. I've been spending my evenings learning Rust by adding onto the language, and it's been a ton of fun. If you want to help out, there's a fairly active IRC channel on Freenode, in #gleam-lang :) [0] https://gleam.run https://gleam.run [1] https://dev.to/contact-stack/mixing-gleam-elixir-3fe3 https://dev.to/contact-stack/mixing-gleam-elixir-3fe3

anhari 6y ago
I’m rooting for Gleam as well. I do wish it adopted the syntax styling of Ruby/Elixir/Crystal though. Either way, it is very compelling.
deleted 6y ago
[deleted]

Scramblejams 6y ago

The older I get the grumpier runtime errors make me. I want ReasonML (language!) and Erlang (OTP!) to have a baby, and I want it birthed by the Go runtime. (Go? Yeah, Go. I don't love the language, but I am a lover of low latency and garbage collection, what can I say?) Yes, there's Gleam, but if something's based on BEAM, the throughput generally won't impress. :-( Would seem a shame to do all that static typing, and then not reap the speed benefits. Relatedly, I think there's a sweet spot for a language that accepts mutability inside of actors, but only allows immutable objects to be sent as messages, with an escape hatch available if needed. (Pony explored this space, would love to see it evolve.) Combine that with OTP for happy-path programming, and an ML so you catch most of your errors at compile time, and you could end up with great throughput, low latency and great ergonomics, all at the same time.

danielscrubs 6y ago
I have assumed BEAM has similar latency to Go and is garbage collected? Here is some benchmarks where Erlang beats Go in throughput: https://timyang.net/programming/c-erlang-java-performance/ https://timyang.net/programming/c-erlang-java-performance/ https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixir/ https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixi...
- Scramblejams 6y ago
  That first link is from 2009. A lot's changed since then, so I didn't read it. And maybe I missed something in the second link, but Go showed very similar I/O performance to Elixir, while consuming a boatload less CPU doing it. That's what I'm after. Open to being told I missed something, though.
  - adelarsq 6y ago
    > Open to being told I missed something, though. The Bean keep using CPU even with no work to be done, so avoid context changes. We can't compare about CPU values.

PascalW 6y ago

This 100%. Dialyzer helps a bit but is difficult to work with due to really cryptic errors. Also the workflow of having the typechecker run as a separate process not part of the compiler feels really cumbersome; it's easy not to notice you have a type error somewhere (often miles away from where the error originates!).

rapind 6y ago

I would argue that if you're looking for a simpler way to build CRUD apps, just skip the middleman and use postgREST. I've been playing with Elixir and Phoenix, and while they're pretty great I like postgREST much better. You eliminate an unnecessary (in most cases) abstraction and backing onto the grown up postgresql authorization and authentication is invaluable for securing your app. For non webapp stuff I've been happy using golang.

moreaccountspls 6y ago
I'd love to hear your opinion on liveview if you've played with it at all. The two ways forward for the industry I see are something like hasura/postgrest with heavy js in the frontend, or something like liveview/blazor. I'd expect the more decoupled approach to win long term, but demos like this: https://github.com/moomerman/flappy-phoenix https://github.com/moomerman/flappy-phoenix are extremely impressive.
- ldd 6y ago
  I commented elsewhere, but I made a quick quirky game with full source code using LiveView. [0]:https://hn.lddstudios.com/ https://hn.lddstudios.com/ [1]:https://github.com/ldd/hn_comments_game/ https://github.com/ldd/hn_comments_game/ Not to share my views or anything, and I have nothing to sell about it, but I thought I would share it with people anyways