11 ms·

Reasons to use Phoenix instead of Rails

122 points by elvio 9y ago

lettergram 9y ago
So, I've used Rails (ruby), Django (python), Flask (python) Revel (go), Spring (java), Node.js (javascript), and even have used C, php and Go to roll my own website from scratch[1]. The thing is, I've always scaled my website(s) to thousands or tens of thousands of requests and hour; with one website even getting close to a million an hour... all with no problem. In the case of Rails (as is discussed in the article), my bottleneck (from a usability perspective) is always bandwidth. Most applications (I build anyway), require a hefty amount of data. Waiting 200ms for the database + an additional 20ms for rendering, the 20ms is not noticeable. Scaling Rails (or any modern web app) is as easy as just launching another instance and load balancing. Given that, I really don't see any advantage toward Phoenix. Plus, why I personally love rails is all the gems - which is super powerful. Most other frameworks simply don't have Rails simple logic, with the easily extendable gems. [1] http://austingwalters.com/building-a-web-server-in-go-handling-page-requests/ http://austingwalters.com/building-a-web-server-in-go-handli...
- TomK32 9y ago
  Tbh, 200ms for the db is massive. I have a 100ms limit at which my mongodb writes into the slow-log. It's an almost empty log. My point being, apps can have all sorts of bottlenecks and you only have to throw the right brain at the problem to fix it, no need to replace the techstack. Yes, gems. The ecosphere in ruby is superb. I'm started working with node a lot more these days and it's a) confusing and b) small packages for all those things whatevertheycallitthesedaysscript is missing. 243 gems in my 7yr old Ruby vs 918 node modules in an app we started this month. What's Elexir/Erlang like in this respect?
  - merb 9y ago
    even for "old databases" (mysql, postgresql) 200ms is huge or to it differently say probably his database is not the bottleneck. He probably fetches big lists, and even lists with over 100 entries are extremly slow on python/rails, whatever. on java/c++/go/rust these things are way faster.
    - lettergram 9y ago
      The database doesn't need to be an issue - it just currently is. We have a fairly complex query on a several terabyte large PostgreSQL database and didn't want to spend more money. Basically, we just haven't sharded it yet, and don't want to pay for a larger machine. The point is - typically the issue isn't the web app. Almost all web frameworks are designed to be scalable from the start. Just launch another instance. Also, we do about 99 writes for every 1 read, so query times don't matter as much. For the given app I was using as an example. Network I/O and large databases are usually the bottlenecks from what I've seen consulting and developing.
    - ezekg 9y ago
      MySQL and PostgreSQL are considered “old” now? I’d guess that’s much like Rails being considered “old” and “legacy.”
    - tychver 9y ago
      This was probably true 10 years ago, but these days it's basically FUD. Since then Ruby improved performance something like 5-80x from 1.8 to 2.5 and moved from an interpreted language to a VM nearly as fast as LuaJIT. Go only has 3-5x the throughput for tasks like: grab 100 rows from PostgreSQL, serialize to JSON, respond via HTTP. Lots of the hot code in Ruby around fetching rows from the DB, serializing to JSON, and HTTP parsing have also since been implemented as native functions in C, massively improving performance with zero effort required by the developer.
      - merb 9y ago
        yeah this is cool, until you make a single map...
        tychver 9y ago
        Do you mean: "take a few thousand rows and map them to a different data structure"? Because I benchmarked that recently and mapping 16,000 rows of GPS points using haversine distance in pure Ruby takes about 12ms, and about 5ms in Go. It's not that much slower. There are tasks where Ruby can be ~100x slower than Go, but a simple map isn't one of them.
- mrisoli 9y ago
  I share your opinion, if you have any bottlenecks which are unsolvable because of Rails or Ruby being slow your app probably scaled up to a point where you have the resources to make a creative solution that is not Phoenix/Elixir. Having said that, while I don't find any major reasons to opt for Phoenix instead of Rails, my main reason to work with Elixir/Phoenix right now on side projects is that it won't make me unlearn Rails which I can always go back to, in fact, using Phoenix for a while made me miss a lot of the available libraries, plug-in solutions and wide range of community knowledge. So ATM I have more reasons to choose Rails over Phoenix, but I suppose that's why these sorts of articles are important, publicity to increase a community and fulfill Elixir's biggest need right now.
  - mooreds 9y ago
    > in fact, using Phoenix for a while made me miss a lot of the available libraries, plug-in solutions and wide range of community knowledge. This is my main reason for focusing on Rails rather than Elixir at present. The sheer breadth of gems available for rails to quickly build sophisticated applications is hard to beat for any up and coming language/framework. That said, my gut feel is that many of the developers who build and maintain these gems have moved on and that Elixir is the new hotness and will probably catch up in the next few years.
  - regulation_d 9y ago
    I wonder if you might extrapolate on which libraries, plug-in solutions you missed in Phoenix.
- phamilton 9y ago
  I mean... 1 million requests an hour isn't that many. That's around 300 requests per second. Assuming 1000ms upper bound on requests, you need 300 workers to handle that load. Assuming 150MB per worker, that's 45 GB of memory required to handle the load. So like... 5 m4.xlarge instances on EC2 (to give redundancy and allow loss of 2 hosts). That's $700/month. That's not that much. We've got a Rails app that pushes 5000 qps. And to be fair, we just dial up the number of instances and it handles it fine. It runs on over 100 instances. It costs us around $10k/month. Not the end of the world, cost wise, but we have multiple Go services that handle similar levels of traffic and run on a dozen instances. Additionally, deploys take a long time (rolling restarts plus health checks on 100 machines takes time). Moving to Go (or Elixir) allows us to handle far more requests per unit of hardware. While latency would indeed improve, it's not the primary motivator for us moving away from Rails. I haven't even mentioned the websocket story on Rails. That's a whole new can of worms.
  - meritt 9y ago
    Do rails apps actually use 150MB per worker or was that just a lofty ceiling estimate? Or is that with an app server that doesn't utilize process forking, and loses the benefit of shared libraries/heap/etc?
    - gkop 9y ago
      Yes, they often do :/
    - tychver 9y ago
      Yes, but you only need one process per core, just like NodeJS. Since 1.9 you can use real OS threads to achieve parallel IO, and certain parallel computations which can proceed without holding the Global Interpreter Lock. JRuby offers completely unrestricted threading with a single process, plus a 3x performance boost, plus the advantage of an incredible amount of work put into their VM and GC. It's a really underrated option these days. The problem with forking, is MRI Ruby is unaware what memory is actually inherited by forking, so eventually it causes the entire heap inherited from the parent to copy into the child. I'm actually working on a patch to fix this. The solution is simple, just don't mark, collect, or allocate into inherited pages, but the implementation itself is fiddly. What's really exacerbated this, is that most Linux distros now have Transparent Huge Pages turned on by default, and flipping a single bit in inherited causes a 2MB copy instead of a 4kb copy!
