4 ms·

While I applaud creating documentation, books, and guides for those new to the language, there's still a significant accessibility gap in resources. I already k

While I applaud creating documentation, books, and guides for those new to the language, there's still a significant accessibility gap in resources. I already know the language, I've already done some basic stuff in phoenix, I've even made my own HTTP API wrapper as its own library. But when it comes to architecting backend systems that aren't tied to phoenix or playing around with IEx, I really feel like I am on my own. There are erlang books, of which I am reading, though it feels like there's always emphasis on history for backwards compatibility and the other warts that Erlang has with its age. I'd like to design reliable systems that operate outside of the classic HTTP -> Elixir -> Database pattern. Things that involve working in memory, processing queues, managing sessions and state, patterns for fallbacks and breakers for services, and so on, that is where I seek more content. Unfortunately I hear the big BEAM player around, Basho, is shutting the lights--so I can't expect to witness the wonderful presentations their engineers provide at conferences or through recordings of such conferences.

tarr11 9y ago
Found this post from June about Basho. https://news.ycombinator.com/item?id=14621359 https://news.ycombinator.com/item?id=14621359
- lostcolony 9y ago
  It's very definitely dead. https://www.theregister.co.uk/2017/07/31/end_of_the_road_for_basho_as_court_puts_biz_into_receivership/ https://www.theregister.co.uk/2017/07/31/end_of_the_road_for...
jah 9y ago
I feel that Erlang adoption is probably the most realistic growth path for most serious Elixir developers. All of these topics you mentioned (breakers, message routing, etc) have been discussed and developed in the Erlang community for years. The only new thing that Elixir brings to the table in these areas is abstraction and syntax - both of which are arguably not needed in large complex systems. Source: full-time Erlang developer of 7 years who spent a full year coding Elixir in its v1.0.x days
- amorphid 9y ago
  I told myself I'd avoid Erlang at all costs. Then I decided I needed to know how leex and yecc work, so I got down and dirty w/ Erlang. It's close enough to Elixir that I can stumble through my way through it.
- ams6110 9y ago
  Just the reply I was looking for. I do not have your years of Erlang experience but I've done enough to think I have a feel for the language itself as well as the fundamentals of OTP. I've looked at Elixir and my feeling is that "it's probably great if you're coming from Ruby but what's the point if you're already invested in Erlang?" Perversely, I actually like Erlang syntax too.
  - passer-by-123 9y ago
    As many others said in the thread, forget about the relationship between Ruby and Elixir, and give Elixir a try. It is much more than syntax: structs, protocols, the test framework, documentation, tooling... even the new error messages and debugger make a big difference on every day development. There are reasons for picking Erlang over Elixir but if the reason is that "Elixir does not offer anything beyond syntax", it is likely the person has not been paying much attention.
    - didibus 9y ago
      Yup, I actually hate the Elixir syntax. I've never been a fan of ruby syntax. Granted I find the elixir syntax a step up on ruby. Anyways, Elixir is nice because of its abstractions. While I understand most people come to it from ruby for its familiar syntax.
- 59nadir 9y ago
  Learning how the BEAM works and the architectural decisions that make sense for running your system on it is the realistic growth path for any serious BEAM developer. This has nothing to do with any of the languages on the BEAM, but with what makes sense on the VM. Your assertion that abstraction is somehow not needed in "large complex systems" (this being completely undefinable, by the way) seems silly and I can refute it with about as many objective reasons as I suspect you have for making that comment. Our current code base would be significantly shorter if we used Elixir (on the order of 50% less code, conservatively approximated) and is an absolute bitch to spelunk in specifically because it's just Erlang. There is no reason to create a new project in Erlang (instead of Elixir/LFE) outside of reasons like handing it off to clients or the like and the focus should never be on learning Erlang, but on the BEAM. Any knowledge gained through that is trivially used in one of the more productive languages on the BEAM.
lojack 9y ago
Definitely recommend reading "The Little Elixir & OTP Guidebook" The focus of the book sounds like pretty much what you're asking for. The first few chapters cover Elixir basics, but its really just a primer -- easily skippable if you already know it. Starts with implementing OTP features from scratch so you can see what they do and why they exist, then dives into how to do it using OTP.
deleted 9y ago
[deleted]
rdtsc 9y ago
> I'd like to design reliable systems that operate outside of the classic HTTP -> Elixir -> Database pattern. Then use Erlang. I like and prefer Erlang to Elixir for example. It has a simpler syntax, it's consistent just like Elixir. And you'd be surprised that Erlang for being what 30 years old is being regularly updated and improved Most importantly things are deprecated regularly from the the language and the standard library, as new stuff is added. That's how it managed to still say small and simple. Plus you'll get a lot of resources and reference already created for it. If you like Elixir, start with it as so many concepts overlap and then you'd pick the Erlang syntax and some conventions later without that much hassle.
bitwalker 9y ago
I'm actually working on a book which I think covers a lot of what you're looking for (and was what I wanted back when I got started with Elixir a few years ago). I'm covering architectural patterns for the items you mentioned as well as flow control and digging in deep on how to really leverage the fault isolation mechanisms of OTP. I'm the maintainer of Distillery, the release tooling in Elixir, so I'm also covering a lot of the gritty details involved there, such as how to work with hot upgrades and such, as well as dealing with issues in production using some of the excellent operational tooling available. Unfortunately I probably won't be done until the end of this month, but if you're interested, keep an eye out on ElixirForum.com, since I'll announce it there when it's available.
- Hates_ 9y ago
  Do you have a mailing list I can sign up to to stay notified?
  - bitwalker 9y ago
    I don't yet, as I've been pretty heads down. I'll put one together this week and reply back once it's up.
