Does anyone ever have to justify using Java for their backend?
mostly in the industry (finance) I work Java is the default. You need to justify and seek approvals for using anything else.
even things like scala or kotlin?
Why We Chose Rails to Build Gitlab
71–80 of 165 posts
Re: Why We Chose Rails to Build Gitlab
#72Earlier 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 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.
Yeah I've thought the exact same thing before and I've actually tried both.
The clear difference is that migrations are easily reversible. Good migration libraries can also reverse data migrations.
A folder of SQL scripts was very refreshing, but no way could I use that system in a production environment. There's just too many edge cases to keep in your head.
Re: Why We Chose Rails to Build Gitlab
#73Earlier quoted context omitted.
> the lack of generics Earnest question: isn't Elixir dynamically typed? If so, how is Go's type system worse? You can always drop down to `interface{}` (the dynamic type) if you like, after all. > And, while go’s channels are cool, they don’t seem nearly as powerful as elixirs actor model/OTP — at least for this example. I haven't used Elixir, but I suspect this is true. Elixir/Erlang are probably the only two langu…
Elixir and Go are not mutually exclusive though. As another sibling comment said: they serve different niches. I'd always reach for Elixir/Phoenix for any web app, or even API (if it's a big app). Also anything that requires heavy concurrency -- web spiders, data collectors of many kinds, scatter/gather flows (or any multi-stage flows; Elixir makes those processes brain-dead easy to code) -- then Erlang/Elixir are a…
> Elixir and Go are not mutually exclusive though.
To be clear, I claimed nothing to the contrary. :) I only argued that concurrency isn't the only criteria in choosing a programming language for a particular project.
Re: Why We Chose Rails to Build Gitlab
#74Earlier quoted context omitted.
> the lack of generics Earnest question: isn't Elixir dynamically typed? If so, how is Go's type system worse? You can always drop down to `interface{}` (the dynamic type) if you like, after all. > And, while go’s channels are cool, they don’t seem nearly as powerful as elixirs actor model/OTP — at least for this example. I haven't used Elixir, but I suspect this is true. Elixir/Erlang are probably the only two langu…
> Earnest question: isn't Elixir dynamically typed? If so, how is Go's type system worse? Elixir has built in support for type specifications and supports static analysis for (among other things) typechecking via dialyzer, a static analysis tool from the Erlang distribution for the BEAM VM.
Are these widely-used? When I tried kicking the tires on Elixir, it seemed like type annotations (specifications?) weren't used in practice, and they also seemed pretty clumsy (I didn't try hard, to be fair).
Re: Why We Chose Rails to Build Gitlab
#75"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…
Or Elixir, or Rust, or Node. Having spent time with all of these options, Rails is still really really good for a lot of use cases. Go comes nowhere near Ruby's readability for me (but I like the lack of surprise). Personally I'd love something typed, performant, and as readable as Ruby with a convention focused platform like Rails. Elixir + Phoenix is probably the closest I can find, but not a perfect fit. Maybe clo…
FWIW Elixir isn't necessarily lightweight. Memory will stay pretty flat (even during high workloads) but it's not lightweight.
Re: Why We Chose Rails to Build Gitlab
#76"Why GitLab are stuck with Ruby on Rails"
As listed in the article under 'Overcoming challenges' we do replace code in Go and Vue where needed. I do believe Rails is still the most productive framework out there. See https://docs.gitlab.com/ee/development/architecture.html#com... for more information on what parts are Go.
To me, the article reads like "We REALLY don't want to abandon Rails so we rewrite the hot paths to Go". I mean no offense; I just wasn't able to find good argumentation in it for sticking with Rails. To me, the article kind of makes the argument for Go.
"Developer productivity" is not a myth and it does exist. But Rails is very far from the only framework that gives you that.
IMO you should seriously evaluate making your web + API gateway in either Elixir or Go, outline a migration plan and get on with it.
Re: Why We Chose Rails to Build Gitlab
#77Earlier quoted context omitted.
Elixir and Go are not mutually exclusive though. As another sibling comment said: they serve different niches. I'd always reach for Elixir/Phoenix for any web app, or even API (if it's a big app). Also anything that requires heavy concurrency -- web spiders, data collectors of many kinds, scatter/gather flows (or any multi-stage flows; Elixir makes those processes brain-dead easy to code) -- then Erlang/Elixir are a…
> Elixir and Go are not mutually exclusive though. To be clear, I claimed nothing to the contrary. :) I only argued that concurrency isn't the only criteria in choosing a programming language for a particular project.
True. I mostly wrote my reply to help future readers.
Sorry, didn't mean to leave you with the impression that you misworded your comment! :)
Re: Why We Chose Rails to Build Gitlab
#78Does anyone ever have to justify using Java for their backend?
It depends on the project.
Java is the goto language in more conservative environments (e.g. insurance, banking, government) and I never had to justify using it there.
In small shops/startups it’s different. Hype is a real thing and running your backend on “25 year old tech” often does not attract the right kind of people you need to have in this space ;^).
That being said, I’ve been shipping stable and performant backends on the JVM for over 15 years and I could not be happier with the state of Java in 2019.
The ecosystem is amazing. Tooling, too. Talent and jobs are available everywhere.
Also, there is an active effort to modernise Javas syntax and I think it’s going into the right direction.
Re: Why We Chose Rails to Build Gitlab
#79because it was the "the thing" at that time, just admit it.
Re: Why We Chose Rails to Build Gitlab
#80Earlier 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 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.
Manually migrating has the issue of testability and hit by the bus.
I don't believe every migration needs a roll back, sometimes the better strategy is restore from a snapshot/backup.