No problem, I’d just like to see the discussion continue

Hooray! Please keep the trend alive.

This talk didn’t speak to me directly too much, just because I have essentially zero experience with Go. That said, I could appreciate that it was a technically well constructed talk. I really love the lengths Veronica went to not to throw shade at either side.

Thanks for picking up the slack.

Veronica touched very briefly on a key metric/indicator when she mentioned she had started a side web project in Go but never completed it vs being able to complete it quickly in Elixir/Phoenix. Frankly, I wish 80% of her talk reflected why this was the case.

I am possibly discovering this the hard way, coding mostly Go, I have been flirting with Elixir on and off for the past 3 years to gauge developer velocity when crafting web applications.

I love Go and it will be a tool I reach for often, our current system is Kubernetes, Docker, gRPC, Protobufs and NSQ (message queue) to tie it all together. Thats a lot of parts and a lot of work to get going. Not to mention we’ve made our own view and database libraries, which is great now, but took a lot of time and adds up to a bit of work to onboard a new developer.

However, debugging production is painful. How many times I longed for the runtime introspection and REPL ability of the BEAM, what-makes-a-good-repl articulates very well the benefits of a tight feedback loop. When choosing Go, we had bought into the Pay-It-Forward concept, more time developing up front would gain us velocity managing and enhancing the system in production. This has held true when you know what to fix, however finding what went wrong and the state that caused it can be harrowing.

To sum it up, I think the dynamic typing, immutable data, guards, processes, supervisors, REPL and frameworks such as OTP and Phoenix/Plug offer best-in-class developer velocity for web applications with a concurrent runtime. (maybe Ecto as well, each time we have looked Elixir’s way we end up fighting Ecto one-way or the other because we love our postgres, custom types, and sql in general – but this seems to be progressing with schemaless queries, fragments, etc). But even with all those goodies, we chose Go over Elixir because it was easy to grok from Day 1.

Runtime introspection of the platform gives best-in-class debugging and maintaining and the tightest feedback look you could ask for. I think as Elixir/Phoenix continue to move forward and more people deploy production apps, its the maintainability and reliability at runtime that will attract even more adoption. I think the keynotes from the last Elixirconf are spot on and shows the community moving in a healthy direction. (sidenote: Phoenix Contexts are basically how we structure our code in any language we can, it’s not a new idea, just a good one)

Maybe this will be the year we grab Elixir by the horns and use it in anger and never look back. If so, it would be fun to share a real-life benefit analysis of Go to Elixir and how the REPL and Runtime safety over Compile time acceptance increases velocity by tightening the feedback loop.