- cordite 9y ago
  I echo what Hates_ says, do you have a mailing list so that I may also be notified when things come out?
  - bitwalker 9y ago
    I hope you don't mind if I just copy my reply to Hates_: "I don't yet, as I've been pretty heads down. I'll put one together this week and reply back once it's up." I'll make sure to write back to you both :)
    - cordite 9y ago
      Thank you!

tarr11 9y ago

Found this post from June about Basho. https://news.ycombinator.com/item?id=14621359 https://news.ycombinator.com/item?id=14621359

lostcolony 9y ago
It's very definitely dead. https://www.theregister.co.uk/2017/07/31/end_of_the_road_for_basho_as_court_puts_biz_into_receivership/ https://www.theregister.co.uk/2017/07/31/end_of_the_road_for...

jah 9y ago

I feel that Erlang adoption is probably the most realistic growth path for most serious Elixir developers. All of these topics you mentioned (breakers, message routing, etc) have been discussed and developed in the Erlang community for years. The only new thing that Elixir brings to the table in these areas is abstraction and syntax - both of which are arguably not needed in large complex systems. Source: full-time Erlang developer of 7 years who spent a full year coding Elixir in its v1.0.x days

amorphid 9y ago
I told myself I'd avoid Erlang at all costs. Then I decided I needed to know how leex and yecc work, so I got down and dirty w/ Erlang. It's close enough to Elixir that I can stumble through my way through it.
ams6110 9y ago
Just the reply I was looking for. I do not have your years of Erlang experience but I've done enough to think I have a feel for the language itself as well as the fundamentals of OTP. I've looked at Elixir and my feeling is that "it's probably great if you're coming from Ruby but what's the point if you're already invested in Erlang?" Perversely, I actually like Erlang syntax too.
- passer-by-123 9y ago
  As many others said in the thread, forget about the relationship between Ruby and Elixir, and give Elixir a try. It is much more than syntax: structs, protocols, the test framework, documentation, tooling... even the new error messages and debugger make a big difference on every day development. There are reasons for picking Erlang over Elixir but if the reason is that "Elixir does not offer anything beyond syntax", it is likely the person has not been paying much attention.
  - didibus 9y ago
    Yup, I actually hate the Elixir syntax. I've never been a fan of ruby syntax. Granted I find the elixir syntax a step up on ruby. Anyways, Elixir is nice because of its abstractions. While I understand most people come to it from ruby for its familiar syntax.
59nadir 9y ago
Learning how the BEAM works and the architectural decisions that make sense for running your system on it is the realistic growth path for any serious BEAM developer. This has nothing to do with any of the languages on the BEAM, but with what makes sense on the VM. Your assertion that abstraction is somehow not needed in "large complex systems" (this being completely undefinable, by the way) seems silly and I can refute it with about as many objective reasons as I suspect you have for making that comment. Our current code base would be significantly shorter if we used Elixir (on the order of 50% less code, conservatively approximated) and is an absolute bitch to spelunk in specifically because it's just Erlang. There is no reason to create a new project in Erlang (instead of Elixir/LFE) outside of reasons like handing it off to clients or the like and the focus should never be on learning Erlang, but on the BEAM. Any knowledge gained through that is trivially used in one of the more productive languages on the BEAM.

lojack 9y ago

Definitely recommend reading "The Little Elixir & OTP Guidebook" The focus of the book sounds like pretty much what you're asking for. The first few chapters cover Elixir basics, but its really just a primer -- easily skippable if you already know it. Starts with implementing OTP features from scratch so you can see what they do and why they exist, then dives into how to do it using OTP.

deleted 9y ago

[deleted]

rdtsc 9y ago

> I'd like to design reliable systems that operate outside of the classic HTTP -> Elixir -> Database pattern. Then use Erlang. I like and prefer Erlang to Elixir for example. It has a simpler syntax, it's consistent just like Elixir. And you'd be surprised that Erlang for being what 30 years old is being regularly updated and improved Most importantly things are deprecated regularly from the the language and the standard library, as new stuff is added. That's how it managed to still say small and simple. Plus you'll get a lot of resources and reference already created for it. If you like Elixir, start with it as so many concepts overlap and then you'd pick the Erlang syntax and some conventions later without that much hassle.

bitwalker 9y ago

I'm actually working on a book which I think covers a lot of what you're looking for (and was what I wanted back when I got started with Elixir a few years ago). I'm covering architectural patterns for the items you mentioned as well as flow control and digging in deep on how to really leverage the fault isolation mechanisms of OTP. I'm the maintainer of Distillery, the release tooling in Elixir, so I'm also covering a lot of the gritty details involved there, such as how to work with hot upgrades and such, as well as dealing with issues in production using some of the excellent operational tooling available. Unfortunately I probably won't be done until the end of this month, but if you're interested, keep an eye out on ElixirForum.com, since I'll announce it there when it's available.

Hates_ 9y ago
Do you have a mailing list I can sign up to to stay notified?
- bitwalker 9y ago
  I don't yet, as I've been pretty heads down. I'll put one together this week and reply back once it's up.
cordite 9y ago
I echo what Hates_ says, do you have a mailing list so that I may also be notified when things come out?
- bitwalker 9y ago
  I hope you don't mind if I just copy my reply to Hates_: "I don't yet, as I've been pretty heads down. I'll put one together this week and reply back once it's up." I'll make sure to write back to you both :)
  - cordite 9y ago
    Thank you!