- sanderjd 9y ago
  My bottleneck with Rails was always memory usage. Our concurrency was always limited by how many web and task workers we could run in the amount of memory we could afford, which was not very many. It was not straightforward to optimize this and ignoring it didn't work for us, so we put lots of time into it and it changed the whole productivity argument for Rails.
  - 33degrees 9y ago
    Agreed. I have a sidekiq job that imports data into elasticsearch from a mysql database using activerecord, and it uses hundreds of megs of memory, which is ridiculous considering how little data is actually being imported.
    - sanderjd 9y ago
      Yeah we struggled to keep our memory usage under 500M per worker. Sidekiq helped because it was able to use threads effectively, but especially when we were running resque workers, we could only handle tens of tasks per second, and often fell behind. I think Rails' autoload-the-world philosophy was a big part of the problem and we spent some time trying to untangle dependencies, but it was swimming against the stream. I'm not sure if these same problems do or don't come up with Phoenix, but when I briefly used it, it did seem to have a smaller memory footprint.
      - tychver 9y ago
        500MB per worker is totally standard. What happens is a job causes a huge array or hash to be allocated, and after it‘s finished the memory can’t be returned to the OS due to heap fragmentation. Java does some crazy stuff with compaction. C programs typically try and internally allocate into arenas to avoid it.
      - 33degrees 9y ago
        The thing is we're not even using rails, it's a simple Sinatra app with ActiveRecord, so there's not much being loaded that's not being used. Could be the ActiveRecord itself is the problem though.
- biokoda 9y ago
  > Waiting 200ms for the database + an additional 20ms for rendering Those are pretty awful numbers. https://blog.gigaspaces.com/amazon-found-every-100ms-of-latency-cost-them-1-in-sales/ https://blog.gigaspaces.com/amazon-found-every-100ms-of-late...
- qaq 9y ago
  Well there is always question of $ if running on Phoenix would let you save $100/month it's one thing if it's 100k/month things might look a bit differently and when it is 1 mil/ month things that will change equation even more. (This is not going into areas were Ruby is not a usable option such as massive real time apps etc.)
TomK32 9y ago
After 10 yrs of Rails I have some high expectations and miss information about Elexir's incarnation of rubygems. Is there anything like RSpec?
- outlog 9y ago
  the package manager is here: https://hex.pm https://hex.pm with elixir having a lot of former and present rails devs in the eco-system - you can usually find "equivalent" packages("gems").. say search for rspec https://hex.pm/packages?_utf8=&search=rspec&sort=recent_downloads https://hex.pm/packages?_utf8=&search=rspec&sort=recent_down...
- thibaut_barrere 9y ago
  I'm using Rails since 2005, used RSpec all the time (and still do), and I must say the built-in testing framework (ExUnit) is "good enough" for me. I haven't felt the need to use something that would mimic RSpec more.
- pg_bot 9y ago
  There is an RSpec clone called ESpec https://github.com/antonmi/espec https://github.com/antonmi/espec. I've used it in my own applications, however I would probably not recommend using it as it relies on a feature of the language (tuple modules) that might be removed in the next major version. Elixir ships with a unit testing library called ExUnit, the documentation for which can be found here. https://hexdocs.pm/ex_unit/ExUnit.html https://hexdocs.pm/ex_unit/ExUnit.html
- bwilliams 9y ago
  Hex (the package manager) is pretty great along with the rest of Elixir's core ecosystem (ExUnit, hexdocs, Mix, etc). In Ruby-land I use RSpec almost exclusively but in Elixir I stick to ExUnit and it's great. I feel like there's not as much of a need for something RSpec like in Elixir-land due it being functional.
- jherdman 9y ago
  I've been programming Ruby and using RSpec for quite some time, but quite honestly I wouldn't use it for a new greenfield Ruby project tomorrow. I've consistently found that it's too difficult to teach and for a team to use effectively time and time again. I'd likely stick with MiniTest. Similarly as I wade into Elixir, I'm sticking with ExUnit. It's simple, concise, and gets the job done.
holydude 9y ago
"Author of http://www.phoenixforrailsdevelopers.com" http://www.phoenixforrailsdevelopers.com" All of this looks like a sales pitch to me. No doubt that elixir / erlang are an extremely useful and brilliant technologies but the article is simply bollocks measuring apples and oranges.
- sotojuan 9y ago
  As a technology gathers hype around it, it is normal to see people try to make a quick buck out of it through books or only courses. I'd recommend interested developers to go read Phoenix' own website and form their own opinion.
evtothedev 9y ago
Seems kind of circular to say, "Use Phoenix instead of Rails because Phoenix is similar to Rails." Which is pretty much points 1, 2 and 3 of this list of 5.
srikz 9y ago
For someone who hasn't learnt Rails or any other backend framwork and has only briefly dabbled with NodeJS, is it better to learn Rails first or should I learn Elixir / Phoenix directly? Thanks.
- gm-conspiracy 9y ago
  Probably Rails, since most web frameworks are inspired by features from Rails. Then you can build the missing "parts" in Elixir for Phoenix.
  - nitrogen 9y ago
    Downvoting this makes no sense. Rails is an excellent backend framework to learn because it's been around long enough for people to know what it does well and what it doesn't, and chances are you won't be big enough to hit the Rails scaling ceiling (it's way higher than most people think).
- elvio 9y ago
  I think it depends a bit on the purpose. If your goal is to learn a new framework and get a job, I believe Rails would be the best option, since there is a huge number of jobs available for Rails developers. Of course you can still get a job with Elixir and Phoenix, but not as many as compared to Rails ones. If your goal is to learn a new web framework and maybe use it to play with personal projects, then both Rails and Phoenix would be great options. Keep in mind that you can also learn both frameworks and benefit even more.
