Hacker News new | past | comments | ask | show | jobs | submit login

Lets restate the question, but this time include Erlang as an option:

You’re about to create a basic CRUD server for storing configuration files (JSON, YAML), with a web frontend. This will be used internally, with a few hundred daily users. No single file is greater than one megabyte, total storage is less than one gigabyte. You have today to complete this task.

You’re given these language options:

Ruby on Rails

PHP

Erlang

C++

x86 Assembly

Which one do you choose?

Answer: Ruby on Rails. Not Erlang.




As a Ruby on Rails Dev of 9 years, and an Elixir/Phoenix/OTP(erlang) dev of 2 years. I'm going to use Phoenix/Live View.

Every. Single. Time.


Given the forgiving requirements, I would choose whatever I know best, because I'm not going to special snowflake a system unless doing so offers outsized benefits.


Have you tried Phoenix? It's... amazing.


Lots of downvoting but I mean duhh for the average app and average developer of course Rails > Erlang is this even a discussion? Anything from documentation, community size, Stackoverflow questions to libraries will be better with Rails. Ah but the comments now say that Erlang = Elixir actually. Ok, I didn't know that. I'd say the same thing though, Rails > Elixir for the average app. You don't need the extra complexity Elixir brings. Yes I know about Whatsapp; no you're not gonna be Whatsapp.


as a person who knows and works both, Elixir/Phoenix and Rails.

Elixir/Phoenix is dead simple. Theres no "Rails Magic." It's easy to understand what's happening at all times. You don't need to have a grasp of the internals of OTP because it's not that important for the problem described above, but it's there should you need it, wand why you do need it you just need to understand it instead of of a plethora of extra technologies/DSLs that you would with a regular Rails Application.

with Rails you need to know/consider technologies like Foremen, Webpacker, Redis, Capistrano(or what ever), AnyCable or ActionCable, Sidekiq or whatever for ActiveJob, then how Puma(Unicorn, Thin) Webservers work, you probably need NgineX or something like it for reverse proxying. For more Rich Frontend experiences, something like Stimulus Reflex or a JS Spa(angular, react, svelte) Cron for periodic task, even stuff like periodically restarting your application. These are things you don't have to necessarily worry about in the context of Elixir & Phoenix w/ Liveview.


You're just listing a bunch of tech here that probably many Elixir apps use. None of it is essential for Rails btw.


>Foremen, Webpacker, Redis, Capistrano(or what ever), AnyCable or ActionCable, Sidekiq or whatever for ActiveJob

- Formen: thats just a process manager. you need somethign for otp as well. in my startup, its booted up from kubernetes. the nice thing is that the vm will use all available cpus.

- Webpacker: phoenix comes with webpack out of the box though I think they are replacing that in the next version with esbuild.

