4 ms·

> Good. The longer I do this, the longer I realize that unless your in a race-to-the-bottom industry (something like vying for eye balls to increase ad spend),

> Good. The longer I do this, the longer I realize that unless your in a race-to-the-bottom industry (something like vying for eye balls to increase ad spend), then this is categorically a bad thing. It's not that simple. I realize this may be uncommon, but it's possible to work on a product that is truly worthwhile, that improves peoples' lives, and whose target users urgently need a solution to the problem you're solving. I recently developed a product that I believe meets this description (I won't plug it here). I chose Elixir for the web application. While I think that's a defensible choice, given the real-time nature of the application, I sometimes wonder if I would have been better off choosing a more mainstream language -- one with an official Stripe client library, for one thing. Any day I spent unnecessarily reimplementing something because I chose Elixir is a day that the target users couldn't benefit from my product. And, bearing that in mind, I should get back to work.

aszen 5y ago
In a more mainstream language, while it may have a few Stripe client libraries but if your true use case of being real time isn't full filled then it makes no sense to choose them. A working stripe client takes at most a day to write, compared to years that can go in changing the architecture of your application
- WJW 5y ago
  If you have enough talent that a good quality Stripe integration takes only a day to write, bending Rails or Laravel to serve websockets is not going to take more than a few days to write either. The true pain of non-standard languages is not in having to implement any specific dependency yourself but in having to reimplement a few dozen trivial-but-not-easy things yourself. It's a death by a hundred small cuts.
  - aszen 5y ago
    On the one hand u r writing a wrapper over an already well specified rest api of stripe and on the other hand u need to modify a programming language runtime to be faster and reliable for real time operations. I'm not sure these tasks are really comparable in any way. Choosing non-popular languages is a trade off yes but not as much as people think especially if you have a good team willing to learn them. There are also benefits apart from technical ones like better job retention and attracting finer talent without having to filter hundreds of resumes. I will say if your business is made around hiring and making anyone work of the shelf then it's a bad idea.
xupybd 5y ago
I've worked on, and am working on projects that are dying because the libraries that were added are now out of date. It gets really hard to maintain after 10 - 15 years. I wish we had rolled our own libraries for some of the simpler functions. Even in PHP this would have made life so much better.

aszen 5y ago

In a more mainstream language, while it may have a few Stripe client libraries but if your true use case of being real time isn't full filled then it makes no sense to choose them. A working stripe client takes at most a day to write, compared to years that can go in changing the architecture of your application

WJW 5y ago
If you have enough talent that a good quality Stripe integration takes only a day to write, bending Rails or Laravel to serve websockets is not going to take more than a few days to write either. The true pain of non-standard languages is not in having to implement any specific dependency yourself but in having to reimplement a few dozen trivial-but-not-easy things yourself. It's a death by a hundred small cuts.
- aszen 5y ago
  On the one hand u r writing a wrapper over an already well specified rest api of stripe and on the other hand u need to modify a programming language runtime to be faster and reliable for real time operations. I'm not sure these tasks are really comparable in any way. Choosing non-popular languages is a trade off yes but not as much as people think especially if you have a good team willing to learn them. There are also benefits apart from technical ones like better job retention and attracting finer talent without having to filter hundreds of resumes. I will say if your business is made around hiring and making anyone work of the shelf then it's a bad idea.

xupybd 5y ago

I've worked on, and am working on projects that are dying because the libraries that were added are now out of date. It gets really hard to maintain after 10 - 15 years. I wish we had rolled our own libraries for some of the simpler functions. Even in PHP this would have made life so much better.