- brandonmenc 9y ago
  Do you prefer functional programming? Do you like to "know how everything works?" i.e., you prefer explicitness over magic? Are you OK with documentation that isn't always correct? Try Phoenix. Are you a beginner? Do you want to learn a more marketable skill? Do you just want to get stuff done as quickly as possible as soon as possible? Do you prefer OOP? Try Rails. I use both in production. Rails is awesome. It does everything, is performant enough for nearly every use case, and has some of the best documentation ever. You really can't go wrong with it. I switched to Elixir and Phoenix mostly because I prefer functional languages. Honestly, if Elixir weren't functional I wouldn't be using Phoenix over Rails. I also felt - after some years - constrained by the style of modularization Rails enforces - which, to be fair, is a benefit when you're just starting and is suitable for nearly every project. But, if you're an experienced developer, it might bother you in larger projects that you can't break up your code the "right" way. It's a minor detail for some people, and a major pain for others. ymmv. tl;dr - use Rails unless you're willing to trade initial productivity for specific and possibly not very important language preferences.
aczerepinski 9y ago
One of my favorite perks of Phoenix vs Rails is no wasted time trying to figure out where the heck a method/function came from. Is it from the parent class? One of the included modules? Or perhaps not defined anywhere at all, with method missing magic? Going from that to explicit imports is refreshing.
- thibaut_barrere 9y ago
  (note: I use both Elixir & Ruby, for different reasons) You can most of the time rely on object.method(:blank?).source_location to quickly determine where a specific method is defined. More useful debugging tips can be found here: https://www.schneems.com/2016/01/25/ruby-debugging-magic-cheat-sheet.html https://www.schneems.com/2016/01/25/ruby-debugging-magic-che...
  - nitrogen 9y ago
    If you use Pry with Rails, you can also call binding.pry before the method in question, then type show-method [methodname] in the Pry console.
- elvio 9y ago
  That is a real productivity booster. I also enjoy the clarity and explicitness present in the framework.
qaq 9y ago
Strange list to be honest. The fundamental reason to choose Phoenix would be: 1) unparalleled capabilities for real time features 2) BEAM VM and all it's capabilities available via more conventional syntax than Erlang via Elixir
- sriram_malhar 9y ago
  Real time? Not really. There's no time bound of any sort offered by any part of the Erlang ecosystem. What they mean is "quick enough", for some definition of quick and enough.
  - qaq 9y ago
    In context of web apps real time generally means things like chat, voice etc. not hard realtime as in RTOS.
  - ramchip 9y ago
    There’s various types of real-time systems: https://en.m.wikipedia.org/wiki/Real-time_computing#Criteria_for_real-time_computing https://en.m.wikipedia.org/wiki/Real-time_computing#Criteria... You’re talking about hard real-time. Erlang, as it says on the official site, targets soft real-time.
    - sriram_malhar 9y ago
      I know Erlang says that and I have always been a bit mystified by it. Definition of soft real time: "the usefulness of a result degrades after its deadline, thereby degrading the system's quality of service". Well, duh. That's pretty useless. Any system in production is soft real-time by that definition. There's really nothing special about Erlang that makes it amenable to "pretty quick" responses. It is not as if admission and rate control are baked into BEAM. If you don't pay attention to your messaging architecture, head-of-line blocking will kill you. I know that they claim that their sharded-GC design helps with shorter pauses, but there's no real evidence to back the imputation that other GC designs have really held back the industry; consider the large number of sites that have been implemented in Java/Python/Ruby. I have put Java/Scala/Go/Erlang systems in production, and rarely have I have ever had to worry about GC tuning.
bwilliams 9y ago
I've used Rails for a long time, and Phoenix since early versions (0.6 or something like that?). Phoenix is amazing but productivity wise I haven't seen it get near the productivity levels you can get with Rails. Other developers I've spoken to say the same thing. This is even more true with the more recent release of Phoenix 1.3 encouraging the use of contexts. I think it's a good pattern to extract to once you have more knowledge about your application but trying to think about it up-front has slowed development speed down and has been hit or miss on whether or not the context was "correct". https://hexdocs.pm/phoenix/contexts.html https://hexdocs.pm/phoenix/contexts.html I think Rails and Phoenix have a heavily overlapping place in web development but my personal tl;dr is that Rails is great for getting shit done and Phoenix is great for scaling, especially when it comes to websockets.
- meesterdude 9y ago
  > Rails is great for getting shit done and Phoenix is great for scaling I think thats a fair assessment. Rails is super productive - but if you're building say, a financial exchange, Phoenix would probably serve you better.
- pqh 9y ago
  Would you have any thoughts on how they compare in maintainability?
  - bwilliams 9y ago
    I do, I think it all boils down to the team. I'll admit Rails apps are a bit harder to untangle but poorly written code is poorly written code. A lot of clever metaprogramming tricks can make that poorly written code a lot more painful though. :)
- bradgessler 9y ago
  Yes! Contexts are the equivalent of building a greenfield rails app with a bunch of properly namespaced and isolated Rails engines. You end up with some really awkward names and boilerplate code that just doesn’t feel right. You can get that sense while reading the Phoenix context documentation. The Phoenix story should include an area where the app can evolve, and as it matures and becomes more well understood, pieces of it could be moved into contexts.
cutler 9y ago
One reason not to use Elixir is the absence of vectors/arrays. Yes, you can import them from Erlang but they ain't pretty. Elixirists try to pretend that lists and tuples are all you need but Elixir's lists are Lispy lists, not the Python variety. It's one of these small print things you only discover after spending time with Elixir but it can be a deal-breaker. Ask on the Elixir lists and you'll get some very defensive responses which basically add-up to vectors/arrays being difficult to optimise in a dynamic functional language. String processing is also not quite as straightforward as in Ruby and Python due to how Erlang/Elixir uses binary representation.
- paulcsmith 9y ago
  Can you explain a bit more what you mean? What advantages do "Python variety" lists give you over what Elixir does with lists and tuples?
  - cutler 9y ago
    Python's lists are really arrays/vectors as in Ruby ie. well-optimised for index-based access. Erlang/Elixir lists are linked lists which are more optimised for appends than index-based access though you can achieve the same with Enum.at(list, index). With small lists/arrays the difference isn't noticeable but it will affect performance with large lists.
    - bousaid 9y ago
      Arrays and vectors are different. I’d suggest adhering to C-like conventions of data structures.
    - dnautics 9y ago
      If we're being honest, Python lists aren't arrays either, they are arrays of pointers which need to be unboxed before using. If you really really need array performance, then drop down to c, or use a language like Julia. Lists give you the ability to quickly pass these structures as immutable objects, which in turn, you want because of safety guarantees in concurrent environments.