- Redis: Elxir borrows from the beam and part of that includes both an in memory ets (key balue storage system) and mnasia (a slightly more sophisticated queriable database. ie: I don't need to setup redis when the virtual machine has something already avaialble. redis is there if you really want it though

- Capistrano: We use kubernetes but theres also mix release which comes out of the box

- AnyCable or ActionCable: have you heard of phoenix's channels system? its WAY more powerful. action cable is a toy compared to what the channels system can do and its already setup when you start a phoenix app.

- Sidekiq or whatever for ActiveJob: Oban works great and I was able to set it up and use it from scratch within an hour


Tech is complicated, I don't think Elixir really lowers the bar in terms of understanding stuff like deployment to a basic level, docker, some persistance (I assume redis IS used quite a lot despite what you are suggesting here), reverse proxies like NGINX, CDNS etc etc. AnyCable is written in Go last I checked btw, what makes you think Elixir has something more performant? Never really bothered with it, it's not like every company I work for needs to push messages to millions of people at once all the time.


> AnyCable is written in Go last I checked btw, what makes you think Elixir has something more performant?

https://www.phoenixframework.org/blog/the-road-to-2-million-...


I'm listing the things I've used over the last 9 years of developing SaaS platforms in Rails.

The beautiful thing about Elixir/OTP in general, is because you can approximate all those things that I listed above with OTP and core Elixir/Erlang libraries. You can't do that with rails, you need those other libraries/technologies/DSLs etc.


How do you "approximate" stuff like retrying failed jobs and persisting them to disk then? You use whatever the Elixir community came up with which is Oban that uses PG or Exq that uses redis. Sure hobby projects won't need an actual queue. You don't need Sidekiq for toy projects as well with Rails simply use the memory store, it can take you pretty far.


literally on the Exq github readme: https://github.com/akira/exq#do-you-need-exq

"While you may reach for Sidekiq / Resque / Celery by default when writing apps in other languages, in Elixir there are some good options to consider that are already provided by the language and platform. So before adding Exq or any Redis backed queueing library to your application, make sure to get familiar with OTP and see if that is enough for your needs. Redis backed queueing libraries do add additional infrastructure complexity and also overhead due to serialization / marshalling, so make sure to evaluate whether it is an actual need or not.

Some OTP related documentation to look at:

GenServer: http://elixir-lang.org/getting-started/mix-otp/genserver.htm... Task: https://hexdocs.pm/elixir/Task.html GenStage: https://hexdocs.pm/gen_stage/GenStage.html Supervisor: http://elixir-lang.org/getting-started/mix-otp/supervisor-an... OTP: http://erlang.org/doc/ If you need a durable jobs, retries with exponential backoffs, dynamically scheduled jobs in the future - that are all able to survive application restarts, then an externally backed queueing library such as Exq could be a good fit.

If you are starting a brand new project, I would also take a look at Faktory. It provides language independent queueing system, which means this logic doesn't have to be implemented across different languages and can use a thin client such as faktory_worker_ex."


Whatever the org is familiar with.

I like the question, though. I've seen small projects that see negligible load, but are mission critical, written in a niche language no one else in the org knows. The language handled the problem good enough, but maintenance costs were massive for what the project was.


You make the bold assumption I know Ruby and if this is a time constrained project I would be more willing to use something I know intimately.

What I'm trying to say is in this case, I'd rather use Elixir and Phoenix as I know that best at the moment.


with those requirements, laravel would probably make even more sense. there's plenty of drop in code to get to 80% of what you need within a day or two and the perf is going to be better than rails.

That said, I'm an elixir developer and I use elixir because I need to handle heavy loads and thousands of daily users with unforgiving uptime guarantees. Elixir lets me do that while keeping my hair.


> Answer: Ruby on Rails. Not Erlang.

Can you justify this?

If you knew them all equally well I would suggest that Elixir and Phoenix would be an excellent choice, although I am definitely stretching the definition of "Erlang" to include Elixir.


RoR in 2021? Dude, that's just sad.


As opposed to Erlang?


My (outsider's) perception is that Ruby came and went, whereas Erlang came and stayed. Talking about their popularity in their niches. It's also much older than RoR, so in that picture it's also likelier to stay longer, regardless of temporary fluctuations.

I'd also like to learn Erlang when I find the time and use it for projects in the future, whereas Ruby was never appealing to me. Each time I had to deal with it, it created a mess in my system.


> My (outsider's) perception is that Ruby came and went,

That's like saying PHP came and went. Just because something is no longer the new hotness and doesn't get discussed a lot on HN doesn't mean nobody uses it. Both Ruby and Rails continue to be updated just like PHP and it's popular frameworks. If you compared the number of websites developed by either compared to Erlang, it's not even close. Elixir & Phoenix would be a better comparison, but Ruby is still top 20 in the Tiobe Index (PHP is top 10), and Elixir is somewhere hovering around the top 50.


I don't see PHP this way. PHP was never the new hotness. It was never cool. Whereas Ruby definitely surfed the fad wave, and this wave is gone now. Similarly, Erlang was not a cool kid, it just was somewhere in the background at telecoms, and slowly started being used in other places. If I had to bet, I'd expect Ruby to be completely gone in 50 years, while Erlang will still be there.


> PHP was never the new hotness. It was never cool

It was kinda the de facto way to make websites at some point, together with Perl. it was definitely cool.


> Each time I had to deal with it, it created a mess in my system

That's fine, that's your subjective experience which I'm not gonna argue with. But if you're trying to say here that Erlang is somehow more popular than Ruby for web development (or in general) that's quite ridiculous, not sure I wanna waste both our time engaging that.




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

Search: