What’s the subject of episode 3?
axelson
Scenic Core Team
NobbZ
Pronounciation of @michalmuskala’s name. At least that’s what I heard on twitter 
I wasn’t able to listen to it so far. I only listen to podcasts on my daily commute, but in Germany today is a holiday and I took a day off yesterday.
1
adkron
AstonJ
Great to see another episode 
I was very eager to hear your views about the community and definitely agree about making it as accessible, welcoming and fun as possible - hopefully we have done a great job of that on this forum 
Would also like to quickly mention that there are many people who may never go to a conference or local meet-up but nevertheless can (like many of our members here on the forum, IRC or Slack) still be a big part of the community… helping shape it into something special. In many ways the online communities are the first port of call for newcomers hence us trying to be as welcoming and helpful as we can 
please don’t forget about us when talking about the community 
5
adkron
I will set a reminder to say something on the next episode, and if I don’t announce the forums I will add a link to the forums now.
4
AstonJ
Thanks Amos, though please don’t alter your schedule on our account. Perhaps if you do another similar episode about the community you could give the hardworking members of online communities, and what they do for the community, a mention
4
adkron
harlan
I’ve listened to all episodes, great stuff, really appreciate the expert knowledge on property testing among other things.
2 questions for Chris @keathley –
-
As I recall, you mentioned that Elixir has some specific technical shortcomings that are slowing it’s adoption. I’d love to hear more about what those are.
-
I appreciated the speaking tips in episode 5. I’d personally love to hear how you prepare your talks, despite your feeling that it won’t work for others – I bet it will for at least some.
Thanks, keep up the great work!
2
adkron
We will probably reach back at these things in a future episode. Today we recorded an episode about the current config proposals.
Thanks for listening.
1
keathley
Oh boy, this one is complicated and I wanna make sure I don’t come across as overly critical here 
. I’ll preface all of this by saying that these aren’t my complaints as much as they are things I’ve heard from clients and such. Also a lot of these “issues” are being worked on so maybe they won’t be limitations for much longer. Basically no one needs to feel compelled to correct me or explain how these are non-issues. I’m just a messenger and these are criticisms people have presented me with . I promise that I’ve done my share of arguing on the side of elixir. With that disclaimer out of the way here’s the stuff that comes up:
- Configuration. Obviously being worked on but figuring out how to tie into existing config systems like vault / etcd / etc. is non-obvious
- Deployment. Also being worked on. Currently, deploying elixir is a bit of a free for all. Some people build releases. Some just use mix. Some people deploy with git. Sometimes docker is involved. Sometimes people use hot code reloads. Contrast this with putting a rails app in a docker container, building a binary with Go, or building a jar in java and it feels less standardized and less obvious what the “right” thing to do is. Many new people feel paralyzed by choice.
- “Why do I need Erlang when I have gRPC” - When people need distribution there are now standard tools like grpc for cross node communication. This is often easier to adopt in an existing stack then picking up a new language. Not to say that we can’t use gRPC from elixir. Just that it removes one of the marketing bullet points. Its very similar to other popular question I get…
- “Why do I need X when I have Kubernetes?” - I’ve been presented with this rebuttal for practically all of the features that I love about elixir. Concurrency, fault tolerance, “scalability”, you name it and (apparently) k8s can solve it all. Honestly, I’m not sure how to fix this from a marketing perspective. I think its hard for people to see the benefits until they’ve actually used the tools.
- Robust “2nd tier” libraries - I’m not sure how to describe this correctly. I’m not trying to place a value judgement by using the term “2nd tier”. I just mean libraries that are less general to all problems and are thus less popular. Once you get past Phoenix, Ecto, etc. there’s just less usage and less support for the other libraries in the ecosystem. For instance, I had a client choose to use a ruby kafka library over an elixir library because it was getting updates for new kafka features faster and was backed by a large company. I think this is a factor of the size of the community so I’m not sure if there is a good solution here.
- “The BEAM is slow” - This comes up a LOT and leads people to choose runtimes like Go or the JVM over the BEAM. I think we need to do a better job of marketing around this point. There are plenty of ways to make a BEAM application fast (or at least fast enough) whether its nifs, ports, hype, etc. Efforts like https://www.elixirbench.org are a really good step in that direction. Another really obvious thing (as silly as it is) would be our techempower benchmarks. I’ve seen elixir tossed out of contention because of those dumb things. That’s not glamorous work but elixir is still a niche language and these sorts of things are low-hanging fruit that do have an impact. Removing that sorta negative marketing can’t really be bad.
A bunch of people have asked me for this so I’m going to try to write something up on my blog. I’ll be sure to post here when its finished.
4