mrdoops 9y ago
I'm in love with the simple explicit composability of everything in the Elixir ecosystem. In Phoenix everything is a pipeline from the connection leading down through the routes, controller, etc. Phoenix is just a plug in a Mix application and it doesn't impose itself in everything I do. I'm not a Phoenix developer, I'm an Elixir developer who happens to be using Phoenix to manage web traffic. I think this is where Rails and Phoenix diverge in philosophy, Phoenix prioritizes explicitness and minimal assumptions with how and what you're going to do with their tool, whereas Rails is famously opinionated providing a 'Rails way' of doing most things. What Rails does, it is very good at, but when you move outside of its expertise, you'll may find yourself in hot-water fast. Phoenix can be what you need it to be, and when you need to do something outside of Phoenix's domain everything is composable, so pick and chose what you need.
csdreamer7 9y ago
Most of the comments seem to answer what I was going to ask after reading the post: "what about the gems?" My question now would be "does Phoenix have something like devise and carrierwave gems?" Please link if so.
- jherdman 9y ago
  Uberauth https://hex.pm/packages/ueberauth https://hex.pm/packages/ueberauth Arc https://hex.pm/packages/arc https://hex.pm/packages/arc
  - csdreamer7 9y ago
    Thank you.
- praveenperera 9y ago
  For authentication I like: https://github.com/riverrun/phauxth https://github.com/riverrun/phauxth
joshmn 9y ago
I've used Django and Phoenix and Laravel. And they all have one thing in common: They're not the same at all. I don't know why people compare MVC-framework-X-that's-inspired-by-Rails'-foundations-and-fundamentals to Rails. Rails isn't great because MVC. Rails is great the vast and mature tooling and ecosystem that exists in Ruby (bundle, rake, thor; Rubygems), and the effortless ability to metaprogram (which is why Rails is what it is). Per Rubygems, there are literally hundreds of thousands of people who are smarter than me who have developed libraries that solve the majority of things that I will/may need to implement. I'm not smarter than them and I'm okay with that. I want to focus on domain-specific stuff. Not anything else. Those other frameworks... They're just not the same. It's like comparing Ghost to Wordpress. Sure, they both allow you to blog, but Ghost doesn't have the Wordpress ecosystem of themes and plugins (blah blah blah security, I know). I don't want to spend my time reinventing the wheel and neither do my clients or users. I'm not trying to earn style points with my stack and neither should anyone else. I'm not trying to impress HN or colleagues or friends. I'm trying to impress my clients and my users. Rails will, for at least the next 5 years, allow me and anyone else who's familiar with OOP to greatly outpace any other web framework, given it's the right tool for the job[0]. There are other comments about scaling below and I'd love to comment on each of them but I won't. Rails scales just fine. I proudly serve an Alexa Top 5000 website that peaks at 500k rpm a few times a month (Nginx/Puma/Postgres/Redis). It all sits on a $30 VPS (2 cores @ 2GHz/8GB RAM). Sub-50ms response times and as stable as can be. It's not the most trivial of applications, either (pushing 50k writes/min and 1000 open pg connections). Sure, you'll spend a day tweaking your setup, but the cost of a day's time is low in comparison to switching to something like Phoenix. [0] No, you're not going to mine crypto with Ruby.
- mrisoli 9y ago
  That's because "Rails with performance" was one of Phoenix's selling points from day one, Phoenix was inspired by Rails and Elixir is heavily influenced by Ruby, prior to 1.3 killing the models in favor of contexts Phoenix contained an extremely similar structure to Rails MVC with less implicit conventions.
- jondubois 9y ago
  Phoenix is way overhyped, particularly on HN. This is the same as what happened with Golang and then with Rust. A few years ago, I remember that all these articles kept popping up about people switching from Node.js to Go. Now it's funny because fairly recently I read a well thought out article on HN encouraging developers to dump Go for Node.js... These days you hardly read anything about Go at all. Not that there is anything wrong with it, but reality caught up with the hype and it's no longer pretending to be a silver bullet. Right now Phoenix is pretending to be a silver bullet, but it's really not.
ben_jones 9y ago
I've worked with Django, Flask, Rails, Express, and Go. It gets to the point where it's not "which framework is the best" but "which framework is the best for our company". Having interviewed at a ton of start-ups recently it's been overwelmingly Node because its super easy to hire for and onboard, with the benefits of dynamic programming and node's ecosystem. If your company has a great hiring pipeline or is super attractive to candidates, you could do something more niche like erlang, scala, elixir, go, etc., to more closely match technical needs. Everytime I see "x is better then y" I just chuckle and slowly step away.
pmontra 9y ago
After many projects with Rails and one with Phoenix, these are my remarks on the list in the post: * The directory structure. Rails has a simpler one. Phoenix has some weirdness (why the migrations are in priv/db? They are private and all the other modules are not?) * The naming conventions. About the same. * The database migrations. About the same, but with Phoenix we have to duplicate the schema definition in the model, which is not DRY at all and encourage bugs. Either the ActiveRecord way (the truth in the db) or the Django way (the truth in the model). * The use of dependencies. About the same. * The ActiveRecord features. AR is much easier to use than Ecto, which is more general but often unnecessarily so. Proof: there are modules on top of Ecto to make it look like AR [1] [2]. Personally I won't use plain Ecto in an Elixir project of my own. * The ERb templates. About the same. * The form helpers. I really don't know: my Phoenix project was a backend to a SPA, we generated JSON plus some email templates. * The built-in support for testing. About the same. Advantages of Phoenix: * no need for Sideqik, just spawn processes and send emails and the like * create some GenServers to run long running processes side by side with the main web application * the websocket server is an example of the previous point and it performs better than the one in Rails. * Elixir's pattern matching is so good to use compared to any language without it (Ruby, Python, etc.) Advantages of Rails: * ActiveRecord is so easier to use that it translates in visible productivity gains (of course it's also 10 years of Rails vs 4 months of Phoenix). What it means for the long term maintainability of the application is up to you to decide. In my experience the impact is zero because none of my projects was meant to scale to the millions of users or to a complex architecture and none did. Your project might be different. * The object oriented notation is more compact than the functional one: object.method.method.method vs value |> function |> function |> function, maybe with some Module.function thrown in to make it even more verbose. [1] https://github.com/sheharyarn/ecto_rut https://github.com/sheharyarn/ecto_rut [2] https://github.com/MishaConway/ecto_shortcuts https://github.com/MishaConway/ecto_shortcuts
- kungfooguru 9y ago
  'priv' is an Erlang/OTP application's directory for files that are part of an application but not source or compiled beams.
- praveenperera 9y ago

122 points by elvio 9y ago

So, I've used Rails (ruby), Django (python), Flask (python) Revel (go), Spring (java), Node.js (javascript), and even have used C, php and Go to roll my own website from scratch[1]. The thing is, I've always scaled my website(s) to thousands or tens of thousands of requests and hour; with one website even getting close to a million an hour... all with no problem. In the case of Rails (as is discussed in the article), my bottleneck (from a usability perspective) is always bandwidth. Most applications (I build anyway), require a hefty amount of data. Waiting 200ms for the database + an additional 20ms for rendering, the 20ms is not noticeable. Scaling Rails (or any modern web app) is as easy as just launching another instance and load balancing. Given that, I really don't see any advantage toward Phoenix. Plus, why I personally love rails is all the gems - which is super powerful. Most other frameworks simply don't have Rails simple logic, with the easily extendable gems. [1] http://austingwalters.com/building-a-web-server-in-go-handling-page-requests/ http://austingwalters.com/building-a-web-server-in-go-handli...

TomK32 9y ago
Tbh, 200ms for the db is massive. I have a 100ms limit at which my mongodb writes into the slow-log. It's an almost empty log. My point being, apps can have all sorts of bottlenecks and you only have to throw the right brain at the problem to fix it, no need to replace the techstack. Yes, gems. The ecosphere in ruby is superb. I'm started working with node a lot more these days and it's a) confusing and b) small packages for all those things whatevertheycallitthesedaysscript is missing. 243 gems in my 7yr old Ruby vs 918 node modules in an app we started this month. What's Elexir/Erlang like in this respect?
- merb 9y ago
  even for "old databases" (mysql, postgresql) 200ms is huge or to it differently say probably his database is not the bottleneck. He probably fetches big lists, and even lists with over 100 entries are extremly slow on python/rails, whatever. on java/c++/go/rust these things are way faster.
  - lettergram 9y ago
    The database doesn't need to be an issue - it just currently is. We have a fairly complex query on a several terabyte large PostgreSQL database and didn't want to spend more money. Basically, we just haven't sharded it yet, and don't want to pay for a larger machine. The point is - typically the issue isn't the web app. Almost all web frameworks are designed to be scalable from the start. Just launch another instance. Also, we do about 99 writes for every 1 read, so query times don't matter as much. For the given app I was using as an example. Network I/O and large databases are usually the bottlenecks from what I've seen consulting and developing.
  - ezekg 9y ago
    MySQL and PostgreSQL are considered “old” now? I’d guess that’s much like Rails being considered “old” and “legacy.”
  - tychver 9y ago
    This was probably true 10 years ago, but these days it's basically FUD. Since then Ruby improved performance something like 5-80x from 1.8 to 2.5 and moved from an interpreted language to a VM nearly as fast as LuaJIT. Go only has 3-5x the throughput for tasks like: grab 100 rows from PostgreSQL, serialize to JSON, respond via HTTP. Lots of the hot code in Ruby around fetching rows from the DB, serializing to JSON, and HTTP parsing have also since been implemented as native functions in C, massively improving performance with zero effort required by the developer.
    - merb 9y ago
      yeah this is cool, until you make a single map...
      - tychver 9y ago
        Do you mean: "take a few thousand rows and map them to a different data structure"? Because I benchmarked that recently and mapping 16,000 rows of GPS points using haversine distance in pure Ruby takes about 12ms, and about 5ms in Go. It's not that much slower. There are tasks where Ruby can be ~100x slower than Go, but a simple map isn't one of them.
mrisoli 9y ago
I share your opinion, if you have any bottlenecks which are unsolvable because of Rails or Ruby being slow your app probably scaled up to a point where you have the resources to make a creative solution that is not Phoenix/Elixir. Having said that, while I don't find any major reasons to opt for Phoenix instead of Rails, my main reason to work with Elixir/Phoenix right now on side projects is that it won't make me unlearn Rails which I can always go back to, in fact, using Phoenix for a while made me miss a lot of the available libraries, plug-in solutions and wide range of community knowledge. So ATM I have more reasons to choose Rails over Phoenix, but I suppose that's why these sorts of articles are important, publicity to increase a community and fulfill Elixir's biggest need right now.
- mooreds 9y ago
  > in fact, using Phoenix for a while made me miss a lot of the available libraries, plug-in solutions and wide range of community knowledge. This is my main reason for focusing on Rails rather than Elixir at present. The sheer breadth of gems available for rails to quickly build sophisticated applications is hard to beat for any up and coming language/framework. That said, my gut feel is that many of the developers who build and maintain these gems have moved on and that Elixir is the new hotness and will probably catch up in the next few years.
- regulation_d 9y ago
  I wonder if you might extrapolate on which libraries, plug-in solutions you missed in Phoenix.
phamilton 9y ago
I mean... 1 million requests an hour isn't that many. That's around 300 requests per second. Assuming 1000ms upper bound on requests, you need 300 workers to handle that load. Assuming 150MB per worker, that's 45 GB of memory required to handle the load. So like... 5 m4.xlarge instances on EC2 (to give redundancy and allow loss of 2 hosts). That's $700/month. That's not that much. We've got a Rails app that pushes 5000 qps. And to be fair, we just dial up the number of instances and it handles it fine. It runs on over 100 instances. It costs us around $10k/month. Not the end of the world, cost wise, but we have multiple Go services that handle similar levels of traffic and run on a dozen instances. Additionally, deploys take a long time (rolling restarts plus health checks on 100 machines takes time). Moving to Go (or Elixir) allows us to handle far more requests per unit of hardware. While latency would indeed improve, it's not the primary motivator for us moving away from Rails. I haven't even mentioned the websocket story on Rails. That's a whole new can of worms.
- meritt 9y ago
  Do rails apps actually use 150MB per worker or was that just a lofty ceiling estimate? Or is that with an app server that doesn't utilize process forking, and loses the benefit of shared libraries/heap/etc?
  - gkop 9y ago
    Yes, they often do :/
  - tychver 9y ago
    Yes, but you only need one process per core, just like NodeJS. Since 1.9 you can use real OS threads to achieve parallel IO, and certain parallel computations which can proceed without holding the Global Interpreter Lock. JRuby offers completely unrestricted threading with a single process, plus a 3x performance boost, plus the advantage of an incredible amount of work put into their VM and GC. It's a really underrated option these days. The problem with forking, is MRI Ruby is unaware what memory is actually inherited by forking, so eventually it causes the entire heap inherited from the parent to copy into the child. I'm actually working on a patch to fix this. The solution is simple, just don't mark, collect, or allocate into inherited pages, but the implementation itself is fiddly. What's really exacerbated this, is that most Linux distros now have Transparent Huge Pages turned on by default, and flipping a single bit in inherited causes a 2MB copy instead of a 4kb copy!
