Why We Chose Rails to Build Gitlab
about.gitlab.com
Why We Chose Rails to Build Gitlab
1–10 of 165 posts
Re: Why We Chose Rails to Build Gitlab
#2"Why GitLab are stuck with Ruby on Rails"
Re: Why We Chose Rails to Build Gitlab
#3> Ruby was optimized for the developer, not for running it in production," says Sid. "For the things that get hit a lot and have to be very performant or that, for example, have to wait very long on a system IO, we rewrite those in Go
Since they prefer the language patterns of Ruby but want better performance for concurrent processes, it seems like this would be a perfect use case for Elixir with Phoenix. I wonder if they considered it.
Re: Why We Chose Rails to Build Gitlab
#4> Ruby was optimized for the developer, not for running it in production," says Sid. "For the things that get hit a lot and have to be very performant or that, for example, have to wait very long on a system IO, we rewrite those in Go Since they prefer the language patterns of Ruby but want better performance for concurrent processes, it seems like this would be a perfect use case for Elixir with Phoenix. I wonder if…
quite a big gap between Elixir & Go though for most use cases.
Re: Why We Chose Rails to Build Gitlab
#5> Ruby was optimized for the developer, not for running it in production," says Sid. "For the things that get hit a lot and have to be very performant or that, for example, have to wait very long on a system IO, we rewrite those in Go Since they prefer the language patterns of Ruby but want better performance for concurrent processes, it seems like this would be a perfect use case for Elixir with Phoenix. I wonder if…
quite a big gap between Elixir & Go though for most use cases.
I don't disagree, but Im curious of the ones you're referring to
Re: Why We Chose Rails to Build Gitlab
#6"Why GitLab are stuck with Ruby on Rails"
What would you prefer?
Re: Why We Chose Rails to Build Gitlab
#7> Ruby was optimized for the developer, not for running it in production," says Sid. "For the things that get hit a lot and have to be very performant or that, for example, have to wait very long on a system IO, we rewrite those in Go Since they prefer the language patterns of Ruby but want better performance for concurrent processes, it seems like this would be a perfect use case for Elixir with Phoenix. I wonder if…
> Since they prefer the language patterns of Ruby but want better performance for concurrent processes, it seems like this would be a perfect use case for Elixir with Phoenix.
Elixir does not have the language patterns of Ruby, though it has a deceptive visual similarity.
Re: Why We Chose Rails to Build Gitlab
#8Does anyone ever have to justify using Java for their backend?
Re: Why We Chose Rails to Build Gitlab
#9No offense, but this is just a really weak PR fluff piece. The with only interesting thing is that they use Go for the hit access part.
Oh, and Ruby and multithreading don’t mix, who knew?
I like that if you preface your offending remarks with “no offense” you’re excused.
Re: Why We Chose Rails to Build Gitlab
#10> Ruby was optimized for the developer, not for running it in production," says Sid. "For the things that get hit a lot and have to be very performant or that, for example, have to wait very long on a system IO, we rewrite those in Go Since they prefer the language patterns of Ruby but want better performance for concurrent processes, it seems like this would be a perfect use case for Elixir with Phoenix. I wonder if…
quite a big gap between Elixir & Go though for most use cases.
Would you be able to give an example or two where you would reach for go vs elixir and vice-versa?
I’ve tinkered with Go, and while it was fairly enjoyable to work with on the small scale, but the lack of generics and constant err != nil checks, and Go 2 on the horizon, I decided to hold off on building anything non-trivial with it.
I’m currently rewriting a Rails app into smaller elixir components, the Rails app is mostly consists of several potentially long running processes that gathers large amounts of data from various sources, does some light transformations, and then combines it and outputs it in various forms. Elixir has been immensely more pleasurable to write in, as OTP, along with things like GenStage and Flow, seem like a perfect fit for this task. And, while go’s channels are cool, they don’t seem nearly as powerful as elixirs actor model/OTP — at least for this example.
The one advantage of Go I can immediately think of is using it for some networking heavy app, which is an area Elixir/Erlang has room for improvement, as making some simple outside http requests isn’t nearly as dead simple, iirc.