Why We Chose Rails to Build Gitlab
21–30 of 165 posts
Re: Why We Chose Rails to Build Gitlab
#22Re: Why We Chose Rails to Build Gitlab
#23Re: Why We Chose Rails to Build Gitlab
#24Re: Why We Chose Rails to Build Gitlab
#25Does anyone ever have to justify using Java for their backend?
Before this, I worked for a company that build almost everything in Java and we had to constantly explain why things were in Java and what we were doing to move things to a more modern solution.
But you don't read blog posts about those companies because they choose not to write them. The blog posts you see about the backend technologies are from companies who are proud to use those technologies and want to promote their use of that technology. The companies who use Java (mostly) are companies who aren't going to write blog posts about their backend technology choices.
Re: Why We Chose Rails to Build Gitlab
#26What 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…
Re: Why We Chose Rails to Build Gitlab
#27"Why GitLab are stuck with Ruby on Rails"
See https://docs.gitlab.com/ee/development/architecture.html#com... for more information on what parts are Go.
Re: Why We Chose Rails to Build Gitlab
#28Earlier quoted context omitted.
The advantages of typed languages are too great to not work in them.
The advantages of some particular insight into a business problem far outweigh the particulars of programming languages, for most problem domains.
It’s by no means a panacea but it does eliminate an entire class of error and obviate a related class of unit testing.
Re: Why We Chose Rails to Build Gitlab
#29It's amusing, that you can substitute every reference from Ruby to Python and Rails to Django and article would still make sense. Except for the part about running in production. Seems like Python is a bit ahead there.
Re: Why We Chose Rails to Build Gitlab
#30Earlier quoted context omitted.
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…
- Some programmers don't like functional programming (I'm not one of them)
- Go has static typing and I find it really cuts away bugs
- Go is backed by giants and has the horse power to push forward regardless of "Github stars"
- Go is easy to compile and run on most/many platforms
- I find myself more able to understand third party code
As a web developer, would I use Go as opposed to Phoenix/Elixir? Yes, I am actually using it in production on a fairly big project [1]. I tried Phoenix and I found it "weird" for my liking. The authentication part of a web app was a real deal-braker for me = too complicated to implement (not bad, just too complicated).
I'm the type of guy that brainstorms (90% of my projects are always "close to completion" though) a lot of ideas and wants to go up and running really fast. I can't do that with Python/Elixir/Ruby without many tests written because I don't trust the code/myself all that much.
Where would I use Elixir/Phoenix:
- a chat/support app or anything that relies heavily on websockets
- real-time apps (related to first point)
- apps that rely heavily on distributed tasks