sanderjd 9y ago
My bottleneck with Rails was always memory usage. Our concurrency was always limited by how many web and task workers we could run in the amount of memory we could afford, which was not very many. It was not straightforward to optimize this and ignoring it didn't work for us, so we put lots of time into it and it changed the whole productivity argument for Rails.
- 33degrees 9y ago
  Agreed. I have a sidekiq job that imports data into elasticsearch from a mysql database using activerecord, and it uses hundreds of megs of memory, which is ridiculous considering how little data is actually being imported.
  - sanderjd 9y ago
    Yeah we struggled to keep our memory usage under 500M per worker. Sidekiq helped because it was able to use threads effectively, but especially when we were running resque workers, we could only handle tens of tasks per second, and often fell behind. I think Rails' autoload-the-world philosophy was a big part of the problem and we spent some time trying to untangle dependencies, but it was swimming against the stream. I'm not sure if these same problems do or don't come up with Phoenix, but when I briefly used it, it did seem to have a smaller memory footprint.
    - tychver 9y ago
      500MB per worker is totally standard. What happens is a job causes a huge array or hash to be allocated, and after it‘s finished the memory can’t be returned to the OS due to heap fragmentation. Java does some crazy stuff with compaction. C programs typically try and internally allocate into arenas to avoid it.
    - 33degrees 9y ago
      The thing is we're not even using rails, it's a simple Sinatra app with ActiveRecord, so there's not much being loaded that's not being used. Could be the ActiveRecord itself is the problem though.
biokoda 9y ago
> Waiting 200ms for the database + an additional 20ms for rendering Those are pretty awful numbers. https://blog.gigaspaces.com/amazon-found-every-100ms-of-latency-cost-them-1-in-sales/ https://blog.gigaspaces.com/amazon-found-every-100ms-of-late...
qaq 9y ago
Well there is always question of $ if running on Phoenix would let you save $100/month it's one thing if it's 100k/month things might look a bit differently and when it is 1 mil/ month things that will change equation even more. (This is not going into areas were Ruby is not a usable option such as massive real time apps etc.)

TomK32 9y ago

After 10 yrs of Rails I have some high expectations and miss information about Elexir's incarnation of rubygems. Is there anything like RSpec?

outlog 9y ago
the package manager is here: https://hex.pm https://hex.pm with elixir having a lot of former and present rails devs in the eco-system - you can usually find "equivalent" packages("gems").. say search for rspec https://hex.pm/packages?_utf8=&search=rspec&sort=recent_downloads https://hex.pm/packages?_utf8=&search=rspec&sort=recent_down...
thibaut_barrere 9y ago
I'm using Rails since 2005, used RSpec all the time (and still do), and I must say the built-in testing framework (ExUnit) is "good enough" for me. I haven't felt the need to use something that would mimic RSpec more.
pg_bot 9y ago
There is an RSpec clone called ESpec https://github.com/antonmi/espec https://github.com/antonmi/espec. I've used it in my own applications, however I would probably not recommend using it as it relies on a feature of the language (tuple modules) that might be removed in the next major version. Elixir ships with a unit testing library called ExUnit, the documentation for which can be found here. https://hexdocs.pm/ex_unit/ExUnit.html https://hexdocs.pm/ex_unit/ExUnit.html
bwilliams 9y ago
Hex (the package manager) is pretty great along with the rest of Elixir's core ecosystem (ExUnit, hexdocs, Mix, etc). In Ruby-land I use RSpec almost exclusively but in Elixir I stick to ExUnit and it's great. I feel like there's not as much of a need for something RSpec like in Elixir-land due it being functional.
jherdman 9y ago
I've been programming Ruby and using RSpec for quite some time, but quite honestly I wouldn't use it for a new greenfield Ruby project tomorrow. I've consistently found that it's too difficult to teach and for a team to use effectively time and time again. I'd likely stick with MiniTest. Similarly as I wade into Elixir, I'm sticking with ExUnit. It's simple, concise, and gets the job done.

holydude 9y ago

"Author of http://www.phoenixforrailsdevelopers.com" http://www.phoenixforrailsdevelopers.com" All of this looks like a sales pitch to me. No doubt that elixir / erlang are an extremely useful and brilliant technologies but the article is simply bollocks measuring apples and oranges.

sotojuan 9y ago
As a technology gathers hype around it, it is normal to see people try to make a quick buck out of it through books or only courses. I'd recommend interested developers to go read Phoenix' own website and form their own opinion.

evtothedev 9y ago

Seems kind of circular to say, "Use Phoenix instead of Rails because Phoenix is similar to Rails." Which is pretty much points 1, 2 and 3 of this list of 5.

srikz 9y ago

For someone who hasn't learnt Rails or any other backend framwork and has only briefly dabbled with NodeJS, is it better to learn Rails first or should I learn Elixir / Phoenix directly? Thanks.

gm-conspiracy 9y ago
Probably Rails, since most web frameworks are inspired by features from Rails. Then you can build the missing "parts" in Elixir for Phoenix.
- nitrogen 9y ago
  Downvoting this makes no sense. Rails is an excellent backend framework to learn because it's been around long enough for people to know what it does well and what it doesn't, and chances are you won't be big enough to hit the Rails scaling ceiling (it's way higher than most people think).
elvio 9y ago
I think it depends a bit on the purpose. If your goal is to learn a new framework and get a job, I believe Rails would be the best option, since there is a huge number of jobs available for Rails developers. Of course you can still get a job with Elixir and Phoenix, but not as many as compared to Rails ones. If your goal is to learn a new web framework and maybe use it to play with personal projects, then both Rails and Phoenix would be great options. Keep in mind that you can also learn both frameworks and benefit even more.
brandonmenc 9y ago
Do you prefer functional programming? Do you like to "know how everything works?" i.e., you prefer explicitness over magic? Are you OK with documentation that isn't always correct? Try Phoenix. Are you a beginner? Do you want to learn a more marketable skill? Do you just want to get stuff done as quickly as possible as soon as possible? Do you prefer OOP? Try Rails. I use both in production. Rails is awesome. It does everything, is performant enough for nearly every use case, and has some of the best documentation ever. You really can't go wrong with it. I switched to Elixir and Phoenix mostly because I prefer functional languages. Honestly, if Elixir weren't functional I wouldn't be using Phoenix over Rails. I also felt - after some years - constrained by the style of modularization Rails enforces - which, to be fair, is a benefit when you're just starting and is suitable for nearly every project. But, if you're an experienced developer, it might bother you in larger projects that you can't break up your code the "right" way. It's a minor detail for some people, and a major pain for others. ymmv. tl;dr - use Rails unless you're willing to trade initial productivity for specific and possibly not very important language preferences.

