Hacker Newsnew | past | comments | ask | show | jobs | submit | poisonta's commentslogin

Phoenix needs an ActiveRecord-like database abstraction layer. Many Rails developers try Phoenix at some point because they may need better performance. They’re so accustomed to the Rails structure that they assume Rails has done everything right. However, Ecto and ActiveRecord are two very different beasts. When Rails developers try out Ecto, they often feel there’s too much boilerplate and believe the Rails design is much more intuitive. This, I think, is one reason Phoenix struggles to attract Rails developers. If it can’t please Rails users, it will rarely appeal to others.


The Ash framework is a data abstraction layer you light want to check out, although I'm not familiar with Rails/ActiveRecord to tell if it's closer to what they're after.


Elixir is a great language, but it lacks a framework as polished and full-featured as Rails. Phoenix could have been far more popular if it had something like Active Record.


Many Rails developers try Phoenix at some point because they may need better performance. They’re so accustomed to the Rails structure that they assume Rails has done everything right. However, Ecto and ActiveRecord are two very different beasts. When Rails developers try out Ecto, they often feel there’s too much boilerplate and believe the Rails design is much more intuitive. This, I think, is one reason Phoenix struggles to attract Rails developers. If it can’t please Rails users, it will rarely appeal to others.


Ecto


Ecto was literally the component I liked less in all the Phoenix stack when I worked with it after a dozen of years of Rails.

I did maybe 5 years of Phoenix for a customer of mine and went back to Rails for another customer. It's good enough and overall Rails is easier to deploy IMHO. Capistrano vs I don't remember what.


Oh man, this must just be subjective because I find Ecto to be beautiful compared to the absolute trainwreck of Activerecord. Having compile time guarantees through Ecto is wonderful.


Yes, that must be the case because if my customers and I would care about compile time guarantees we would not be working with Ruby.

In that years long Phoenix project one of the developers on the team added dialyzer type annotations to the functions in the files he worked on. Everybody else did not bother. The project ended up with no type checking. The service run and the company did well.

Overall using Phoenix was a good experience. I never used Elixir in any other project and never for my own programs. I use several other languages for my own little scripts, mainly bash, Ruby, Python and Lua. I think that I really like dynamic typing.


Not a fan of anything Google does these days.


I can sense why it didn’t go to tenderlovemaking.com


I think tenderworks wrote this post.


I'm curious whether the success of Google in launching software that seems not fully developed can be attributed to their Site Reliability Engineering (SRE) practices.


Not really, the company is massive and until recently very motivated (promo) to launch new things. SREs probably helped get things across the finish line but likely didn't start those projects.


> Not really, the company is massive and until recently very motivated (promo) to launch new things.

What changed?


Layoffs and a change in the performance management system (moving away from perf).


> change in the performance management system (moving away from perf)

This sounds... confusing. They moved away from performance?


this is a dumb comment, but yes, part of the role of SREs was helping people make (and then implement) trade-offs around system deployment while deploying things that basically worked as intended.


As I understand it (from friends who were SREs in the 2010s) the really clever bit was that projects basically had a budget for "how much SRE attention your deployment needed" - so there was payoff for getting more deployment details right the first time, and structural pushback for just throwing things over the wall. Sounded like an interesting way to connect up the levers...


It seems that there may be issues with accountability within their development teams. The reliability of Google Cloud is in question, as encountering 500 errors appears to be a frequent problem. It has been observed that if one persists in retrying a request, it may eventually succeed. This suggests that their teams may have an error budget and might not take action until the issue is flagged by their Site Reliability Engineering (SRE) team.


Anybody willing to start an Upwork alternative?


I tried to start one, with the concept being that it would be free and run by participants. It was almost completely ignored. I think people just didn't see many posts on it and decided it wasn't popular or something.

I think part of the issue was just that the website didn't look cool enough. It looked fine to me but I think that people judge things in a very shallow way.


> people just didn't see many posts on it and decided it wasn't popular

Were they wrong? If there were not many posts, it wasn't popular.


Implied by that was "and so everyone should ignore it until it becomes popular". If you can see the implication of that.


So, they have services than engineers - 4000+ services and 3000 engineers? So, some services don't have maintainers?


I think you have not used Webex, Bluejeans and others.


I only like Clouflare as a security company.


I wish gyms had similar legislation.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: