Why We Chose Rails to Build Gitlab

Post by majewsky » Thu, Jan 24, 2019, 12:09 PM UTC

james-mcelwain wrote: post #135

dam5s wrote: post #100

Earlier quoted context omitted.

Why would you not test your code with the same RDBMS you will have in production? Especially if it’s something as easy to install as Postgres? It seems like begging for trouble...

If you're using an ORM, it can be an easy way to ensure that no vendor specific stuff sneaks in. Also, until recently it was difficult to run, e.g., SQL Server in Docker, so Postgres might be easier to test with. Agreed SQLite is a weird choice, but not all integration tests are robust enough to test characteristics of the underlying db, i.e. focus on business logic not performance.

  $ time go test github.com/sapcc/limes/... | grep -v 'no test files'
  ok      github.com/sapcc/limes  0.004s
  ok      github.com/sapcc/limes/pkg/api  0.515s
  ok      github.com/sapcc/limes/pkg/collector    0.449s
  ok      github.com/sapcc/limes/pkg/core 0.006s

Post by purple_ducks » Fri, Jan 25, 2019, 9:15 AM UTC

freehunter wrote: post #162

purple_ducks wrote: post #112

Earlier quoted context omitted.

> we're moving to a more modern solution What exactly qualifies as a modern solution that Java(/jvm?) is disqualified? Syntax, library eco-system, paradigm, type system, cruft? Is "modern solution" some function of blog post count? A social blade type score for how many early-20 somethings are using it? Or is it going to be something "simplistic" & "clear" which will eventually inherit the cruft all other large langu…

None of the people complaining are the developers (the developers like Java). They're all (enterprise) end users. The "modern" solution is something where the customers don't know it's Java, don't have to hear the words "tomcat" and don't bring to mind all the baggage associated with those names. There's nothing wrong with Perl or PHP either, but plenty of end users have seriously negative associations with the techn…

Post by yannovitch » Sun, Jan 27, 2019, 1:12 AM UTC

stanhu wrote: post #105

yannovitch wrote: post #58

"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 … We are still trying to make GitLab use less memory" Honestly, I think that Go is beginning to be where Rails was few years ago, and lots of developer friends want to hop on the Go trai…

I agree that memory requirements are too high, but I think there is a lot of room for improvement without a complete rewrite, which would be very costly. Also keep in mind that a standalone GitLab instance ships with all batteries included: PostgreSQL, Redis, etc., all of which add to the memory requirements. That being said, we are certainly looking at moving performance-critical functions into Go. See the GitLab Wo…