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.
Why We Chose Rails to Build Gitlab
61–70 of 165 posts
Re: Why We Chose Rails to Build Gitlab
#62> 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. I wonder if they considered it. The difference being that the Rails ecosystem is infinitely more mature than the Phoenix ecosystem (and community). Ecto is still going through some massive changes (ActiveRecord is comparatively stable). Persona…
> 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 they will not do breaking API changes [0]; this part in particular:
"With the release of Ecto 3.0, I would like to announce that I finally consider Ecto to provide a stable API. This means no more new features, although we will continue providing bug fixes and updates. For everyone running Ecto in production, rest assured that Ecto will continue to be a well maintained project with the same production quality and polish that it has today."
So the first part of your statement is factually false.
For ActiveRecord being stable... subjective, I'll give you this much. Try and migrate a Rails 4.0 app to 5.x and come cry with me over a dozen beers. ;)
> Personally I think that Elixr is an interesting language but it's not one I'd want to mess with in a production environment.
Many people and organizations are "messing" with Elixir in production with great -- and increasing -- success.
Phoenix at the moment is one of the very few frameworks that delay your scalability problems much farther into the future than most me and many others have worked with. Phoenix can easily give you thousands of requests per second on a $5 DigitalOcean droplet. Rails and several C# and Java frameworks cannot.
I am not attacking you and I hope I don't sound that way -- but you seem to have a non-factually supported negative bias against Elixir. It gets more mature by the day and is quite capable of very serious work in pretty tough environments. Positive case studies spring into existence often.
[0] https://elixirforum.com/t/ecto-3-0-is-out-and-stable-api/173...
Re: Why We Chose Rails to Build Gitlab
#63What 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…
Every time I try to write some "super simple web app" that I think is much too small for Rails I always end up in spots like this: migrations, then asset fingerprinting, then some quick sanity tests, oh, now I need this other thing and I've cobbled together a creaky messed up version of Rails.
Re: Why We Chose Rails to Build Gitlab
#64What 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…
I agree, and most other commenters still miss the point about what makes Rails so great :
it's not the technical part (you can point slowness, quirks in how the language/framework is used) but the human and business part. It works. It makes adapting to change easy. Yes it's a monolith, yes it encourages fat models, etc. But it works so damn well.
`rake db:migrate` is not so great as a feature (other frameworks in other languages have it), the greatness comes from how well it's integrated with the Rails workflow.
Re: Why We Chose Rails to Build Gitlab
#65i just assumed it was becasue "we didnt know better"
Re: Why We Chose Rails to Build Gitlab
#66Earlier quoted context omitted.
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…
> 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.
Re: Why We Chose Rails to Build Gitlab
#67What 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…
Just wait til you actually work on some production code... For the most part you don't actually want to roll back schemas as you would lose data. And iterating on SQL schemas in a live app involves all kinds of tricky edge cases and backfills, knowing when to make your changes in multiple steps, being careful not to take down the whole thing because you didn't realize a certain change required a full table lock or a certain index would take so long to create, etc.
As is so often the case in Rails, it's set up to be nice and simple for a hello world example but little more. It doesn't actually make things as simple as they seem at first, and you're on your own to figure out which of its niceties are actually helpful and which are dangerous to use that you need to build your own workarounds for.
Re: Why We Chose Rails to Build Gitlab
#68Earlier quoted context omitted.
> 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. The difference being that the Rails ecosystem is infinitely more mature than the Phoenix ecosystem (and community). Ecto is still going through some massive changes (ActiveRecord is comparatively stable). Persona…
> 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…
> but you seem to have a non-factually supported negative bias against Elixir.
If deployments are broken for months[1] with no fix in sight, what do you expect? I'm currently seeing zero requests per second with Elixr. If the sole maintainer of the sole deployment tool is too disengaged to reply to bug reports I don't care one way or another what sort of performance a product (or its fanbase) are claiming. If the product can't be deployed it's not going to scale. Period.
It's a bit silly to talk performance comparisons between Ruby and Elixr as the premise of this article was that Ruby is simply too slow. Are you going to have a harder time scaling Go or Rust than Elixr? I doubt it. I have no idea if you're going to have a harder time scaling Java than Erlang, but Java is popular enough in the enterprise space that finding people with that sort of experience isn't so difficult. The only time I've seen Erlang at scale was with Megacorp's Enterprise Chef deployment. There was easily tens of thousands of dollars in hardware there and the Chef server was still regularly brought to its knees with well less than a thousand total users (and well fewer than that at any given time).
Re: Why We Chose Rails to Build Gitlab
#69"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 close enough though.
Re: Why We Chose Rails to Build Gitlab
#70Earlier quoted context omitted.
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…
> 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 no-brainer. People keep wrongfully underestimating them.
But if I am to write a CLI app or a very heavy-duty network daemon, Go is IMO hands down unbeaten and the best possible choice. Also anything that requires serious number crunching.