2 ms·

Some posts on HN are meant for people who actually like to build the tools upon which future app or backend dev will build end-user software. I think this is th

by bsaul 7y ago

Some posts on HN are meant for people who actually like to build the tools upon which future app or backend dev will build end-user software. I think this is this kind of post.

xrd 7y ago
Totally fair point. But, not at all an answer to my question. To you, does my question about Nim seem out of line?
- bsaul 7y ago
  If you're asking why you got downvoted (i didn't downvote you), i think it's because of the weird phoenix/elixir vs react/js comparison, together with wondering what nim brings to the table. It all seemed very confused, a bit like comparing apples to oranges. But that's just my opinion.
  - abledon 7y ago
    I think when they compare phoenix/elixir to react/js maybe they are incorporating LiveView into the equation, as it allows SPA like ability through a backend LiveView template.
  - xrd 7y ago
    That makes sense. I wasn't attempting to compare these technologies at all. I was suggesting that when I look at a new technology, I like to think of what's there currently and then ask what this new stack brings that I can't already do with the existing stacks. Phoenix/Elixir seems like it permits solutions that might be 10x better than the existing solutions in that space. Agree 100% that this space I'm referring to is NOT Android. I was just attempting to explain how I make a decision to spend the time to understand a new stack and why I do or don't. Am I totally off base stating that Phoenix/Elixir is used in the same places React is? thoughbot wrote a piece about that: https://thoughtbot.com/blog/how-we-replaced-react-with-phoenix https://thoughtbot.com/blog/how-we-replaced-react-with-phoen... But, I'm curious why you think this is weird? Care to elaborate?
    - bsaul 7y ago
      "Am I totally off base stating that Phoenix/Elixir is used in the same places React is?" There are so many things to consider when deciding upon an architecture that the choice of going SPA + "regular" backend tech (js, php, whatever) vs something as specific as phoenix + elixir + server side rendering is really not a matter of "react" or something else. A few questions you'll have to ask : what if you want to add a mobile GUI, will you want to keep rendering everything on the server ? How will you fetch the data ? Should the GUI (either mobile or web) work offline ? If you go mobile will you want to benefit from reusing react patterns ? Now purely on the server side, erlang VM is highly optimized for concurrency (and not so much at pure cpu), but elixir is also a very peculiar language. How will you recruit people ? Is your team used to functional programming ? Do you have the skills to go to C programming in case you need performance ? Then comes deployment. Will you plan on using OTP and actor-based architecture, for maximum availability ? Do you want to deploy on google cloud using kubernetes ? Heroku ? App-engine ? Each of these options have implications on your stack. etc, etc. I could go on forever. The post you mentionned only talked about the most basic thing every single tech has been able to do for the last 30 years, aka : render a web page from a template. But that's a very very narrow consideration for picking a tech stack.

by bsaul 7y ago

Some posts on HN are meant for people who actually like to build the tools upon which future app or backend dev will build end-user software. I think this is this kind of post.

xrd 7y ago

Totally fair point. But, not at all an answer to my question. To you, does my question about Nim seem out of line?

bsaul 7y ago
If you're asking why you got downvoted (i didn't downvote you), i think it's because of the weird phoenix/elixir vs react/js comparison, together with wondering what nim brings to the table. It all seemed very confused, a bit like comparing apples to oranges. But that's just my opinion.
- abledon 7y ago
  I think when they compare phoenix/elixir to react/js maybe they are incorporating LiveView into the equation, as it allows SPA like ability through a backend LiveView template.
- xrd 7y ago
  That makes sense. I wasn't attempting to compare these technologies at all. I was suggesting that when I look at a new technology, I like to think of what's there currently and then ask what this new stack brings that I can't already do with the existing stacks. Phoenix/Elixir seems like it permits solutions that might be 10x better than the existing solutions in that space. Agree 100% that this space I'm referring to is NOT Android. I was just attempting to explain how I make a decision to spend the time to understand a new stack and why I do or don't. Am I totally off base stating that Phoenix/Elixir is used in the same places React is? thoughbot wrote a piece about that: https://thoughtbot.com/blog/how-we-replaced-react-with-phoenix https://thoughtbot.com/blog/how-we-replaced-react-with-phoen... But, I'm curious why you think this is weird? Care to elaborate?
  - bsaul 7y ago
    "Am I totally off base stating that Phoenix/Elixir is used in the same places React is?" There are so many things to consider when deciding upon an architecture that the choice of going SPA + "regular" backend tech (js, php, whatever) vs something as specific as phoenix + elixir + server side rendering is really not a matter of "react" or something else. A few questions you'll have to ask : what if you want to add a mobile GUI, will you want to keep rendering everything on the server ? How will you fetch the data ? Should the GUI (either mobile or web) work offline ? If you go mobile will you want to benefit from reusing react patterns ? Now purely on the server side, erlang VM is highly optimized for concurrency (and not so much at pure cpu), but elixir is also a very peculiar language. How will you recruit people ? Is your team used to functional programming ? Do you have the skills to go to C programming in case you need performance ? Then comes deployment. Will you plan on using OTP and actor-based architecture, for maximum availability ? Do you want to deploy on google cloud using kubernetes ? Heroku ? App-engine ? Each of these options have implications on your stack. etc, etc. I could go on forever. The post you mentionned only talked about the most basic thing every single tech has been able to do for the last 30 years, aka : render a web page from a template. But that's a very very narrow consideration for picking a tech stack.