[HN Gopher] Why We're Sticking with Ruby on Rails at Gitlab
___________________________________________________________________
Why We're Sticking with Ruby on Rails at Gitlab
Author : mooreds
Score : 208 points
Date : 2022-06-13 15:19 UTC (7 hours ago)
(HTM) web link (thenewstack.io)
(TXT) w3m dump (thenewstack.io)
| brink wrote:
| Anyone find it suspicious how many companies put so much effort
| into justifying how Rails is still a good tech for a mature
| company?
|
| I think the truth is really something like - we prototyped the
| app in Rails, because that's what Rails is good at, now we've
| evolved into a huge and slow application with no type validation,
| but porting the application and switching the team to something
| better and faster would be a nightmare, so we're just going to
| write an article about feeling good about where we're at.
| tmp_anon_22 wrote:
| Rails has a lot of "magic". Which is fine if you only hire
| veteran Rails developers who know the magic, but over time it
| becomes organizationally exhausting because ultimately you will
| have to train people, you will have people leave the org, and
| you'll have people coming from other orgs with way less
| conceptual overhead that keep asking "why don't we just..." to
| methodologies outside the core rails ecosystem.
|
| Rails is perfectly fine but being perfectly fine is an
| unsatisfactory outcome over time.
| ipaddr wrote:
| What would replace Rails?
| sparker72678 wrote:
| > Rails is perfectly fine but being perfectly fine is an
| unsatisfactory outcome over time.
|
| Perfectly fine over time feels like a tremendous
| accomplishment in software.
| Ataraxic wrote:
| I actually disagree that it's suspicious. I think there are
| often trends in programming that despite being touted as newer,
| better, and faster have failed to deliver on that. Ala the
| amazing amount of churn in JS frameworks in the earlier years
| of SPA's and such. An article saying y'know what "X is actually
| good enough" isn't any more suspicious than all the articles
| saying "Y is the new hot thing".
|
| I am biased here because with respect to the products that I've
| helped create the speed of ruby vs js, python, etc. has never
| been a dealbreaker.
|
| Even if porting an entire application wasn't a nightmare, why
| would you ever do it unless your organization was going to fail
| without? Porting entire applications needs to be justified by
| some critical requirement that (in this case) ruby/rails isn't
| meeting.
|
| https://www.joelonsoftware.com/2000/04/06/things-you-should-...
| -- Porting an entire application into a new language can easily
| be a rewrite and not a "port".
| itake wrote:
| Organizations rarely port working code to new frameworks, but
| they launch new products and features with new frameworks.
|
| If you're developing and serving ML models, I'd be surprised
| if they chose to stick with Ruby over Python/Flask.
|
| Gitlab could keep everything "rails" and break out service
| into micro-rails services.
| LordHeini wrote:
| Because Rails is a good technology for a lot of use cases.
|
| If you want to develop a simple crud style app, with user
| login, mail sending and all that stuff it is highly productive.
|
| Performance is okay and certainly good enough for the average
| web project.
|
| Just get rid of the weird parts like turbolinks (unnecessary
| and messes up a lot of js) and don't write APIs using it (can't
| even rename fields easily).
|
| There are similar Frameworks in other languages and they all
| have pros and cons.
|
| Imho when it comes to web frameworks there is way too much
| emphasis on the startup style company and the ones with huge
| traffic.
|
| Companies doing grunt work style web development don't waste
| their time on flavor-of-the-month.js.
|
| If you build a website for a niche company to sell odd
| machinery on, you have to get shit done and you will never need
| to scale.
|
| That means reliable, batteries included, highly standardized
| and easy to use. Rails ticks those boxes really well.
| itake wrote:
| edit: to down voters: please educate me and not just down
| vote because you disagree with my question.
|
| ---
|
| Every tiny rails app that uses rspec ends up with +1hr test
| times due to tight coupling between activemodel and the db
| connections.
|
| Do you know of any good blog posts the describe how to do
| rails testing at scale?
|
| > Companies doing grunt work style web development don't
| waste their time on flavor-of-the-month.js.
|
| Rails devs have to deal with DHH's-flavor-of-the-month.coffee
| (coffeescript, asset pipeline, webpacker, import_maps)
| arcticfox wrote:
| > Every tiny rails app that uses rspec ends up with +1hr
| test times due to tight coupling between activemodel and
| the db connections.
|
| Wat? I mean test times aren't great but I've got several
| thousand specs for what I would call a medium-sized
| application that run in <1m using TurboTests or <3m using
| rspec alone. I can't imagine a "tiny" rails app that takes
| an hour to test. Maybe you're doing a lot of browser
| rendering or something? My app is API only.
| itake wrote:
| I think the fundamental design problem for rspec is for
| each test you create db state (tons of writes), run the
| test (reads and writes), and then tear-down (truncate).
| Each test is at least adding an authorized user (and then
| removing it) at the simplest and at the worst creating
| complicated db state to support relational models that
| must be added and torn down with each test
| (database_cleaner).
|
| Gems like Fabricator or FactoryBot also make the "create
| db state" even more excessive, because developers would
| be lazy and use factory methods that create more than
| they actually need for the test.
|
| For example, one project I stored a tree-structure that
| could be modified by api calls. Each test required re-
| creating the 15 node tree + each node's relational data
| (think node = user and all users must have a profile,
| authorization scheme, etc.).
|
| I never figured out how to avoid resetting the db state
| for each test case.
| jamie_ca wrote:
| This isn't an rspec problem, it's a Factories-for-
| ActiveRecord problem.
|
| The two main options to mitigate are:
|
| - just work with in-memory objects (FactoryBot using
| build or build_stubbed, or just MyModel.new) and
| stub/mock finders as needed,
|
| - or there's this thing people like to hate that was
| introduced in Rails 1 called test fixtures, which allow
| you to prepopulate the database with some initial data
| and then your test just runs in a transaction and rolls
| back.
|
| The best suggestion I've heard recently (though I can't
| recall where to give credit) for managing complexity w/
| fixtures is to write an extremely minimal fixture set
| aiming for 2 instances per model with minimal data
| required to be valid, and then customize it as part of
| your test. For a blog example, that means you have two
| Posts in your fixtures and would write a test around
| drafts by updating one of them to draft status (be it
| state, toggle, or publication date) and then test your
| query, or controller, or whatever. This keeps the data
| churn inside each test minimal, while keeping the out-of-
| scope data minimal as well -- if there's only 2 blog
| posts, all your tests can assume there will be one you
| care about and one you don't, which is useful for testing
| filtering/search/visibility/authorization/etc while
| remaining pretty consistent.
| itake wrote:
| > - just work with in-memory objects (FactoryBot using
| build or build_stubbed, or just MyModel.new) and
| stub/mock finders as needed,
|
| Mocking the finders is obnoxious, since ActiveRecord
| returns a relation class, not an array. Plus stubbing out
| relational coupling isn't easy (e.g. the user model might
| have a `company_name` method that delegates to the
| company table.).
|
| > - or there's this thing people like to hate that was
| introduced in Rails 1 called test fixtures, which allow
| you to prepopulate the database with some initial data
| and then your test just runs in a transaction and rolls
| back.
|
| Fixtures and Factories have the same issue are vulnerable
| to inserting unnecessary data for the test. Models may
| have validation requirements that must be satisfied to be
| stored, but completely unnecessary for the test. For
| example, all users need a `company_id` with a foreign key
| constraint, so to test _anything_ on user, you have to
| insert a valid company as well.
|
| Maybe I need to re-evaluate fixtures though, since they
| would be simpler to run than a factory.
| piperswe wrote:
| The idea is that you write one set of fixtures for the
| whole app that you then use in all tests. You'd have a
| valid company and a valid user in your fixtures, but
| that's fine because you probably want to test both the
| company and user models. In the user model tests, you can
| ignore the existence of the company fixtures, and vice
| versa.
|
| Since the inserts only happen once for the whole test
| suite, the marginal cost of adding more fixtures is
| minimal, so it makes sense to just make the fixtures as
| complete as possible.
| itake wrote:
| interesting. I haven't used fixtures before. Wouldn't
| this make individual tests slow (like in development?)
| since all fixtures must be inserted all the time?
| mscccc wrote:
| I worked on GitHub's Rails app. The main way this was
| solved was by running tests in parallel. It's now available
| in default Rails:
| https://edgeguides.rubyonrails.org/testing.html#parallel-
| tes...
|
| In addition to that, the test suite performance was
| regularly monitored. And like any performance issue, we'd
| instrument and then fix issues as they came up.
| itake wrote:
| (duplicating another comment I wrote to hear your
| thoughts)
|
| The fundamental design problem for rspec is for each test
| you create db state (tons of writes), run the test (reads
| and writes), and then tear-down (truncate). Each test is
| at least adding an authorized user (and then removing it)
| at the simplest and at the worst creating complicated db
| state to support relational models that must be added and
| torn down with each test (database_cleaner).
|
| Gems like Fabricator or FactoryBot also make the "create
| db state" even more excessive, because developers would
| be lazy and use factory methods that create more than
| they actually need for the test.
| mscccc wrote:
| GitHub uses minitest, but same situation.
|
| I don't exactly agree that it's a design problem. I think
| there is a lot of value in testing at a high level
| (controller tests) and having them touch the full stack
| (down to the DB). Gives a lot of confidence that the code
| will work in production. Throwing money at it (running
| the tests in parallel) pretty much solves it.
|
| I have seen FactoryBot use get out of control (creating
| 8x as many records as you'd expect). That's a really easy
| way to slow down a test suite :). One way I've found to
| fix that is by adding tests for the factories, and
| asserting they are only creating what you want them to.
|
| On model tests, another thing GitHub did well was
| encourage using `.build` when possible to avoid writing
| the the DB.
| itake wrote:
| > I think there is a lot of value in testing at a high
| level (controller tests) and having them touch the full
| stack (down to the DB).
|
| There is a lot of wasted work. Each (similar) test would
| insert and then delete the same rows, but make a little
| tweak.
|
| Other languages and frameworks (java, python or golang)
| don't need to test the db and run super quick. Most db
| systems do not actually need to be tested. e2e testing
| can be done manually via curl or qa.
|
| > Throwing money at it (running the tests in parallel)
| pretty much solves it.
|
| Tests still are slow locally.
|
| > One way I've found to fix that is by adding tests for
| the factories
|
| That is interesting. I had a meta-test that would limit
| the number of sql queries a test could trigger.
| worker_person wrote:
| When you hit scale. Rails is not the concern. It's the
| datastore.
|
| All of the major performance problems at scale I've dealt
| with came down to a super giant table that keeps getting
| locked.
| itake wrote:
| In another comment, it said Gitlab moved off
| ActiveRecord.
|
| The fundamental problem with rspec + ActiveRecord is for
| each test: you create db state (tons of inserts), run the
| test (more db reads and writes), and then tear down the
| state. This is very expensive when you have 100,000s of
| tests each taking 500ms.
|
| Rails/rspec does not make it easy to stub db state with
| ActiveRecord.
| worker_person wrote:
| http://underpop.online.fr/r/ruby/rails/tutorial/ruby-on-
| rail...
|
| Use transactional fixtures as much as possible. Minimal
| db usage between tests.
| itake wrote:
| yes, that improves clean up time, but doesn't help with
| all of the db writes you have to make to create db state
| for each test case.
| worker_person wrote:
| Initial state is loaded via fixtures or whatever. (slow
| and expensive)
|
| Transaction is started. Run Test 1 Transaction rolled
| back. (quick)
|
| Test 2 can be run without the expensive fixtures.
|
| Repeat for all tests.
| itake wrote:
| Does this mean if you only want to run the tests for
| `users_controller` during development, you still have to
| load the fixtures for all other tests with each run?
| gepardi wrote:
| I don't think anyone _has_ to use coffee script.
|
| Our company has a large code base. Tests run in about 15
| minutes in CI.
| itake wrote:
| What testing tools are you using?
| rspec+database_cleaner+FactorBot/Fabricator?
|
| How many tests do you run?
| ravenstine wrote:
| > Imho when it comes to web frameworks there is way too much
| emphasis on the startup style company and the ones with huge
| traffic.
|
| That's exactly what is making web development decreasingly
| enjoyable as the years go on.
|
| ~99.5% of the web doesn't need the hyperscalable cool-tech du
| jour one typically reads about on HN. As long as developers
| don't fall for footguns, there's a lot that can be
| accomplished even with a language runtime like MRI. If scale
| becomes an issue, those things can be solved through
| horizontal scaling, optimizing database queries, not doing
| stupid shit that's memory-hogging, and moving expensive
| algorithms into another language. Ruby is perfectly adequate
| for serving HTTP requests. Whenever I've worked on a Rails
| app that everyone was frustrated with, the problems were
| almost always a compound of a bunch of dumbass shit that
| various developers piled on without much thought (otherwise
| I'd have seen them discussed in GitHub or Pivotal stories).
| thr0wawayf00 wrote:
| > so we're just going to write an article about feeling good
| about where we're at.
|
| I've been doing rails for years now, I have yet to work for a
| rails shop that is living in denial about the state their app.
| The batteries-included nature of rails is easily worth the cost
| of no type validation in most companies I've worked for, and
| the teams I've worked with that lean into JS more tend to be
| much, much bigger with a lower developer throughput.
|
| IMO it's a much more sane world to be in than JS and React
| where best practices change every year or two but the company
| repos can't keep up. So you wind up digging for solutions to
| problems that React no longer considers to be a best practice
| and is therefore buried underneath a pile of Medium articles
| discussing the new right way to do things.
|
| There's no such thing as a free lunch.
| malfist wrote:
| Also problematic is that gitlab really really cares what
| programming languages you've worked in before. I've applied and
| they've turned me down because I didn't have enough Ruby
| experience, nevermind that I have plenty of years of experience
| in development and learning another language isn't that big of
| a deal.
|
| Ruby has had it's heyday. It's 15 minutes of fame was a decade
| ago. If they persist in using Ruby and only hiring people with
| extensive Ruby experience, they're going to run out of talent
| AND have to pay over market rate to get people in their
| specialization. Like all the banks and governments forking over
| loads of cash for COBOL and Coldfusion consultants because the
| refused to modernize.
| latchkey wrote:
| It could also be that they didn't want to hire you because
| you aren't a 'believer' in the technology (in that you're not
| already experienced with it).
|
| They have doubled down on Rails, so if they hire people who
| aren't already in the ballgame, they will either be faced
| with people who want to change things (which creates
| conflicts) or have to train people to avoid the speed bumps
| in the existing system (which also pushes people to want to
| change things).
|
| I'm curious, was your position during the interview that you
| were beyond excited to pick up Rails as your next technology?
|
| Finally, you never know... their feedback might have also
| just been a kinder let down... maybe they didn't feel your
| programming chops were up to their required level. Who
| knows...
| ElectricalUnion wrote:
| > Like all the banks and governments forking over loads of
| cash for COBOL and Coldfusion consultants because the refused
| to modernize.
|
| COBOL itself it's actually very cheap and simple; in fact "so
| simple anyone can use it because it's just english" /s
|
| What banks and governments fork loads of cash for, it's a
| highly vertically scalable, performant and redundant system
| that works (and keeps working) under heavy load and
| concurrency. A SaaS cloud (including the ludicrous prices you
| pay for a SaaS when you need to scale your service...) before
| SaaS clouds were a thing. A mainframe computer with a support
| contract.
| jaredcwhite wrote:
| > Ruby has had it's heyday
|
| Yep, it's right now.
|
| > It's 15 minutes of fame was a decade ago.
|
| Nope. Just as popular, if not more so, than ever.
|
| > If they persist in using Ruby and only hiring people with
| extensive Ruby experience, they're going to run out of talent
|
| The best time to become a Ruby programmer or run a bootcamp
| teaching Ruby was five years ago. The second best time is
| now.
|
| > Like all the banks and governments forking over loads of
| cash for COBOL and Coldfusion
|
| Ha.
|
| > learning another language isn't that big of a deal
|
| Actually Ruby has a very specific and long-standing style
| that is subtle and takes a while to pick up. Any Rubyist
| worth their salt can instantly spot code that's simply been
| "ported" over from some other language community. Ruby has a
| "Ruby way", which in large part inspired the "Rails way".
| It's frankly insulting to claim you can just pick up Ruby on
| a whim and it's no big deal. Sure, Ruby isn't hard to learn
| at first, and I encourage all beginners out there to give it
| a real try. You won't be disappointed. But Ruby is also a
| _deep_ language with a rich vocabulary, and it will take you
| some time to master it. In some ways, if you 're an
| experienced programmer from another language community, it'll
| take you _longer_ --because you'll need to unlearn the habits
| you've picked up before that in Ruby might be considered a
| code smell.
|
| I suggest you spend some time gaining actual Ruby experience,
| and then next time you apply for a job asking for Ruby
| experience, you'll have some. :)
| digitalsin wrote:
| >if you're an experienced programmer from another language
| community, it'll take you longer--because you'll need to
| unlearn the habits you've picked up before that in Ruby
| might be considered a code smell.
|
| So much this :) I've been a C# developer for over 20 years
| and I also write quite a bit of Go. I recently decided to
| write my NFT app in RoR with backend / batch processes in
| pure Ruby, and having essentially minimal experience with
| Ruby it has taken a while to unlearn some of the things
| that are nearly instinctive to me with (particularly) C#.
|
| That said, so far I am really glad I did what I did. I love
| Ruby and I think it's incredibly underrated, especially vs
| Python (though Python is also a great language on its own).
| Once you really get a handle on Ruby (and Rails), it makes
| web dev a fun again.
| BlargMcLarg wrote:
| Ruby has been steadily going down as favorite language for
| years. I have absolutely no beef with Ruby, but GP is
| pretty clearly pointing out the disjunct between continuing
| to use a language with a dwindling userbase, and requiring
| that userbase to have professional experience. In its home
| country, GitLab is one of the few to use Ruby to begin
| with.
|
| >I suggest you spend some time gaining actual Ruby
| experience
|
| Which requires those people to get jobs. If they can't get
| jobs in the language, they can't get experience in the
| language. This is already an issue with the more popular
| languages which are converging to the same point.
| FpUser wrote:
| >"Also problematic is that gitlab really really cares what
| programming languages you've worked in before"
|
| I agree that for experienced developer requirement to have
| extensive experience with particular language may not be all
| that important.
|
| But rewriting perfectly working software just because
| developers knowing legacy language is too expensive is a big
| mistake. They would waste way way more trying to implement a
| perfect copy of the old system with "cheaper" developers.
| capableweb wrote:
| > Also problematic is that gitlab really really cares what
| programming languages you've worked in before. I've applied
| and they've turned me down because I didn't have enough Ruby
| experience, nevermind that I have plenty of years of
| experience in development and learning another language isn't
| that big of a deal.
|
| Yeah, I've come across this in loads of companies too. In the
| end, I think those sort of companies don't understand that
| once you grok 2-3 languages, the rest of them mostly
| look/work the same (except the really different ones), and
| they are just looking for "code-monkeys" to program with them
| for a year or two.
| ElectricalUnion wrote:
| > grok 2-3 languages
|
| I don't think most people simply "accidentally grok" or use
| Smalltalk, Lisp or Raku; therefore I consider most people
| don't have what takes to grok Ruby either.
| BlargMcLarg wrote:
| Oh please, Ruby is not some arcane language. It's really
| not all that different from Python, JavaScript, Java and
| C# once you get used to your dev environment. Those
| languages alone cover way over half all the developers.
|
| People here are acting Ruby is anywhere on the same level
| of difficulty for a regular high-level OOP developer as
| C++ or Haskell.
| ElectricalUnion wrote:
| > It's really not all that different from Python,
| JavaScript, Java and C#
|
| I think that being able to dynamically replace behavior
| from almost anything at any point in your program is
| pretty much very different from Python, Java and C#.
|
| The only other mainstream language with this capacity is
| Erlang, and Erlang is not exactly what I would call
| mainstream language.
| weatherlite wrote:
| > I think that being able to dynamically replace behavior
| from almost anything at any point in your program is
| pretty much very different from Python
|
| How so - Python is dynamic. Django does quote some magic
| (e.g defining methods on the fly etc).
| ElectricalUnion wrote:
| Python is dynamic but doesn't provide an easy way for you
| to change the types the language provides, while that is
| more or less expected in Ruby.
| weatherlite wrote:
| Looks pretty straightforward to me
| https://gist.github.com/fwenzel/622519
| corrral wrote:
| > I think that being able to dynamically replace behavior
| from almost anything at any point in your program is
| pretty much very different from Python, Java and C#.
|
| Javascript is pretty popular.
| ElectricalUnion wrote:
| I'm pretty sure Java != Javascript?
| corrral wrote:
| Sure, but it's a very popular language that puts the
| ability to modify behavior at run-time front and center.
| It's not like Ruby is special in that regard.
| BlargMcLarg wrote:
| And you believe that Ruby both does not make it easy to
| learn this concept and makes aggressive use of this
| concept?
|
| I believe you're severally overestimating the impact and
| importance of one quirk when many developers are picking
| up wildly differing languages and decently successful at
| it all the time.
| dragonwriter wrote:
| > I think those sort of companies don't understand that
| once you grok 2-3 languages, the rest of them mostly
| look/work the same
|
| I mean, if you know 2-3, say, static class-based OOP
| languages, other static, class-based OOP languages mostly
| look/work the same.
|
| If you know 3+ languages with wildly divergent paradigms,
| you can probably pick up most new languages even if they
| don't look/work the same.
|
| But if you know 2-3 closely related languages, one that
| isn't closely related to those 2-3 can be problematic.
| corrral wrote:
| _To be fair_ it takes a ton of memorization to be productive
| in a Rails codebase, between lack of static types and tons of
| runtime "magic". Requiring Ruby experience is silly if
| you've managed to write in several languages productively
| already--Rails experience, though, I could see requiring
| that. _Recent_ Rails experience, even.
|
| Which is part of why I've pretty much sworn it off forever,
| after working on several Rails projects over the years. I
| never, ever want to onboard to a Rails project again, if I
| can help it.
| ravenstine wrote:
| Companies justify using Rails publicly because it makes
| financial sense.
|
| There's this meme that Rails "just doesn't scale" and is
| "yesterday's software", but neither are necessarily true. Ruby
| isn't the fastest language, but it's now competitive enough
| that the same critics might as well throw Python under the bus
| while they're at it. There's things I don't like about both
| Ruby and Rails, but it's a perfectly viable and productive way
| to build websites. A very scant number of businesses need to be
| at the scale of Twitter or The Google, in which case Rails can
| be a great choice.
|
| But I imagine Rails is being increasingly dismissed by newbie
| developers as being obsolete and not-cool. Mature companies may
| realize it's in their best interest to communicate that their
| boring-tech works just fine and that they have no plan on
| changing to cool-tech. If it's true, then someone's got to say
| it, right? Someone needs to be interested in working with
| Rails. Not every business has the money to waste converting
| their old apps to cool-tech like Elixir or a React frontend
| with microservices.
| zumu wrote:
| In my experience, scaling RoR is totally doable, but very
| tricky, as the both language and associated frameworks are
| very terse, opaque and by default seem to do the thing that
| does _not_ scale well. Because of all this magic, you have to
| be somewhat of an expert to avoid all the foot guns.
|
| As a new shop, without a known depth of knowledge and talent,
| I'd probably avoid Rails if scaling is a concern, but if I'm
| Gitlab or Shopify or some place with world class Ruby
| engineers, I'm staying the course.
| michannne wrote:
| > But I imagine Rails is being increasingly dismissed by
| newbie developers as being obsolete and not-cool. Mature
| companies may realize it's in their best interest to
| communicate that their boring-tech works just fine and that
| they have no plan on changing to cool-tech
|
| I dont think that's the case. I think Ruby is dismissed
| because it's _not_ a boring language, but has none of the
| safety of the other "shinier" languages.
| mbesto wrote:
| IMHO, the only two valid business criticisms _at scale_ are:
|
| - It's loosely typed and most orgs end up putting in some
| type system since it can get unwieldy
|
| - Performance is poor at scale
|
| Both can be "patched" fairly easily at scale though:
|
| - Start introducing a typing system: https://sorbet.org/
|
| - Split heavy throughput services out into things like Go,
| Java, etc.
| dan_quixote wrote:
| > Not every business has the money to waste converting their
| old apps to cool-tech like Elixir or a React frontend with
| microservices.
|
| I always ask myself (and the team at large) "how much
| time/effort will it take to reach parity using the new tool-
| set?". The answer usually settles the debate immediately.
| solatic wrote:
| > But I imagine Rails is being increasingly dismissed by
| newbie developers as being obsolete and not-cool. Mature
| companies may realize it's in their best interest to
| communicate that their boring-tech works just fine and that
| they have no plan on changing to cool-tech. If it's true,
| then someone's got to say it, right?
|
| That's precisely the problem. If engineers were a dime a
| dozen, then Rails could be a great choice. Boring tech is a
| great place for businesses to be, _in theory_. Back here _in
| reality_ , finding engineers is pretty hard, and the ones who
| we can find, are all only interested in working with Cool New
| Shiny Toys. If we posted a Ruby ad, we wouldn't get any
| bites. It's not used here.
|
| Boring tech is great, until it becomes a noose to hang
| yourself with.
| ravenstine wrote:
| > If engineers were a dime a dozen, then Rails could be a
| great choice.
|
| Are they not, though? The narrative is that there's
| simultaneously too many engineers coming out of school and
| yet it's extraordinarily difficult to hire engineers. Which
| is it? Or are most engineers really that bad that they're
| unhirable?
|
| > Back here in reality, finding engineers is pretty hard,
| and the ones who we can find, are all only interested in
| working with Cool New Shiny Toys.
|
| I definitely believe you, but I wonder how much of this is
| self-fulfilling. Maybe a lot of engineers get into cool-
| tech because more jobs are demanding it, and their
| perception is they'll be quickly obsolete if they work with
| boring-tech. Most newbs seem to look towards startups
| first, which are going to be using cool-tech a lot of the
| time, but there seems to actually be a lot of interest on
| HN in working with boring-tech at either nontech companies
| or BigCo.
| bcrosby95 wrote:
| It's not hard to hire an engineer that can take a ruby on
| rails project and run with it. There's mountains of
| tutorials and books about it. You don't need the best of
| the best for this.
|
| Some people have decided that that isn't good enough for
| their company though.
| solatic wrote:
| No language book can genuinely teach you the ecosystem
| for that language. The ecosystem is many times larger
| than could ever possibly fit into one book, but the
| ecosystem is what provides you with the libraries you
| actually reach for to build things day-to-day.
|
| Expecting engineers to self-teach from a book is
| practically begging for NIH syndrome and a rewrite in two
| years.
| solatic wrote:
| > The narrative is that there's simultaneously too many
| engineers coming out of school and yet it's
| extraordinarily difficult to hire engineers. Which is it?
|
| It's both. You need to be a large company to hire junior
| talent. The local market is mostly startups without well-
| developed production guardrails and well-gardened, too
| long backlogs. The large companies cherry-pick for the
| relatively few junior positions that open and they aren't
| using Ruby internally. Thus the Ruby ecosystem hasn't
| developed here.
|
| > but there seems to actually be a lot of interest on HN
| in working with boring-tech at either nontech companies
| or BigCo.
|
| HN trends senior talent which has been around the bloc
| enough times to know that stacks change and people don't.
| Most of the labor market comes into interviews and want
| to impress you with how many languages they know.
| stevenally wrote:
| I bet you wouldn't hire me, even though I am a very
| competent developer with a long resume. The problem is
| narrow minded hiring. I have never had problem hiring good
| people.
| wlll wrote:
| > That's precisely the problem. If engineers were a dime a
| dozen, then Rails could be a great choice.
|
| If engineers are hard to find then isn't using a framework
| that maximises developer productivity the way to go? Rails
| definitely falls into that category.
|
| Related, we recently advertised for Rails and React
| engineers. We had about the same number of applicants for
| each position but the Rails engineer quality was in general
| higher than the React engineer quality.
| solatic wrote:
| > If engineers are hard to find then isn't using a
| framework that maximises developer productivity the way
| to go? Rails definitely falls into that category.
|
| Languages are not like cars. You cannot take a
| professional Rust engineer and drop him into a Ruby
| environment and expect him to be immediately highly
| productive, as if you were switching him from a Miata to
| a Ferrari. Languages need to be learned all over again,
| their ecosystem needs to be learned, beginner code needs
| to be reviewed by someone senior who is more familiar
| with the language. You can't just make an executive
| decision to go with Ruby because it has a reputation for
| productivity and expect immediate productivity gains.
| hsm3 wrote:
| We've not had a big problem getting candidate streams of
| people who want to work with Ruby. In a way I don't mind
| having an implicit filter against people who only want to
| work with shiny new things, as we don't really want our
| platform filled with everyone's favorite shiny technologies
| any more than we need a shiny language to write a good-
| sized e-commerce web app.
| munificent wrote:
| _> Ruby isn 't the fastest language, but it's now competitive
| enough that the same critics might as well throw Python under
| the bus while they're at it._
|
| You say that like it's a point in support of Ruby, but, yes,
| absolutely, Python should be thrown under that same bus. Both
| languages are _dramatically_ slower than other languages that
| are available. My little hobby programming language with a
| bytecode VM I wrote myself in a single C file is faster than
| Ruby and Python. It would be hard to design a language that
| _isn 't_ easy to make faster than Ruby and Python.
|
| They both pay an incredible runtime performance cost for
| their deep support for dynamic runtime metaprogramming and
| mutability. If you don't want those features, I don't think
| it makes sense to use those languages.
| ravenstine wrote:
| If speed was all that mattered then almost no one would be
| using Python.
| munificent wrote:
| That's why my last sentence starts with "if".
| ydnaclementine wrote:
| I would argue the eventual "bogged down" feel of a Rails
| application isn't ruby itself. It's rather the abuse the
| database takes because ActiveRecord allows you to lazy load
| records so easily by abstracting SQL calls, so you're
| hitting the database many times per request and not
| realizing it until you get bitten. There is an option to
| disable lazy loading at a project level, but I've run into
| gems that assume it's enabled.
|
| For comparison, elixir's Ecto doesn't allow lazy loading
| grimjack00 wrote:
| In addition, for things that can't be done easily with
| ActiveRecord, you can write your own SQL, but then you
| really need to know SQL to get the performance right.
|
| Where I work, our main product is a Rails monolith, over
| 10 years old at this point. The few serious performance
| issues we currently have are due to complicated SQL
| queries written back when the DB was much smaller.
| native_samples wrote:
| These days TruffleRuby can run Ruby at incredible speeds.
| It unfortunately can't run really huge apps at the scale of
| GitLab though.
| wiseowise wrote:
| > It unfortunately can't run really huge apps at the
| scale of GitLab though.
|
| Why?
| kaba0 wrote:
| I guess part Hyrum's law in that big projects depend on
| implementation details to a degree, related but many C
| extensions (though Graal can run these as well, but
| perhaps not all of them), and last I read about it, the
| JIT compiler is not yet that good at optimizing very big
| applications -- it takes a really long time for some
| functions to become hot enough.
| weatherlite wrote:
| > Someone needs to be interested in working with Rails.
|
| A lot of us are. I don't think Gitlab is in any shortage of
| resumes...I tried. Might be the market collapse or whatever
| reason, didn't even get past the initial HR interview. It's
| also possible my country of residence isn't high on their
| list...we are expensive.
| sodapopcan wrote:
| > Anyone find it suspicious how many companies put so much
| effort into justifying how Rails is still a good tech for a
| mature company?
|
| No. I would imagine these articles are coming out as a response
| to people claiming Ruby is outdated tech when it's still
| perfectly viable. And I say this as someone who has happily
| moved on from it.
|
| And I would hardly consider a blog post or two "a ton of
| effort".
| weatherlite wrote:
| > who has happily moved on from it
|
| What did you happily move to? I can't find happiness, not in
| Go at least. Go just doesn't care about developer experience.
| sodapopcan wrote:
| Elixir. And it wasn't "because Elixir looks like Ruby"--in
| fact, I personally found having it look so much like Ruby
| detrimental at first since the similarities end at syntax.
| I had a growing interest in functional programming and in
| improving a multi-user web app we were building. Elixir's
| (really Erlang's) concurrency model is the first I've ever
| been comfortable with and able to build a clear mental
| picture of what's happening. The syntax (for creating
| concurrent processes) is a wee bit gnarly, of course.
| There's no perfect world :)
|
| As it stands, if I were to ever want to work in OO again, I
| would go back to Ruby. It's still my local-scripting
| language of choice for things that are too annoying to do
| in bash.
| weatherlite wrote:
| OK. Elixir is a no go for me, there's zero jobs where I
| live and I don't see this ever changing. It leaves
| Python, it was the second most enjoyable (to me) after
| Ruby, and Django is fine. Node is simply too hectic with
| new frameworks coming in every week and Go...oh boy.
| sodapopcan wrote:
| That's too bad. Not that you'd be for sure happy with
| Elixir. Where do you live?
| weatherlite wrote:
| Hey I understand how I sound, I'm privileged to be doing
| this job and get paid what I'm getting paid that it's a
| bit ridiculous to be stressing over stacks. Some people's
| jobs are to fight for people's lives in Emergencies Rooms
| or keep public order in dangerous neighborhoods and here
| I am not pleased that I might have to switch from Ruby to
| Go lol.
|
| > Where do you live?
|
| Sorry for the paranoia but ever since I'v found out you
| cannot delete accounts from HackerNews I tend not to
| reveal too much personal info. But lets just say that on
| quite a large radius there aren't any Elixir jobs
| available to me and Ruby is drying up fast as well. And I
| don't think 100% remote is something I'd be happy in long
| term.
| sodapopcan wrote:
| I complain about work all the time, I didn't think you
| sounded like anything :D
|
| > Sorry for the paranoia
|
| No worries--I thought of that after hitting submit. And
| ya, there are some jobs where I live but I work 100%
| remote in order to be at a company that uses Elixir and
| pays me far more than my own country would. Although I'm
| super happy with 100% remote. I've already blown off one
| of 2 company meet-ups this year, lol (though really that
| was more about having to travel).
| kaba0 wrote:
| There is Java.
| subpixel wrote:
| This isn't about truth-telling, it's about impressing
| enterprise prospects with the _relative_ and self-described
| simplicity of a basket they are considering putting
| some/most/all of their apples in.
| stakkur wrote:
| Given Gitlab's fairly transparent chronicling of what they've
| learned and how they work, I disagree. One of the things I
| like best about Gitlab (as an organization) is their ongoing
| effort to conduct business and process learnings in public,
| and share them.
| andrew_ wrote:
| Astute observation (sincerely, this is not sarcasm). I hadn't
| considered that. It's a puff piece.
| weatherlite wrote:
| I don't get the case that Rails is not working out well for
| them which is implied in your answer. What is the "better and
| faster" tech here that would have made a big impact on their
| business?
| gepardi wrote:
| No
| quest88 wrote:
| I'm more suspicious of companies that choose not to use it.
| TheRealDunkirk wrote:
| Counterpoint: I find it suspicious that so many people on this
| forum take the opportunity to bag on Ruby on Rails every time
| it comes up. It's almost like they hate the fact that it is, in
| fact, a perfectly valid choice of language and platform, and
| they're trying to justify the self-flagellation required to use
| Java for web apps. I've been around the block a couple of times
| now, and done projects in PHP, ASP, .NET, and Java. But I've
| been using Rails whenever possible to make LOB CRUD apps for
| almost 15 years now, and there's nothing that can even hold a
| candle to it for productivity. Still. Things that can take just
| a line or two in Rails often take HUNDREDS in Java & <insert
| popular JS framework>, and be a nightmare to keep square with
| strong typing that's so popular with Typescript now. So go
| ahead, cast aspersions on Rails. I'll be over here, happily
| cranking out features as fast as my users request them, while
| the corporate IT departments at my Fortune 250 take 6 months to
| even put a request on their schedule.
|
| EDIT: As an example, I once rewrote a web app for a department.
| The original was all Java/Struts. It took a team of outsourced
| developers 2.5 years to write. It took me 4 months to rewrite
| it in Rails (having no access to the code), and mine did the
| main operation twice as fast, which meant that you could do it
| online, instead of having to wait for a backgrounded process to
| finish and send email.
| cultofmetatron wrote:
| checkout elixir/phoenix. Its almost as productive as rails
| while having performance within the same realm as go.
|
| pros: imutable data types. ruby like syntax. similar codebase
| organization. super fast. more modular than rails. the
| websocket system is way faster to develop in and deploy.
|
| cons: no runtime metaprogramming but you do have a
| sophisticated macro system. not as many drop in libraries.
| not as many jobs for it yet.
| zumu wrote:
| Unfortunately Elixir just doesn't have the network effects
| of Ruby. Ruby support (libraries, SDKs, first class
| integrations) and popularity (ability to hire effective
| devs) is just an order of magnitude or more higher than
| Elixir.
|
| I say this as a massive Elixir and functional programming
| fanboy.
| cultofmetatron wrote:
| network effects take time to develop. unfortunately it
| doesn't have a major company or foundation pushing it
| forward aggressively. That said, I'm hopeful. its
| defiantly the BEST platform for building anything
| websocket based. the killer apps for picking elixir will
| be anything requiring soft realtime.
|
| case in point, I built my startup in elixir. completely
| agree on the difficulty in hiring but its not hard to
| teach. It was harder for me to find people who knew sql
| well. Unlike active record, ecto embraces sql so you have
| to know sql to use it.
|
| anyways, its time will come. more and more companies are
| adopting it from discord to supabase to <cringe> trump
| media group.</cringe>
| likortera wrote:
| Cons: missing community, a lot less well maintained
| libraries, needs more wheel reinvention, impossible to hire
| experienced developers, far worse tooling and editor
| support.
| rhizome31 wrote:
| This is what people were saying about Python 20 years
| ago.
| paganel wrote:
| The community was there, at least that was my feeling
| when I started learning Python around 2003. What wasn't
| there was of course almost anything web-related, for my
| first "website" in Python I had to resort to using
| mod_python, which was a perfectly fine project in itself
| but which wasn't giving you the same instant
| gratification as PHP did when it came to the web. (there
| was also the Zope ecosystem, but that's a subject in
| itself).
| your_username wrote:
| swman wrote:
| What is "LOB" crud?
| LesZedCB wrote:
| "Line of Business"
| edwinbalani wrote:
| And CRUD -> create, read, update, delete.
|
| By "LOB CRUD" GP means those fairly generic apps that are
| mainly a front-end to some database, with a bit of
| business logic or integrations tacked on. They're not the
| apps making money for a business, they're just helping it
| tick along and do the things that actually bring in
| revenue.
| acoard wrote:
| As LesZedCB said, LOB is "Line of Business". In practice,
| this is where your business-logic resides.
|
| edit: CRUD means Create-Read-Update-Delete. It's a basic
| programmer term for a simple application, or those simple
| parts of it at least. Even something big like Wikipedia, at
| it's core is a CRUD site. Most things are, with business
| logic sprinkled in; but some things aren't CRUD at all (eg
| a video game).
|
| For example, if you're a car dealership your LOB CRUD API
| would handle stuff like submitting new cars, or staffs, or
| associating a sale of a specific car with a specific
| salesman or whatever other biz logic you have. This could
| be in contrast with, say, your Document Storage CRUD API
| which handles integrations with your document storage (eg
| storing things on a SharePoint, or Ceph, or S3, etc).
|
| LOB has no inherent value with regards to microservice vs.
| monolith, it's simply another way to refer to the business
| specific logic. The term LOB is common across business as a
| whole, whereas "business logic" is generally a phrase used
| by programmers about programs.
|
| https://en.wikipedia.org/wiki/Line_of_business
| kaba0 wrote:
| > The original was all Java/Struts
|
| Okay, come on! That is fking Struts, it is hardly a fair
| comparison. Though otherwise I agree that Rails is a great
| choice for almost every CRUD app, like we really should stop
| overstressing it. Just use whatever one we are comfortable
| with and has enough internal knowledge on and with modern
| computers it will be plenty fast enough.
| jcelerier wrote:
| > It's almost like they hate the fact that it is, in fact, a
| perfectly valid choice of language and platform,
|
| why is gitlab is so surreally SLOW then ? even on simple
| projects on powerful hosted instances it's barely tolerable
| leke wrote:
| Interesting! I'm wondering since you have programmed in PHP,
| what has been your experience with that? I assume you would
| be using web frameworks like Laravel or Symfony or
| equivalent. Does Rails still beat those like it did Java and
| <Foo>JS?
| [deleted]
| corrral wrote:
| Rails is incredibly productive for 1-3 people to write
| something from scratch.
|
| As soon as everyone committing code isn't synced up with the
| same knowledge and solution styles, it goes to hell fast.
| It's bad at surviving team transitions intact, bad for
| onboarding once the project is past its earliest days, et c.
| TheRealDunkirk wrote:
| Now, see, I would argue EXACTLY the opposite. I worked
| (briefly) for a Rails "house." I was assigned to a project
| that someone who had left the company had been working on,
| and told to add payment processing. I started working
| through the idea, putting stuff in the places it should go
| throughout the stack. About halfway through the process, I
| finally noticed some code that looked almost exactly like
| my function, "below the fold" of the text editor window.
| Then I started noticing that I had duplicated the little
| snippets of code needed in many files. They looked almost
| the same, and they were in all the same files. In fact, I
| realized that ALL the code to enable the processing was
| already done, and all I had to do was expose it on the
| page. To me, it was a crystal clear example that each bit
| of code needed to do something in Rails has a "correct"
| spot, and it's hard for me to believe that anyone with a
| nominal understanding of Rails wouldn't grok the
| organization, and naturally do things "the Rails way."
| corrral wrote:
| I've worked on four or five Rails codebases. All did
| things "the Rails way". All were quite different, and
| none were plainly incorrect.
| jasonwatkinspdx wrote:
| My experience doing agency work with Rails has been
| similar. Love or hate the opinionated nature of it,
| switching projects was fast because generally you'd just
| know where any given thing's home would be.
| nine_k wrote:
| It's interesting though how you had to re-implement a
| large part before you were able to discover the existing
| code that does what you had needed.
|
| Discoverability problems are not specific to Rails, but
| may have something to do with convention over
| configuration, though.
| nahname wrote:
| That is every project when the team is dysfunctional. Your
| language won't save you.
| corrral wrote:
| Some languages and ecosystems can be _more helpful_ ,
| though, even if none can save you. Rails is memorization-
| heavy and doesn't have static types to aid in navigation
| & reading. Its runtime auto-magic even resists grepping.
| Auto-imports mean you don't even get a decent list of
| which sources are contributing to a given file's
| behavior.
|
| It's also the case that different teams can write it
| pretty differently, depending on gem choices and which
| Rails features they lean on. Plenty of other languages
| and ecosystems are like that, too, but all the above
| stuff means Rails is exceptionally bad, in that regard.
| Lio wrote:
| > Rails is memorization-heavy and doesn't have static
| types to aid in navigation & reading.
|
| Except of course that now it does.
|
| So worst case if you inherit a codebase without static
| types added you can use gradual type as you get to know
| it.
| jshen wrote:
| I've worked on a large rails code base for 10 years, with
| hundreds of developers. It hasn't been any worse than any
| other language I've used.
|
| The worst code bases I've worked on used statically typed
| Java.
| nine_k wrote:
| This is a succinct illustration why magic [1] in
| engineering is an anti-pattern.
|
| [1]:
| https://data.whicdn.com/images/198477032/original.jpg
| dangus wrote:
| At least in Gitlab's case, I think this is spot on.
|
| My biggest complaint about it is that it's slow, and as of the
| last time I used it so many of its functionality didn't auto-
| update until you hit refresh.
|
| I don't know enough about web development to understand whether
| this was a Ruby on Rails problem or a Gitlab problem.
| asaddhamani wrote:
| GitHub is also built using Rails and I haven't found it to be
| slow. Neither the zillions of Shopify stores out there.
| andrew_ wrote:
| > You need a fairly sophisticated DevOps organization to
| successfully run microservices
|
| Yawn. Stopped reading when I reached this. One can make the case
| for their choices without parroting the same old tired arguments
| against alternative choices. Shallow comparisons between Java to
| PHP to Ruby is lazy, and very 2010. If I were in the CEO's
| circle, I wouldn't have recommended this be published. Bad look
| for Gitlab.
| dgb23 wrote:
| From the quoted Wikipedia article (https://en.wikipedia.org/wiki/
| Fallacies_of_distributed_compu...):
|
| Fallacies of distributed computing:
|
| - The network is reliable;
|
| - Latency is zero;
|
| - Bandwidth is infinite;
|
| - The network is secure;
|
| - Topology doesn't change;
|
| - There is one administrator;
|
| - Transport cost is zero;
|
| - The network is homogeneous.
| andrew_ wrote:
| These have been footguns of web development since the 90s.
| [deleted]
| ksec wrote:
| I hope Gitlab could afford to offer some resources towards the
| Ruby and Rails ecosystem.
| wdb wrote:
| Whatever works for them to make the pages load faster. It's
| really slow lately
| pmarreck wrote:
| Elixir/Phoenix would be a much better fit but it's your loss to
| bear if you really do like a big ball of monkeypatched mutable
| spaghetticode
| ajsharp wrote:
| > Organizing your local software systems using separate
| processes, microservices that are combined using a REST
| architectural style, does help enforce module boundaries via the
| operating system but at significant costs. It is a very heavy-
| handed approach for achieving modularity.
|
| One of the most effective and succinct criticisms I've seen of
| microservices: an architecture hack for modularity.
|
| The irony is, it's rarely an effective hack. If you don't get
| your service boundaries right, modularity goes out the window,
| and you're stuck with a bunch of network calls that should be
| function calls.
| marcosdumay wrote:
| It's worse, because now you can't fix your bad boundaries,
| because there are different teams working on each side, and
| different projects under different PMs.
| jasonwatkinspdx wrote:
| When the microservice craze took off a lot of people asked me
| for opinions on it, and said the same thing then I say now: it
| more or less boils down to Conway's law. If you have multiple
| teams that need to iterate and deploy independently the
| overhead may be worth it. But if you're just a small startup
| with a single unitary dev team, and that generally just deploys
| a new version of any changed services all as one lump, it's an
| insane amount of complexity and overhead.
| blobbers wrote:
| While that's true that the network calls should be function
| calls, it means you can scale horizontally in a lot easier
| fashion.
|
| Sure you've got waste at the small scale, but if you're
| building for webscale then you have to realize these are the
| trade offs one must make.
| willcipriano wrote:
| I've seen several times where the overhead of the network
| request is dramatically higher than the work being preformed.
|
| The worst example was a validation microservice that did
| things like "is True" or "is greater than 5" one element at a
| time on a large object. So you'd have an object with 50
| elements and it would make 50 requests to the service. This
| was in the context of a batch processing job that handled
| millions of items, so billions of requests end up being
| created.
|
| I tried to explain that each network request probably does a
| few thousand things like "if request_type == 'get'" during
| it's lifecycle on both sides of the transaction, but nobody
| got it and I quit soon after.
| brianwawok wrote:
| A lot of devs just don't care. They want to do a cool thing
| for their resume. This usually means there is no tech
| leadership that "gets it".
| runevault wrote:
| Resume driven development is one of the most depressing
| things I keep running into in my career. Wanting to learn
| and grow is great, but forcing customers to suffer the
| repercussions of your learning because technology/design
| pattern x is in vogue is closing in on malpractice.
| brianwawok wrote:
| Until there is consequences, why not?
|
| Next time you interview with someone, ask why they
| converet a system to Microservices at their last job? If
| they don't have an actual reason, bin them.
| Beltalowda wrote:
| A lot of people seem to underestimate how fast computers are;
| a lot of times you don't _need_ to scale horizontally, even
| at "webscale". And even when you do, it's not like you need
| microservices for that; sometimes you just run a new instance
| of $app, or spin off one thing to a new service (while
| similar to "microservices", it's not really the same thing as
| the bulk remains monolithic).
| vlunkr wrote:
| > you can scale horizontally in a lot easier fashion.
|
| I think you need to define "easier" here. It's easy to launch
| more instances of your rails app.
| revskill wrote:
| As long as microservices don't share database, then all is
| fine.
| nine_k wrote:
| Why, SOA is a reasonable concept, and does help scaling. Say,
| billing, ETL and batch processing, and Web backends can live as
| separate services all right.
|
| Going with _micro_ -services is another story, and it makes
| sense in a more narrow gamut of circumstances. Say,
| microservices may be a great fit for AWS Lambda-style
| deployments, but this assumes spiky, sparse load patterns.
| nonameiguess wrote:
| It kind of feels like Sid is lying through his teeth here, as a
| person who deploys and maintains a private Gitlab installation,
| along with a whole host of other core platform services for
| internal use. Gitlab is by far the most modular off-the-shelf
| product I've encountered outside of JFrog's Xray. Look at their
| official Helm chart: https://gitlab.com/gitlab-
| org/charts/gitlab. Gitlab itself consists of 14 sub-charts and
| it also bundles 4 third-party sub-charts for object storage, a
| web proxy and ingress controller, certificate management, and
| the internal container registry. Gitlab without the third
| parties _I believe_ consists of 15 distinct containers.
|
| I don't think it matches what most people think of when they
| hear "monolith." It is absolutely not a single process only
| communicating between components via function calls. Many of
| the Gitlab core services, such as Gitaly, are written in Go, as
| well, not Ruby, though they also have "gitaly-ruby" as a
| testing service that can be used by developers not comfortable
| with Go.
| john_cogs wrote:
| GitLab team member here. Sid addressed GitLab's use of Go in
| a comment on a previous discussion of this article from last
| week: https://news.ycombinator.com/item?id=31687289
|
| He wrote: "We're moving the 20% of the app consuming 80% of
| the compute to Go."
|
| His comment also highlights another benefit of the way our
| core services are structured: reusability.
| native_samples wrote:
| He mentions gitaly in the blog post.
| Srikanth wrote:
| This probably is the reason why it works in some settings.
| Anecdotally, as someone with more domain/functional knowledge
| and operations knowledge than knowledge of frameworks, I found
| microservices architecture with good functional test coverage a
| better way to deal with a team of programmers like me
| (basically, a typical team in an offshore IT consultancy
| building enterprise applications using SpringBoot and Node.JS).
| Ship the service as early as possible with available talent and
| then get someone really good with that programming language or
| framework to deal with performance bottlenecks within the
| microservice. I see it basically as a way to limit the blast
| radius of the applications. Of course, as you said, get the
| boundaries wrong and you have a bigger problem.
| ryanmcbride wrote:
| Yup I've seen it at just about every company I've worked for. A
| cluster of microservices that is really just a distributed
| monolith. Is it really a microservice if changing one part of
| it requires making echoing changes to every service downstream?
| Is it really a microservice if one part breaking causes the
| entire system to fail spectacularly?
|
| I feel like the pendulum is starting to swing the other way as
| companies learn that microservices aren't the end-all solution
| to their process problems, and that prioritizing new features
| every sprint and constantly pushing housekeeping, bugsquashing,
| and system improvements will result in a broken collection of
| microservices just as quickly as it resulted in a broken
| monolith.
| cogman10 wrote:
| > prioritizing new features every sprint and constantly
| pushing housekeeping, bugsquashing, and system improvements
| will result in a broken collection of microservices just as
| quickly as it resulted in a broken monolith.
|
| Now, HTF do you convince a C-Level of this truth? Seems like
| there is never any time for any sort of housekeeping until
| the house is literally on fire and the whole world is looking
| at our smoke pillar.
|
| Even then, they'll usually be like "Ok, take 2 weeks to fix
| all our architecture problems and then get back to work on
| new features!". As SOON as the fire is doused, they want to
| move on rather than cleaning and removing the flammable
| material and the flame that keep starting the fire.
| mixedCase wrote:
| You don't, it's not his job to care, it's yours.
|
| And just like you don't ask permission for writing down a
| line of feature code, you don't ask permission for
| maintenance work. You just do it and schedule it
| accordingly to business needs to the best of your ability.
| And make sure not to apologize for doing your work or treat
| maintenance work as "unimportant" because that is how it
| will be perceived.
|
| It does get tricky when you have a manager defining tasks
| and you have yet to determine whether their job is to be a
| technical manager (and is adequately competent) or a nerd
| babysitter/translator. In the former case it's good to run
| maintenance projects by them if they need active, dedicated
| time as opposed to something you can mostly do during
| downtime. In case it's the _other_ kind of "manager", and
| you've already tried and failed to convince them to
| prioritize basic stuff, you have to just put it inside
| other estimates and rope in the rest of your team to do the
| same and/or polish your resume.
| bcrosby95 wrote:
| It's tricky when it gets to the point that you need
| specific tasks to clean things up.
|
| But lots of developers think _any_ amount of cleanup
| needs to be scheduled. No, it does not. When you build on
| a feature, you modify the feature so that you can
| actually build on it in a reasonable fashion.
|
| Lots of developers will, instead of doing that, shove
| round pegs into square holes. There's nothing about a
| task that says you have to do it in the sloppiest,
| shittiest way possible. It's like the plumbers that cut
| through your floor joists because that's the easiest way
| to get their drain in.
| the_gipsy wrote:
| Gotta get their PRs merged fast to look good and be a
| team player (with the project/product manager).
| pojzon wrote:
| > You don't, it's not his job to care, it's yours.
|
| Last time I checked it was the job of Project Manager to
| decide which tasks land on the sprint backlog as he
| decides the priorities of what has to be delivered.
| Literally written in the job description.
|
| As a developer you can create a plan/tasks about
| decreasing technical dept, but its never your work to
| prioritize that, coz you dont know whats the priority of
| upper management..
| criley2 wrote:
| In any sane system, technical debt isn't backlogged and
| prioritized by project managers, it's simply a tax on all
| work.
|
| The point of "just doing" your technical debt isn't that
| you're stealing time from the PM, it's that when an
| engineer estimates their work, story points the next
| feature and everyone is deciding on the time frame, that
| process should implicitly include ~20% of time for you to
| continue to fix and update and improve things.
|
| Most PM's I've worked with do not care about that 20%, in
| fact, they're happy that we're taking the time to do it.
| They just want accurate estimates so they can tell
| stakeholders a realistic time frame and somewhat meet
| that goal. All you have to do is bake your 20% in and
| everyone is happy.
|
| Honestly if I worked for a company that micromanaged my
| time so closely that I was prevented from cleaning up
| technical debt and fixing things, I would still clean
| things up and be good at my job and let them fire me for
| it (or be searching and leave anyway). No PM, no middle
| manager, and no executive can ever make me sacrifice the
| quality of my work. They can only replace me with a
| monkey that won't have the same issue.
| polotics wrote:
| dot dot dot Hello! you do know the priority of upper
| management: they prioritize their own personal best
| interest, and as much as the board and CEO manage the
| incentive structure, this will be aligned with their fat
| bonuses. so, dot dot dot. do the same: if something
| creates pain for you, dispose of it.
| cogman10 wrote:
| I've got two choices:
|
| - I can work with the current architecture and ever
| inflating accruing debt (yet slowly inflating) feature
| times which ultimately is acceptable by PM. This will get
| me pay raises, bonuses, and praise.
|
| - I can work on the annoying stuff which product does NOT
| want me working on, does decrease feature times, and does
| decrease debt. This will get me chastised, if I get any
| praise from my local team members, I don't get it from
| the people paying me.
|
| Working around the system is punished. Working through
| the system is rewarded. I get my fat bonuses by making my
| PO/PM happy. I don't get fat bonuses making my life
| easier.
| cogman10 wrote:
| Bingo.
|
| My quarterly deliverables are defined by the product guy
| above me. His priorities are defined by the product org.
| Ultimately, the CTO/CEO are the ones that set and tell
| them to allocate stuff.
|
| I can RAISE issues that need to be addressed to product,
| but generally speaking, dev doesn't have a seat at the
| table when it comes to prioritizing stuff. Instead,
| that's all driven by sales. Sure the company SAYS they
| do, but the practice isn't there. Dev requests are
| routinely ignored to the point that dev stops making
| them.
|
| Perhaps this is just my org that's dysfunctional, doesn't
| feel that way though.
| mixedCase wrote:
| Your org is most definitely dysfunctional. If you meant
| to say your org doesn't feel too out of ordinary, then
| it's not wrong depending on what industry sector you're
| working in.
|
| I'd summarize my comment again: if management doesn't let
| you do job properly you can suck it up, leave, or just
| fix things without asking anyone. But ask yourself, do
| you care that much about that company to not just move
| on?
| mixedCase wrote:
| It's what I tried to address in the second part of my
| comment.
|
| A lot of teams don't have dedicated PMs in the first
| place, but for those who do get those jobs there's an
| extremely wide and well-distributed gamut of competences
| and skill sets, even more than developers I'd say. And
| you have to figure out whether you got a proper one, in
| which case it's the right thing to run such tasks through
| them when non-trivial, and then there's the rest. It
| depends on which market bubbles you've worked in to
| determine whether this latter group is an outlier or the
| norm.
| lamontcg wrote:
| > you dont know whats the priority of upper management..
|
| well, upper management has absolutely no clue about the
| state of your codebase.
|
| i don't understand how anyone can think that top-down
| driven engineering like this is healthy or correct
| organizational flow.
| cogman10 wrote:
| Unfortunately, us bottom guys don't generally get to pick
| whether or not the org is bottom up or top down.
|
| Guess switching jobs is always an option, but what I've
| gone through is basically watching as an org grows it
| getting switched from being a bottom up to top down org
| because the C level guys want more control over
| everything.
| mperham wrote:
| Farmers have to let fields lie fallow every N seasons,
| gardens must be weeded.
|
| You could easily argue that if a CTO or VP Eng doesn't
| already understand and agree with this, they aren't
| qualified for the job.
| jasonwatkinspdx wrote:
| > Now, HTF do you convince a C-Level of this truth? Seems
| like there is never any time for any sort of housekeeping
| until the house is literally on fire and the whole world is
| looking at our smoke pillar.
|
| I've had minor successes with advocating for a tik / tok
| approach, ie every couple iterations you have one iteration
| where new feature work is banned vs cleanup, bugs long
| ignored in the backlog, etc. I haven't found a simple way
| to explain this, but product centric executives do seem to
| see "ok, they get one iteration of what they want in trade
| for me getting what I want in the others" as a reasonable
| trade to keep the dev team happy.
| native_samples wrote:
| It's probably the predictability and bounded costs that
| help.
|
| I've been on both sides of this. I've been on projects
| with tech debt, but I've also had lots of experiences
| where new developers join a project and _immediately_ ,
| before _even seeing the code at all_ , announce that they
| enjoy "making code clean" and "cleaning up tech debt" and
| where is the tech debt they can refactor away? Or they'll
| join, spend literally 20 minutes reading the first file
| they come across and then start pronouncing the decisions
| made by their new collegues 18 months ago as obviously
| "legacy" or "hacky".
|
| That's usually a sign of trouble. The whole concept of
| tech debt or "cleanness" is very under-defined. One man's
| tech debt is another man's pragmatic solution, or even
| clean design.
|
| The last company I worked at is basically being killed by
| this problem. The technical leadership is weak and agrees
| to what the engineers say too easily. Theoretically
| there's a product team but they aren't technical enough
| to argue with the devs. The moment the company started
| getting product/market fit and making good sales the devs
| announced the product - all of three years old - was
| riven with tech debt and would need a massive rewrite (it
| didn't, I worked on it and it was fine). Three years
| later their grand rewrite still didn't launch. Utterly
| pathetic. The correct solution would have been to crack
| down on that sort of thing and tell devs who wanted to
| rewrite the product that they were welcome to do that,
| somewhere else. Or, they could get back to adding
| features that would actually make users happier.
|
| I think a lot of companies have had that experience - the
| sort of devs who are obsessed with "clean code" and "tech
| debt" often exhibit extremely poor judgement and can end
| up making things worse. Especially if the product has a
| naturally limited lifespan anyway due to e.g. pace of
| change in the industry, it can be fatal to spend too much
| time on meta-coding.
| pojzon wrote:
| No architectural design is an ,,End of all best solution".
|
| Best solution is to get very smart ppl and listen to them.
|
| Thats the part most companies fail at.
|
| Until Software Engineering becomes a real ENGINEERING,
| companies will do half-ass job just to push something out and
| make quick bucks.
|
| Rarely you gonna see nowadays a craftsmanship brilliance.
| ryanmcbride wrote:
| Exactly
| andrew_ wrote:
| Agreed. The kicker is knowing what those boundaries are and
| avoiding them. I really enjoy working with microservices for
| async tasks, and I think they're really well-suited to them. I
| really dislike inter-service dependencies. And of course,
| there's nothing wrong with a few, small monolith services. It's
| all about the right tool for the right job for me, and being
| too prescriptive to a particular architecture comes at a high
| cost.
| ravenstine wrote:
| A better first approach would be to try and remove roadblock
| and bureaucracy that are encouraging developers to actually
| consider microservices. Those are of course not the only the
| only arguments for microservices, but I do think they're a big
| one that more often goes unsaid than the modularity. You can
| have modularity in a monolithic app, but for some reason many
| teams don't actually take modularity seriously; they ask that
| everything be object-oriented and call it a day, as if writing
| a `module` in Ruby means you've made things modular.
| Microservices become appealing when the process to have
| monolithic code reviewed and deployed is long and painful,
| since they are by definition small, decoupled, and simple to
| deploy. Of course it often doesn't quite work out that way, in
| which case a monolith would have worked anyway.
|
| But it's unlikely things will change in coding culture so long
| as there's the perverse incentive for businesses to encourage
| their engineers to use hacks out of expediency. Hacks
| inevitably make things really hard down the road, create
| mysterious problems that are hard to solve, and the solution is
| often to add bureaucracy or switch to microservice
| architecture.
| ar_lan wrote:
| Yeah, I agree.
|
| I've worked with a variety of monoliths. The biggest
| complaint I've had from companies who utilize that
| architecture is that I shouldn't have to run entire pre and
| post pipelines to make a minor change to an internal function
| that only affects one package in the entire repository.
|
| This is solvable, but it is a problem - one that causes a lot
| of engineers to consider starting fresh in a new repo anyway.
| Multiple repositories inherently solve this for you - but
| bring about _other_ problems.
|
| In my opinion - most projects don't need microservice
| architecture in the sense of separated binaries. Typically,
| they can be written with clear boundaries within the monolith
| such that, should the time come when scaling concerns are
| real for certain applications, then they can be ripped out as
| needed into their own binaries.
| rgbrgb wrote:
| Agree.
|
| The problem you describe is the inverse of the common
| testing problem you see with microservices (a dependent
| service changed without kicking off downstream tests
| against the new version). I'd take your version any day...
| It's easier for me to make tests faster and/or correctly
| identify which should run on a change if they're all in one
| repo as opposed to making network calls to each other
| across a service boundary. Also, clearly always better to
| run superfluous tests than to skip necessary tests.
| potbelly83 wrote:
| Interesting question arises here. Given most shops are now
| using interpreted languages, is it possible to make a
| change to say a .py file and ONLY deploy that .py file to
| production? i.e. do incremental releases
| ar_lan wrote:
| I don't know if "most shops are now using interpreted
| languages" is an accurate statement :) (I actually don't
| know).
|
| But I think that's definitely an interesting idea (likely
| with some small levels of extra caution with some
| specific high profile files, like an API
| definition/endpoint or something).
| potbelly83 wrote:
| Ha no worries, to be fair most of my working life has
| been spent at C++ shops. I guess Windows does something
| similar via dlls.
| pojzon wrote:
| The issue was rather about the fact that changing that
| single .py file can have impact on a service A and
| service B which depend on service C where the file was
| changed.
|
| In microservice world, you have to run e2e tests because
| thats the only place where you can really guarantee the
| system will work as you expect.
|
| Pacts wont solve that, integration test - the same, units
| w/e.
|
| Running a monolith test is overall faster than spinning
| 20 microservices, beinging every db to specific atate and
| running tests.
| jhgb wrote:
| > The biggest complaint I've had from companies who utilize
| that architecture is that I shouldn't have to run entire
| pre and post pipelines to make a minor change to an
| internal function that only affects one package in the
| entire repository.
|
| Perhaps that sounds like the problem is not with the
| monolithic architecture but with the internal processes? If
| you "shouldn't have to" do something, then why do it?
| ar_lan wrote:
| Monolithic architectures default to this kind of
| methodology, though. You have to instrument tooling to
| identify what tests should be run when these
| files/services/etc get affected in order to optimize the
| developer flow in a monolith.
|
| With several repositories you get this for free, with a
| trade-off of other difficulties.
| jhgb wrote:
| These days I'd imagine that pretty much any profiling
| and/or coverage tool worth its salt should be able to
| gather this information automatically.
| native_samples wrote:
| A lot of teams use tools that can do this sort of thing
| OK out of the box. I've set up CI to only run affected
| tests and use incremental builds in the past. My current
| project has incremental CI.
|
| The core problem is actually dev teams. Every time I've
| tried to implement incremental CI when I wasn't in a
| position to force it through, people fought against it,
| complained, moaned etc until higher level management gave
| in. The problems were:
|
| 1. People liked the feeling of every test passing every
| change. It made them feel safe and like they could point
| the finger at CI if something went wrong, because if
| every test passed it's definitely not their fault, right?
| But this leads to slow builds and then they complain
| about that instead. However this is preferable because
| slow builds are the project manager/TL's problem to
| solve, not theirs, so there's a built-in bias towards
| over-testing.
|
| 2. If there's any issue with the build system that causes
| one test run to affect another in some way (shared state
| of any kind), then incrementality can cause hard to
| understand flakes. Sometimes tests will just fail and
| it'll go away if you force a truly clean rebuild. Devs
| hate this because they've been taught that flaky tests
| are the worst possible evil.
|
| 3. Build systems are generally hard-wired for
| correctness, so if you make a change in a module that
| everything transitively depends on, they'll insist on
| retesting everything. This is reasonable from a
| theoretical perspective, but again, leads to very slow
| builds and people finding ways around them.
|
| 4. Work-shifting. Splitting stuff out into separate build
| systems (separate repos is not really the issue here),
| may appear to solve these issues, but of course in
| reality just hides them. Now if you change a core module
| and break things, you just won't know about it until much
| later when that other team updates to the new version of
| the module. But at that point you're working on another
| ticket and it's now their problem to deal with, not
| yours, so you successfully externalized the work of
| updating the use sites to someone else.
|
| Competent firms like Google have found solutions to these
| problems by throwing hardware at it, and by ensuring
| nobody was able to create their own repositories or
| branches. If your company uses GitHub though, you're
| doomed. No way to enforce a monorepo/unified CI
| discipline in such a setup.
| marcosdumay wrote:
| Out of curiosity, how long is a full build on that place?
|
| I wonder what does it take to give up those points, as
| they are very good things to have. I can't imagine I
| would give up on them if builds took around an hour,
| maybe a day.
| denysvitali wrote:
| Why not Crystal?
| AtNightWeCode wrote:
| As the saying goes in my country, don't practice javelin in a
| green house.
|
| The coupling between GIT with the surrounding services and
| software architecture is just a big joke. Microservices is a
| terrible match with GIT. Get rid of GIT instead.
| PointyFluff wrote:
| "Because we can't write in rust"...I am assuming...I don't care.
| mdaniel wrote:
| I dunno how this eluded the dupecheck, but it's been submitted
| several times:
|
| https://news.ycombinator.com/item?id=31684529
|
| https://news.ycombinator.com/item?id=31693971
| zzzeek wrote:
| Well since the only choices that exist are Java, PHP or Ruby, you
| made the right choice!
| macspoofing wrote:
| To each his own, but the only reason to go with Ruby is in this
| case is if you already have a large legacy codebase and
| internal Ruby talent. For greenfield, stay away from both PHP
| and Ruby.
| FpUser wrote:
| >"Well since the only choices that exist are Java, PHP or Ruby"
|
| Nope
| Arubis wrote:
| Parent comment is phrased this way because TFA only presented
| and evaluated those options.
| ElectricalUnion wrote:
| > Java, PHP or Ruby
|
| Funny, since for a long while, the "correct" way to run Ruby
| workloads in production was to run JRuby, therefore Java.
| ARandomerDude wrote:
| Not really.
|
| 1. Java != JVM
|
| 2. If JRuby is basically just Java, then keep going.
| Everything becomes binary at some point, therefore
| Python/JS/Ruby/etc are just binary.
| systems_glitch wrote:
| Worked on a big project like that once. The day we put JRuby
| out to pasture was a great day indeed.
| TheRealDunkirk wrote:
| I've been using Rails for 15 years, and probably written or
| supported 20 apps with it. In all the reading I've done on
| it, and all the work I've done with it, I've never used
| JRuby, nor seen it implied that this was the "correct" way to
| run an app in production. As an appeal to authority, Heroku's
| default is MRI.
| wlll wrote:
| > Funny, since for a long while, the "correct" way to run
| Ruby workloads in production was to run JRuby, therefore
| Java.
|
| cite please?
|
| I've worked with Rails since 2008 (as well as a lot of other
| languages) and JRuby has rarely been used.
| dijit wrote:
| jruby was definitely the play in 2008-2012, reason being
| that puma wasn't out yet and everything else was doggedly
| slow, so you used to use tomcat or glassfish.
|
| Since jruby is being interpreted into java (thus,
| bytecode), the resulting performance (throughput and
| latency) was a lot better and the lack of jemalloc (a good
| allocator by most means!) meant that your memory growth was
| a little more sawtooth and a little less... growy.
|
| I think these days most folks are just running something
| like puma.
| Rhedox wrote:
| Java is hard to use?
|
| Seriously?
| mschuster91 wrote:
| Tomcat is an archaic goddamn mess with _so many_ pitfalls and
| difficulties to get it actually performant on a production
| system it isn 't even funny to make memes out of it.
|
| Not to mention the crap tooling choices (ant vs gradle vs
| maven), the tendency of Java applications to eventually bloat
| in RAM consumption over time due to memory leaks or the fact
| that Java unlike PHP doesn't punish a developer for wasteful
| development. With Java apps, startup times of minutes are the
| norm, the worst thing I ever saw written in it was an
| "enterprise" CMS (!) that, while definitely more capable than
| Drupal or Wordpress, takes a 32GB RAM machine to develop on,
| wants a 64GB or more machine as hosting and takes half a
| goddamn hour to boot.
| ElectricalUnion wrote:
| It's so hard to get it configured right that instead of
| deploying your app to Tomcat, you embed Tomcat in your app
| and letting the framework deal with the configuration, like
| in Spring Boot.
|
| Of course it means you end up with several
| dozen/hundred/thousand copies of Tomcat...
| geodel wrote:
| And now I have to deal with this supremely crappy Spring
| Boot which would convert compile time Java errors to
| runtime exceptions. Turn already verbose 100 lines stack
| trace from Java into 5000 lines of Spring infested stack
| trace. I guess I just couldn't praise enough this Spring
| Boot.
| jayd16 wrote:
| >and letting the framework deal with the configuration
|
| You could even say that the frameworks put the config on
| rails.
|
| But seriously, just embed the server. Its not a bad deal at
| all.
| mschuster91 wrote:
| That's even worse for optimization since now you have to
| deal with whatever your framework does to get Tomcat up to
| speed and how to set a configuration option for Tomcat in a
| way that eventually ends up at the correct place.
| marcosdumay wrote:
| I have just watched an ops team say "hey there's a security
| problem with our version of Tomcat, we need to update it",
| and then nothing works anymore for a few hours until they get
| every problem.
|
| My observed odds of a point version upgrade on a normal web
| server breaking something is 0%. That includes Microsoft IIS,
| that is a patently known piece of shit.
|
| My observed odds of a point version upgrade on Tomcat
| breaking something is 100%.
| geodel wrote:
| I smile not only because you are right but also because
| tomcat looks like sweet little server compared to next level
| of crappiness peddled by IBM/RedHat/Oracle etc which I have
| misfortune to deal with.
| tootie wrote:
| Yeah, it has fallen out of fashion, but I still say Java is
| pretty much always the best option. Java may be less
| "approachable" than Rails, but 99% of an application's lifetime
| will be spent in maintenance. And anyone coming in cold to any
| software written by any human being is going to have an uphill
| battle. Strict types, rigid structures and verbose syntax are a
| blessing to anyone coming in from the outside to read your
| code. The number language features that make Java the best are
| javadoc and clear stack traces. Anything else is just
| superfluous.
|
| Also, anyone who thinks maven is too complicated while working
| in a language that requires bash hacks to manage runtime
| versions and native dependencies is equally nuts. Maven (JDK
| really) lets you specify language-level compatibility as a
| configuration flag. And can hold multiple versions of external
| dependencies at once without fainting.
| sergiotapia wrote:
| I look at Java and I want to throw up. So much verbosity.
|
| Supervising.Supervisor.SupervisorFactory.get_instance(Supervisi
| ng.Supervisor.SupervisorFactory.Default.init());
|
| No thanks!
| stonogo wrote:
| Aside from the idea of charting random developers' gut instincts
| regarding entire programming languages, the only contribution
| this article makes to the literature is the dubious phrase
| "scalability of innovation." I would have appreciated some
| honesty regarding why they're really sticking with Rails at
| Gitlab: a decade worth of development that would have to be
| rewritten from scratch to little discernable benefit.
| mooreds wrote:
| > I would have appreciated some honesty regarding why they're
| really sticking with Rails at Gitlab: a decade worth of
| development that would have to be rewritten from scratch to
| little discernable benefit.
|
| This is an underappreciated value of sticking with a current
| solution. You know the warts. You know the issues. You have
| significant sunk costs.
|
| The value of moving to a new solution has to be really really
| high, because there are always surprises when doing so
| (business logic that you didn't account for, edge cases that
| only occur once in a blue moon).
| xdennis wrote:
| Sorry to be so off topic, but the bloody hands image is
| hilariously morbid.
| mountainriver wrote:
| Gitlab is one of the buggiest most unreliable applications I've
| used. Not sure how much of that has to do with Ruby but this
| isn't a good endorsement
| bravogamma wrote:
| I like to refer to computing history as much as the next person,
| but the references in this post [0][1][2] came across as rather
| weak and mostly anachronistic.
|
| Computer hardware, networking, and server software has evolved by
| leaps and bounds over the last 5-10 years, let alone 50!
|
| [0] https://prl.ccs.neu.edu/img/p-tr-1971.pdf (1971)
|
| [1] https://en.wikipedia.org/wiki/The_Mythical_Man-Month (1975)
|
| [2]
| https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...
| (1997?)
| goldcountry wrote:
| As someone who has always viewed the winds of web development
| trends with significant skepticism, this article is one of the
| best I've read at explaining why no, you don't need <x language/y
| architecture/z framework>. The technologies that powered the web
| ten years ago still work just fine. Even the ones that powered
| the web 20 years ago often still have their place. Keeping your
| stack boring is frequently the best decision for everyone, save
| for the career climber who wants to put the latest trends on
| their CV for the next job.
| CameronNemo wrote:
| Duplicate post from 3 days ago
| https://news.ycombinator.com/item?id=31684529
| safaci2000 wrote:
| This blog articles feels too black or white.
|
| There's a middle ground between microservices and de-coupling.
| The UI can be written in JS/TS with a backend written in a more
| scalable faster language. It doesn't need to be all or nothing?
| Even if you stick to Ruby pulling some things apart due to
| separate concern/responsibilities is not a bad approach. Aka if
| you have workers/cleanup operations they don't need to live in
| the same code as your REST/MVC code base.
|
| Also, it would be nice if their CI/CD could be defined in
| multiple .yml instead of one giant file that I seem to end up in
| most projects.
| jmholla wrote:
| > Also, it would be nice if their CI/CD could be defined in
| multiple .yml instead of one giant file that I seem to end up
| in most projects.
|
| It can. You can use `include` to include templates and job
| definitions from other files. Also, with child pipelines (i.e.
| trigger jobs), you can run a pipeline defined in a separate
| YAML file.
| safaci2000 wrote:
| sure, I've touched on include a bit and removes some of the
| repetitive code.
|
| I would rather have something like:
|
| release.yml documentation.yml security-scan.yml
|
| I know you can define all these in a common repo and then
| have a few lines to include them but it's not exactly the
| same IMO.
|
| Not to mention that now I need to pull another repo to see
| what is going on and why the task no longer works.
| ifaxmycodetok8s wrote:
| ruby can be just as "messy" as php. what a strange take.
| unicornmama wrote:
| I treat engineering opinions from Gitlab with the same serious
| consideration as financial planning advice from a 6 year old.
| vlunkr wrote:
| They don't really bother to say what their "modular monolith"
| looks like, besides being "well-structured, well-architected",
| and tautologically, "highly modular."
| hbien wrote:
| The author linked to this article to explain it:
| https://medium.com/@dan_manges/the-modular-monolith-rails-ar...
|
| ----
|
| From the article:
|
| We don't have an app/ directory in our Rails project. All of
| our code is either in gems/ or engines/.
|
| Gems contain Ruby code that does not depend on Rails. We use
| ActiveSupport, but we do not use ActiveRecord or ActionPack.
| The gems are all stateless.
|
| Engines contain Ruby code that does depend on Rails.
| Persistence happens at this layer through ActiveRecord. API and
| Web interfaces are exposed at this layer through ActionPack.
| vlunkr wrote:
| Right, but then they say "Although structuring GitLab as a
| monolith has been extremely beneficial for us, we are not
| dogmatic about that structure." And looking at their source
| code, they aren't following that very strictly.
| andrew_ wrote:
| Trading one form of complexity for another.
| rgbrgb wrote:
| Is it a good trade? To me it seems like maintaining a
| gem/library is less complex than maintaining a service that
| exposes the functionality of said gem. No networking,
| deployment configuration, request handling, parsing, host
| monitoring, logging, access control, etc to deal with.
|
| Which do you think is more complex?
| Arubis wrote:
| Nobody needs to justify not replatforming, regardless of the
| involved tech. It's just a sane default. It's when an org _does_
| decide that rebuilding their existing property on a different
| stack that justification is in order.
| dijit wrote:
| > Nobody needs to justify not replatforming
|
| Maybe, but when your software is the piggiest of pig software
| then it _should_ be called into question.
|
| Unrelated to Gitlab, but to give an example of what I mean:
|
| How many installations of Slack are there in the world, or
| Teams.
|
| even with an extremely conservative estimate of 10 million;
| 10mb of ram and 5% of a CPU core has a measurable impact on the
| planet.
|
| With such a wide distribution it's worth calling at performance
| of the platform, even if it's nice that Teams at least
| _supports_ Linux...
| Arubis wrote:
| Oh, yeah. I'm not prescriptive about never replatforming. You
| just shouldn't do it without a very compelling reason and a
| lot of consideration.
|
| If you've got a dozen microservices written in a mix of
| ColdFusion, Salesforce, something Microsofty, and some other
| enterprise slow-and-expensive platform running on leased bare
| metal with a bunch of third-party licensed support software
| and you're burning tens of millions a year on that, and you
| can get a team to rewrite the thing on another stack--
| virtually _any_ other stack, so long as you go from a dozen
| vendors to fewer--you can probably justify allocating your
| entire engineering budget for a year or two just to stop the
| bleeding.
|
| Twitter built their stack on Rails, ran into performance
| issues that they couldn't mitigate, and replatformed. That
| seems to have worked out for them.
|
| Neither of those are most of us.
|
| Sustainable computing, as you're alluding to, is a whole
| other discussion. It's one worth having, but I hope there's
| other solutions out there than "write software the 10x slower
| and harder way", because otherwise anyone who tries it will
| be beaten by a less principled competitor.
| [deleted]
| mdasen wrote:
| I don't use Rails anymore, but I did use Rails from pre-1.0
| through version 3 (and played with later versions a tad).
|
| The best thing about Rails is that it delivers a complete
| package. Rails doesn't come along and say "Oh, you need to use JS
| packages and minify your CSS and compile your SASS/SCSS? That's
| an exercise left to the reader. Good luck dealing with npm or
| yarn, choosing between Bower/Gulp/Grunt/Webpack/Browserify, good
| luck figuring out how to integrate Node into your build process,
| good luck figuring out how to add caching, good luck with async
| background task runners, good luck sending email, good luck with
| validation, good luck with testing, good luck with all the things
| beyond the core competency."
|
| That's one of the things that made Rails so powerful and
| continues to make it great. They offered good practices for so
| much of what you need. I don't want to say best practices because
| I think sometimes Rails has faltered, but at least there was a
| reasonable path and because it was "in" the framework, people in
| the community would talk about it - and talk about how it could
| be better.
|
| I think Rails also pushed the industry toward more structured
| organization of code (rather than just creating a mess), toward
| better testing, MVC and other patterns, etc.
|
| I hate picking on projects that I think are mostly good, but to
| illustrate some things it helps. Ninja Framework (Java) has a
| section "Advanced Topics" which includes things like "working
| with relational databases" and "validation" and "testing".
| Frankly, those aren't add-ons or advanced topics.
|
| In fact, Rails really pushed testing. It's been a while (so
| correct me if I'm wrong), but all their generators built testing
| stubs. Sure, you'd have to fill out the tests, but it gave you a
| place for the tests, a way of running them, and generating the
| file gave you that little push of "oh, this isn't hard" (which is
| especially important for newer programmers).
|
| I think Django and ASP.NET are wonderful, but neither really
| offers a great answer for handling the
| JS/TypeScript/SCSS/SASS/minification stuff that you really want
| for a modern web app. ASP.NET points you to LigerShark's
| WebOptimizer which is good. There are add-ons for Django. But it
| means that you're left looking around the internet for what is
| the "right" path which can simply waste time and put people into
| analysis paralysis. Likewise, there are add-ons for background
| tasks. ASP.NET has the incredibly popular Hangfire. Django has
| add-ons as well. These aren't impossible things to overcome, but
| Rails holds your hand a bit.
|
| Many frameworks don't deal with things like "how do I deal with
| the fact that I want to test my stuff against a database" and set
| that up nicely for you. Instead, it's an exercise left up to the
| reader.
|
| If you're at a giant company where you have a platform team who
| can handle all these things, you don't need Rails. You have your
| own teams making this stuff good for you. If you're a start-up
| with a few engineers, do you want to spend your time figuring out
| how to compile assets, how to wire up MySQL to your tests, how to
| run background async tasks, etc.
|
| That said, I do think Rails went in certain directions that have
| limited it. Static typing has become the way most people want to
| program. People are less interested in "magical" ways of typing
| less code and more interested in understanding how code is
| working. Other languages have become a lot better with lambdas,
| local type inference, less ceremony, etc. and we've seen new
| languages like Kotlin and Go. Other languages are substantially
| faster. Ultimately, a lot of frameworks learned a ton from Rails
| and copied a lot of the best bits. I still think Rails has a
| broader vision than basically anyone else and I think it's a bit
| of a pity that no one else seems to want to have that vision (and
| please point me to projects you think have that broad vision if
| you know of them).
|
| Rails really changed web software. Even if you want to use
| something else, Rails has likely had a huge impact on how you're
| developing web software (even if you don't know it). I'm grateful
| for what Rails taught me and how it impacted the industry even
| though it's been a long time since I've used it.
| silviogutierrez wrote:
| I too found a lack of strong opinions and recommendations for
| using Django with TypeScript and modern web technologies. So,
| shameless plug, I built https://www.reactivated.io . Give it a
| look if you ever work with Django again.
| metaltyphoon wrote:
| Is there a necessity to use minification and bundling when on
| HTTP2?
|
| Why use HangFire for ASP when BackgroundWorkers exist? It's
| extremely simple to use.
|
| I really don't see the advantage of Rails over ASP, meanwhile
| one will won't ever be your bottleneck.
| wdb wrote:
| I always connected BackgroundWorker with Windows apps and not
| ASP(.NET) applications
| resters wrote:
| This is a very insightful comment. I used the same versions of
| rails and (after reading your comment) realized I appreciate
| the same things about it. Thank you for articulating it so
| well.
| andrewstuart wrote:
| If you care abut hiring and recruiting then you would kill your
| Ruby On Rails projects.
|
| In fact, as far as recruiting goes, you really need to switch all
| your projects to either TypeScript, C# or Python. Everything
| else, Java, PHP etc etc is on the decline.
|
| POSSIBlY on the way up is Golang, but again don't use this is
| hiring is a primary concern.
|
| BUT Ruby On Rails has to be one of the worst to recruit for
| unless you're using Fortran or COBOL.
___________________________________________________________________
(page generated 2022-06-13 23:01 UTC)