Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why We Chose Rails to Build Gitlab

about.gitlab.com

Post reply on HN
Print view View original

151–160 of 165 posts

Re: Why We Chose Rails to Build Gitlab

#151

Post by joelbluminator »

pry86 wrote: post #150
joelbluminator wrote: post #149

Haters gonna hate. Shopify, Stripe, Github, Gitlab, AirBNB, Fiverr, Bloomberg, Hulu, Kickstarter, Deliveroo, Zendesk, New Relic, etc etc etc. How many more companies does it take to prove the point that Ruby/Rails is a viable option to base a company on?

Same with PHP and its frameworks (lots of haters comes from RoR side, isn't it?) So let's leave this aside :)

I agree, PHP is more than viable to build companies, and has proved it again and again. As did Ruby :) The fact that PHP isn't my favorite language is really besides the point. Those vocal Ruby/Elixir/Go/Node enthusaists who crap all over other battle tested stacks are very immature individuals.

Re: Why We Chose Rails to Build Gitlab

#152

Post by lilbobbytables »

Osmose wrote: post #34
yingw787 wrote: post #21

What I really liked about Ruby on Rails when I took an online course on it were the schema.rb files and `rake db:migrate` command. I don't know if there's an analog in Python, but honestly I think clean, highly structured, maintainable data is way more important than the backend you use. Having the ability to quickly iterate your SQL schemas and roll them back as necessary is essential to shipping high quality featur…

Migrations are rad! Django (the Python equivalent of Rails) has had built-in migrations for several years now: https://docs.djangoproject.com/en/2.1/topics/migrations/

Granted my rails experience is minimal at best, but I really favor Django's migrations. They're pretty fantastic.

Re: Why We Chose Rails to Build Gitlab

#153

Post by pdimitar »

Scarbutt wrote: post #116
pdimitar wrote: post #62

Earlier quoted context omitted.

> The difference being that the Rails ecosystem is infinitely more mature than the Phoenix ecosystem (and community) What are you viewing as mature? It's a loaded word and many people use it with a different meaning in mind. > Ecto is still going through some massive changes (ActiveRecord is comparatively stable) As of the latest release of Ecto -- 3.0 -- the maintainers said they consider it mostly complete and said…

Phoenix can easily give you thousands of requests per second on a $5 DigitalOcean droplet. Rails and several C# and Java frameworks cannot. Phoenix doesn't hold a candle to anything JVM or Golang though: https://www.techempower.com/benchmarks/

That is undeniable. Java and Go are definitely faster in terms of raw performance.

The main value proposition of Erlang/Elixir is: a very acceptable performance combined with unparalleled concurrency primitives, plus resiliency and high availability. Not performance alone.

Re: Why We Chose Rails to Build Gitlab

#154

Post by pdimitar »

jashmatthews wrote: post #127
pdimitar wrote: post #62

Earlier quoted context omitted.

> The difference being that the Rails ecosystem is infinitely more mature than the Phoenix ecosystem (and community) What are you viewing as mature? It's a loaded word and many people use it with a different meaning in mind. > Ecto is still going through some massive changes (ActiveRecord is comparatively stable) As of the latest release of Ecto -- 3.0 -- the maintainers said they consider it mostly complete and said…

> Phoenix can easily give you thousands of requests per second on a $5 DigitalOcean droplet. Rails and several C# and Java frameworks cannot. Elixir + Phoenix is no faster than CRuby + Sequel/Roda today. When Elixir was started the common Ruby version was 1.8, a tree walking interpreter with no parallelism. Today's Ruby is nothing like that.

Could be. I abandoned Rails 2-3 years ago and haven't looked back since. Even then migrating a project to Ruby 2.3 was a huge pain due to the immutable strings feature. It was one of the things that made me throw my hands in the air.

But I almost haven't seen a Rails project using Sequel for 6 years of working with it. 99% of the projects use ActiveRecord.

Re: Why We Chose Rails to Build Gitlab

#155

Post by pdimitar »

inferiorhuman wrote: post #130
pdimitar wrote: post #99

Earlier quoted context omitted.

> To put it another way, if deploying is a pain, scaling is a pain. I can't understand that argument. Would you please expand? --- I agree it doesn't look very trustworthy that the only viable deployment option in Elixir is kind of stalled lately. Of course. What I am saying is, what we have at the moment works plenty well -- if you can get over the fact that enabling deployment in an Elixir app is needlessly complex…

> I can't understand that argument. Would you please expand? See the Github issue linked (and the related issues). Distillery is known broken. Who cares if Elixr or Erlang scales really well if you can't even get it deployed? That Distillery is, for all intents and purposes, abandoned is secondary. It wasn't left in a usable state.