aczerepinski 9y ago

One of my favorite perks of Phoenix vs Rails is no wasted time trying to figure out where the heck a method/function came from. Is it from the parent class? One of the included modules? Or perhaps not defined anywhere at all, with method missing magic? Going from that to explicit imports is refreshing.

thibaut_barrere 9y ago
(note: I use both Elixir & Ruby, for different reasons) You can most of the time rely on object.method(:blank?).source_location to quickly determine where a specific method is defined. More useful debugging tips can be found here: https://www.schneems.com/2016/01/25/ruby-debugging-magic-cheat-sheet.html https://www.schneems.com/2016/01/25/ruby-debugging-magic-che...
- nitrogen 9y ago
  If you use Pry with Rails, you can also call binding.pry before the method in question, then type show-method [methodname] in the Pry console.
elvio 9y ago
That is a real productivity booster. I also enjoy the clarity and explicitness present in the framework.

qaq 9y ago

Strange list to be honest. The fundamental reason to choose Phoenix would be: 1) unparalleled capabilities for real time features 2) BEAM VM and all it's capabilities available via more conventional syntax than Erlang via Elixir

sriram_malhar 9y ago
Real time? Not really. There's no time bound of any sort offered by any part of the Erlang ecosystem. What they mean is "quick enough", for some definition of quick and enough.
- qaq 9y ago
  In context of web apps real time generally means things like chat, voice etc. not hard realtime as in RTOS.
- ramchip 9y ago
  There’s various types of real-time systems: https://en.m.wikipedia.org/wiki/Real-time_computing#Criteria_for_real-time_computing https://en.m.wikipedia.org/wiki/Real-time_computing#Criteria... You’re talking about hard real-time. Erlang, as it says on the official site, targets soft real-time.
  - sriram_malhar 9y ago
    I know Erlang says that and I have always been a bit mystified by it. Definition of soft real time: "the usefulness of a result degrades after its deadline, thereby degrading the system's quality of service". Well, duh. That's pretty useless. Any system in production is soft real-time by that definition. There's really nothing special about Erlang that makes it amenable to "pretty quick" responses. It is not as if admission and rate control are baked into BEAM. If you don't pay attention to your messaging architecture, head-of-line blocking will kill you. I know that they claim that their sharded-GC design helps with shorter pauses, but there's no real evidence to back the imputation that other GC designs have really held back the industry; consider the large number of sites that have been implemented in Java/Python/Ruby. I have put Java/Scala/Go/Erlang systems in production, and rarely have I have ever had to worry about GC tuning.

bwilliams 9y ago

I've used Rails for a long time, and Phoenix since early versions (0.6 or something like that?). Phoenix is amazing but productivity wise I haven't seen it get near the productivity levels you can get with Rails. Other developers I've spoken to say the same thing. This is even more true with the more recent release of Phoenix 1.3 encouraging the use of contexts. I think it's a good pattern to extract to once you have more knowledge about your application but trying to think about it up-front has slowed development speed down and has been hit or miss on whether or not the context was "correct". https://hexdocs.pm/phoenix/contexts.html https://hexdocs.pm/phoenix/contexts.html I think Rails and Phoenix have a heavily overlapping place in web development but my personal tl;dr is that Rails is great for getting shit done and Phoenix is great for scaling, especially when it comes to websockets.

meesterdude 9y ago
> Rails is great for getting shit done and Phoenix is great for scaling I think thats a fair assessment. Rails is super productive - but if you're building say, a financial exchange, Phoenix would probably serve you better.
pqh 9y ago
Would you have any thoughts on how they compare in maintainability?
- bwilliams 9y ago
  I do, I think it all boils down to the team. I'll admit Rails apps are a bit harder to untangle but poorly written code is poorly written code. A lot of clever metaprogramming tricks can make that poorly written code a lot more painful though. :)
bradgessler 9y ago
Yes! Contexts are the equivalent of building a greenfield rails app with a bunch of properly namespaced and isolated Rails engines. You end up with some really awkward names and boilerplate code that just doesn’t feel right. You can get that sense while reading the Phoenix context documentation. The Phoenix story should include an area where the app can evolve, and as it matures and becomes more well understood, pieces of it could be moved into contexts.

cutler 9y ago

One reason not to use Elixir is the absence of vectors/arrays. Yes, you can import them from Erlang but they ain't pretty. Elixirists try to pretend that lists and tuples are all you need but Elixir's lists are Lispy lists, not the Python variety. It's one of these small print things you only discover after spending time with Elixir but it can be a deal-breaker. Ask on the Elixir lists and you'll get some very defensive responses which basically add-up to vectors/arrays being difficult to optimise in a dynamic functional language. String processing is also not quite as straightforward as in Ruby and Python due to how Erlang/Elixir uses binary representation.

paulcsmith 9y ago
Can you explain a bit more what you mean? What advantages do "Python variety" lists give you over what Elixir does with lists and tuples?
- cutler 9y ago
  Python's lists are really arrays/vectors as in Ruby ie. well-optimised for index-based access. Erlang/Elixir lists are linked lists which are more optimised for appends than index-based access though you can achieve the same with Enum.at(list, index). With small lists/arrays the difference isn't noticeable but it will affect performance with large lists.
  - bousaid 9y ago
    Arrays and vectors are different. I’d suggest adhering to C-like conventions of data structures.
  - dnautics 9y ago
    If we're being honest, Python lists aren't arrays either, they are arrays of pointers which need to be unboxed before using. If you really really need array performance, then drop down to c, or use a language like Julia. Lists give you the ability to quickly pass these structures as immutable objects, which in turn, you want because of safety guarantees in concurrent environments.

mrdoops 9y ago

I'm in love with the simple explicit composability of everything in the Elixir ecosystem. In Phoenix everything is a pipeline from the connection leading down through the routes, controller, etc. Phoenix is just a plug in a Mix application and it doesn't impose itself in everything I do. I'm not a Phoenix developer, I'm an Elixir developer who happens to be using Phoenix to manage web traffic. I think this is where Rails and Phoenix diverge in philosophy, Phoenix prioritizes explicitness and minimal assumptions with how and what you're going to do with their tool, whereas Rails is famously opinionated providing a 'Rails way' of doing most things. What Rails does, it is very good at, but when you move outside of its expertise, you'll may find yourself in hot-water fast. Phoenix can be what you need it to be, and when you need to do something outside of Phoenix's domain everything is composable, so pick and chose what you need.

csdreamer7 9y ago

Most of the comments seem to answer what I was going to ask after reading the post: "what about the gems?" My question now would be "does Phoenix have something like devise and carrierwave gems?" Please link if so.

jherdman 9y ago
Uberauth https://hex.pm/packages/ueberauth https://hex.pm/packages/ueberauth Arc https://hex.pm/packages/arc https://hex.pm/packages/arc
- csdreamer7 9y ago
  Thank you.
praveenperera 9y ago
For authentication I like: https://github.com/riverrun/phauxth https://github.com/riverrun/phauxth

joshmn 9y ago

I've used Django and Phoenix and Laravel. And they all have one thing in common: They're not the same at all. I don't know why people compare MVC-framework-X-that's-inspired-by-Rails'-foundations-and-fundamentals to Rails. Rails isn't great because MVC. Rails is great the vast and mature tooling and ecosystem that exists in Ruby (bundle, rake, thor; Rubygems), and the effortless ability to metaprogram (which is why Rails is what it is). Per Rubygems, there are literally hundreds of thousands of people who are smarter than me who have developed libraries that solve the majority of things that I will/may need to implement. I'm not smarter than them and I'm okay with that. I want to focus on domain-specific stuff. Not anything else. Those other frameworks... They're just not the same. It's like comparing Ghost to Wordpress. Sure, they both allow you to blog, but Ghost doesn't have the Wordpress ecosystem of themes and plugins (blah blah blah security, I know). I don't want to spend my time reinventing the wheel and neither do my clients or users. I'm not trying to earn style points with my stack and neither should anyone else. I'm not trying to impress HN or colleagues or friends. I'm trying to impress my clients and my users. Rails will, for at least the next 5 years, allow me and anyone else who's familiar with OOP to greatly outpace any other web framework, given it's the right tool for the job[0]. There are other comments about scaling below and I'd love to comment on each of them but I won't. Rails scales just fine. I proudly serve an Alexa Top 5000 website that peaks at 500k rpm a few times a month (Nginx/Puma/Postgres/Redis). It all sits on a $30 VPS (2 cores @ 2GHz/8GB RAM). Sub-50ms response times and as stable as can be. It's not the most trivial of applications, either (pushing 50k writes/min and 1000 open pg connections). Sure, you'll spend a day tweaking your setup, but the cost of a day's time is low in comparison to switching to something like Phoenix. [0] No, you're not going to mine crypto with Ruby.

mrisoli 9y ago
That's because "Rails with performance" was one of Phoenix's selling points from day one, Phoenix was inspired by Rails and Elixir is heavily influenced by Ruby, prior to 1.3 killing the models in favor of contexts Phoenix contained an extremely similar structure to Rails MVC with less implicit conventions.
jondubois 9y ago
Phoenix is way overhyped, particularly on HN. This is the same as what happened with Golang and then with Rust. A few years ago, I remember that all these articles kept popping up about people switching from Node.js to Go. Now it's funny because fairly recently I read a well thought out article on HN encouraging developers to dump Go for Node.js... These days you hardly read anything about Go at all. Not that there is anything wrong with it, but reality caught up with the hype and it's no longer pretending to be a silver bullet. Right now Phoenix is pretending to be a silver bullet, but it's really not.

ben_jones 9y ago

I've worked with Django, Flask, Rails, Express, and Go. It gets to the point where it's not "which framework is the best" but "which framework is the best for our company". Having interviewed at a ton of start-ups recently it's been overwelmingly Node because its super easy to hire for and onboard, with the benefits of dynamic programming and node's ecosystem. If your company has a great hiring pipeline or is super attractive to candidates, you could do something more niche like erlang, scala, elixir, go, etc., to more closely match technical needs. Everytime I see "x is better then y" I just chuckle and slowly step away.

pmontra 9y ago

After many projects with Rails and one with Phoenix, these are my remarks on the list in the post: * The directory structure. Rails has a simpler one. Phoenix has some weirdness (why the migrations are in priv/db? They are private and all the other modules are not?) * The naming conventions. About the same. * The database migrations. About the same, but with Phoenix we have to duplicate the schema definition in the model, which is not DRY at all and encourage bugs. Either the ActiveRecord way (the truth in the db) or the Django way (the truth in the model). * The use of dependencies. About the same. * The ActiveRecord features. AR is much easier to use than Ecto, which is more general but often unnecessarily so. Proof: there are modules on top of Ecto to make it look like AR [1] [2]. Personally I won't use plain Ecto in an Elixir project of my own. * The ERb templates. About the same. * The form helpers. I really don't know: my Phoenix project was a backend to a SPA, we generated JSON plus some email templates. * The built-in support for testing. About the same. Advantages of Phoenix: * no need for Sideqik, just spawn processes and send emails and the like * create some GenServers to run long running processes side by side with the main web application * the websocket server is an example of the previous point and it performs better than the one in Rails. * Elixir's pattern matching is so good to use compared to any language without it (Ruby, Python, etc.) Advantages of Rails: * ActiveRecord is so easier to use that it translates in visible productivity gains (of course it's also 10 years of Rails vs 4 months of Phoenix). What it means for the long term maintainability of the application is up to you to decide. In my experience the impact is zero because none of my projects was meant to scale to the millions of users or to a complex architecture and none did. Your project might be different. * The object oriented notation is more compact than the functional one: object.method.method.method vs value |> function |> function |> function, maybe with some Module.function thrown in to make it even more verbose. [1] https://github.com/sheharyarn/ecto_rut https://github.com/sheharyarn/ecto_rut [2] https://github.com/MishaConway/ecto_shortcuts https://github.com/MishaConway/ecto_shortcuts

kungfooguru 9y ago
'priv' is an Erlang/OTP application's directory for files that are part of an application but not source or compiled beams.
praveenperera 9y ago