4 ms·

Hey there! I'm the Co-founder of Steer and the Maker of Transparent Startups. This platform is 100% built with Elixir and the Phoenix Framework. I can proudly

Hey there! I'm the Co-founder of Steer and the Maker of Transparent Startups. This platform is 100% built with Elixir and the Phoenix Framework. I can proudly say it's a blazing fast application. I cannot be happier with the performance and productivity achieved with Elixir. I highly recommended it for your brand new projects. :) I'd love to hear your thoughts. Cheers, Rafa

k__ 10y ago
Using a framework for thousands of real-time connections for weekly reports? Seems like over engineering to the max. :D On the other hand they call it the hipster stack, so well done, I guess?
- rafapaez 10y ago
  I disagree. Over engineering does not relate to a particular framework. In fact, you can over-engineer with any tech. It's the design of the system what defines that (e.g microservices vs monolith for a small web app). It's a simple monolithic application with a relational database. Does this sound like over engineering? I don't think so. It's actually the opposite. Which one seems like an overkill, Server A or Server B (https://pbs.twimg.com/media/CngB1sfWIAAbOFi.jpg https://pbs.twimg.com/media/CngB1sfWIAAbOFi.jpg)? ;)
  - k__ 10y ago
    So you're implying that a simple service that could be implemented with Sinatra should not be considered over engineered because the dev tried to hammer on the problem with Rails? Background: Just today I read that DHH considered Phoenix pretty cool, but Rails is enough if you don't need the real-time features. Anyway, of course you can build your services how you like and it's probably a lot fun to use Phoenix :D
    - rafapaez 10y ago
      - If I have to choose a Ruby tech, I would go for Rails, no Sinatra, no Padrino, nop. Whatever you think is simple now it will change in the future. So start with what you know well and has everything you might need, even if you're not using it now. I've seen many "small" services being rewritten in Rails for this reason and that's painful and a waste of resources. - Nowadays I have several reasons not to use Rails for new projects (https://blog.jaredfriedman.com/2015/09/15/why-i-wouldnt-use-rails-for-a-new-company/ https://blog.jaredfriedman.com/2015/09/15/why-i-wouldnt-use-...). But I actually I have more reasons to use Elixir instead (https://medium.com/@kenmazaika/why-im-betting-on-elixir-7c8f847b58#.guroqbfmf https://medium.com/@kenmazaika/why-im-betting-on-elixir-7c8f...) (http://blog.carbonfive.com/2016/04/19/elixir-and-phoenix-the-future-of-web-apis-and-apps/ http://blog.carbonfive.com/2016/04/19/elixir-and-phoenix-the...). And yes, it's fun, incredibly robust and scalable. :D

k__ 10y ago

Using a framework for thousands of real-time connections for weekly reports? Seems like over engineering to the max. :D On the other hand they call it the hipster stack, so well done, I guess?

rafapaez 10y ago
I disagree. Over engineering does not relate to a particular framework. In fact, you can over-engineer with any tech. It's the design of the system what defines that (e.g microservices vs monolith for a small web app). It's a simple monolithic application with a relational database. Does this sound like over engineering? I don't think so. It's actually the opposite. Which one seems like an overkill, Server A or Server B (https://pbs.twimg.com/media/CngB1sfWIAAbOFi.jpg https://pbs.twimg.com/media/CngB1sfWIAAbOFi.jpg)? ;)
- k__ 10y ago
  So you're implying that a simple service that could be implemented with Sinatra should not be considered over engineered because the dev tried to hammer on the problem with Rails? Background: Just today I read that DHH considered Phoenix pretty cool, but Rails is enough if you don't need the real-time features. Anyway, of course you can build your services how you like and it's probably a lot fun to use Phoenix :D
  - rafapaez 10y ago
    - If I have to choose a Ruby tech, I would go for Rails, no Sinatra, no Padrino, nop. Whatever you think is simple now it will change in the future. So start with what you know well and has everything you might need, even if you're not using it now. I've seen many "small" services being rewritten in Rails for this reason and that's painful and a waste of resources. - Nowadays I have several reasons not to use Rails for new projects (https://blog.jaredfriedman.com/2015/09/15/why-i-wouldnt-use-rails-for-a-new-company/ https://blog.jaredfriedman.com/2015/09/15/why-i-wouldnt-use-...). But I actually I have more reasons to use Elixir instead (https://medium.com/@kenmazaika/why-im-betting-on-elixir-7c8f847b58#.guroqbfmf https://medium.com/@kenmazaika/why-im-betting-on-elixir-7c8f...) (http://blog.carbonfive.com/2016/04/19/elixir-and-phoenix-the-future-of-web-apis-and-apps/ http://blog.carbonfive.com/2016/04/19/elixir-and-phoenix-the...). And yes, it's fun, incredibly robust and scalable. :D