I agree it doesn't look well but you simply can't claim that Distillery is broken. The last stable version works just fine.

Interesting to see an outside take on the situation though. Thank you.

(EDIT: Also, in the issue it's pointed out that a newer Erlang OTP release fixes the problem.)

Re: Why We Chose Rails to Build Gitlab

#156

Post by AnthonBerg »

nothrabannosir wrote: post #146
AnthonBerg wrote: post #145

Earlier quoted context omitted.

I took it as rrix2 were pointing out a tragedy :)

That’s a far better way of looking at it. I now regret not having seen it that way. I guess you see what you want to see :(

fwiw I completely understand! I have also regretted what seems to be an instinct or habit to go for that same perspective. I’m not sure I can explain in a way that makes sense.

Re: Why We Chose Rails to Build Gitlab

#157

Post by mythrwy »

evanelias wrote: post #140
mythrwy wrote: post #46

Earlier quoted context omitted.

I sometimes suspect a folder full of sql scripts would be better than black box migrations (which are a folder full of sql scripts or similar anyway). Migrations are great, until they aren't. Sometimes if you actually manually do the thing you know how it works better and can adjust. I suppose the drawback to that is everyone else doesn't.

Another option is a schema management tool that doesn't rely on migrations at all. I'm the author of one, Skeema [1], for MySQL/MariaDB. Others include migra [2] for Postgres, and sqldef [3] for MySQL or Postgres. These all use a declarative approach [4], where the user just specifies the desired new state, by adding or changing the set of CREATE statements. The tool knows how to run the correct DDL to reach that new…

How Interesting. Thanks!

Re: Why We Chose Rails to Build Gitlab

#158

Post by zmmmmm »

Dirlewanger wrote: post #61
ppeetteerr wrote: post #8

Does anyone ever have to justify using Java for their backend?

It's nitpicky, but Java is just so fucking ugly and verbose. Does Kotlin extend beyond the Android ecosystem? I'd totally consider that if the case.

Consider Groovy if you're interested in something Python or Ruby-like but with access to the JVM and its ecosystem. It's basically the best of of both worlds with almost none of the downsides.

Re: Why We Chose Rails to Build Gitlab

#159

Post by zmmmmm »

stock_toaster wrote: post #56
mey wrote: post #26

Earlier quoted context omitted.

I suggest checking out https://flywaydb.org/ It doesn't have the ORM-ness mapping rails migrate does, but it makes it really simple to organize sql scripts to move/update schema configs.

I personally tend to prefer migrate[1] as it doesn't require java. [1]: https://github.com/golang-migrate/migrate

Java seems ideal as it will be completely cross platform and you can add / update the database drivers after the fact.

Migrate has a different binary for each platform and from what I can see, the support for each database is compiled in, so just to update a driver you are going to be maintaining that binary all over the place.

Re: Why We Chose Rails to Build Gitlab

#160

Post by inferiorhuman »

pdimitar wrote: post #155
inferiorhuman wrote: post #130

Earlier quoted context omitted.

> I can't understand that argument. Would you please expand? See the Github issue linked (and the related issues). Distillery is known broken. Who cares if Elixr or Erlang scales really well if you can't even get it deployed? That Distillery is, for all intents and purposes, abandoned is secondary. It wasn't left in a usable state.

I agree it doesn't look well but you simply can't claim that Distillery is broken. The last stable version works just fine. Interesting to see an outside take on the situation though. Thank you. (EDIT: Also, in the issue it's pointed out that a newer Erlang OTP release fixes the problem.)

Uh, there's also a suggestion that setting NODE_NAME will fix the solution. Unfortunately the issue remains open because Distillery has been abandoned in a non-working (which, by definition, is broken) state.

I would compare Elixr to Go, Java (OpenJDK), Javascript (node) and Rust here. All have passive support for the BSDs, and yet all three have actively maintained native packages (rustup and/or ports tree). That neither the Distllery author nor the BSD users have managed to come up with a solution is quite telling — deployments on Elixir are nightmarishly complex. I'm most familiar with Rust, so in contrast if you look at the the BSD specific issues you'll find a very engaged userbase.

Deploying unmaintained software in production is sometimes a necessity with legacy stuff but is almost always a bad idea for new deployments. Elixir has plenty of passionate advocates but no good deployment or support stories. That's just a long-winded way of saying Elixir/Phoenix, unfortunately, aren't things I would be comfortable deploying in production (Linux or not) no matter how many compelling ideas they dangle in front of you. And, as has been pointed out, Elixr doesn't offer significant (if any performance benefits) over modern Ruby (and by extension Java, Go, or Rust).

vOv

Post reply on HN