Ask HN: Is Ruby on Rails still relevant? I'm currently going through Destroy All Software's screencasts [0]. They're heavily based on Ruby + Rails and TDD, although most of the concepts probably do do translate to other languages. Since the screencasts are over 10 years old now, I'm wondering if Ruby on Rails is still going strong. What resources would you recommend to get into Ruby/Rails specifically? Same question for TDD? Thanks! |
I know some people of the community moved to Rust or Node. But the Rails ecosystem is still the most complete out there.
The framework, as the language, is still evolving, getting quicker and integrating will all sorts of other tools (GraphQL, Elastic, etc).
Ruby is much faster in 2.7/3.x as it was in 1.9/2.0 era.
Rails is starting to try dropping node and all the JS package craziness. But still supports all them. So you can pretty much do HTML-over-the-wire, plain jQuery or go full-blown React/GraphQL/API using webpack or similar.
Interesting, can you give a few names? Just so that I'll know to reconsider if I need to use one of them.
I tried to get used to Go several times but it always failed. Go lacks an interactive console. Its syntax is ugly and very limited and not expressive, which means I had to reinvent the wheel all over the time. Why the heck Go has not even have reduce function? It is true, that using Go ends with a TONS of verbose code. The same functionality in another language can be built in a fraction of the time and will have a much simpler and smaller code size
But having worked with Rails code base, it becomes a guess work in a text editor to know what you're getting in a method. The duck typing makes impossible to be sure for text editors unless you resort to some sort of type hinting and that's not Rails's fault, that's ruby.
In 2022, given among all the choices, I'd probably go to either deno + Typescript or golang.
3 months ago https://news.ycombinator.com/item?id=30022185
These days it's mostly Javascript, Go, some Kotlin.
Regardless I work in Elixir because they can pry BEAM out of my cold dead hands. And Liveview is inspiring all other frameworks to build similar tooling that is unfortunately second-best because Elixir and Erlang's BEAM are so well suited to it's workflow.
London: Rails 237, Django 383, Laravel 149
UK (excl. London): Rails 230, Django 406, Laravel 1001
So, yes, there are less Rails jobs overall but considering there are less than twice as many jobs as with Django, which is powered one of the most popular languages, Rails is clearly still very active in the marketplace.
Although it's a hard choice because the books and documentation and training resources are great in Rails, so easier to level up, but I don't think that's where things are going anymore.
It's tricky more generally to see if a technology is still relevant because there is so much hype of new stuff in web development.
Usually after the plateau of productivity, you don't see too many people talking about a given technology, your only signal of success would be something like Who's Hiring and Cmd + F "rails".
It is for dark matter developers now, SV dark matter but dark matter.
Look for the job market in your region and field and then address e it for yourself
Even just a "Ruby on Rails Tutorial" search on YouTube will get you going, too, if that's more your thing.
I'm building Avo to help developers ship apps faster than ever. Avo is to Rails what Rails is to web development.
For more performance intensive tasks .NET Core is used.
There are much better options, but some people just like the crap they know
DHH's blog video feels pretty dated now. Does anyone have any pointers to a decent video tutorial that starts from the basics?
In this context, I'm still very happy to be developing in Ruby and Rails and it still feels very fresh to me most of the time.
It may come down to, like Vim, it's not exactly in the new stuff department, it's 'niche', even, but the super users and hardcore community apparently will never let it down. It is very well taken care of software and I think there's a lot of people in a virtuous relationship with it i.e.: probably a lot of people running it to get things done, doing good business, making money and satisfied enough that it sort of doesn't matter much what 'kids' looking for the hot new tech to fill CVs think about it. I think RoR is super solid in this regard.
Following on the Vim analogy, I think both Ruby and Rails have the 'power tool' quality/deph in that it keeps rewarding you with more power the more you get the handle of it, there's few things like TDD on RoR. When you're senior and you're not afraid to tweak things as you want it anymore, things get really interesting. For example:
- Microservices x monoliths: I've built a Service Object layer, all Services have an API of .new(:param, :param)(sugarized to initialize_with :param, :param) and .call, .call!, .queue. These service objects can be strung together, allowing for composition. call without '!' gives you an object you can say .success?, .result and react however you want. .call! will raise exceptions. .queue runs it async in Sidekiq. We have over 40 of them, in some cases we refactored out a piece of functionality(e.g.: google sheets integration) and just deleted a whole folder of them, just like that.
All of these 'actions' can be run from any context: MQTT message, API call, console, Sidekiq, Sidekiq-scheduled, tests. In ruby *anything* can be mocked anytime, have you thought about the power of this? I can make an expectation that an --instance of a class somewhere will receive a call--, it could be mine, it could be a class in a lib, it could be something in the framework.
- Sidekiq just works and is awesome. Free fault-tolerance, performant, scalable.
- Building custom piece of architecture, ruby scripting is very powerful: we had bots simulating the motorcycles running and talking with the backend way before we actually had a board and software able to do that. MQTT messages are relayed to Rails app through a custom long running service, it's a ruby script. Later on we've twisted it to test Firmware Updates Over the Air feature, basically, scripting the script itself. So we have a CI/CD job that allow us to stress test/spec test firmware. Right now I'm doing a middleware so I'll script Rack/Rails next, TDD is going smoothly.
- Maybe tweaking it further to make it more of an a Event Driven application.
I think ultimately Ruby developers end up being good developers because of the high power+low cognitive overhead style at the heart of the language.
Now for the cons:
- It is indeed becoming niche. Junior developers probably mostly not learning it. Are they really as productive as they could be on Rails though? I think NodeJs stuff are interesting, I wonder though how productive they actually are. Is the stuff they build really bug-free? Fully featured? Well tested? From my experience they are fast but will overlook obvious bugs in their code as if it was ok. I think the Ruby community had tons of good teachers who focused on elegant working code, RailsCasts, DestroyAllSoftware, etc. Also a lot of influential devs and ppl who learned from them & similar sources, a lot of them still participating or who done amazing contributions, like Aaron Patterson, Jose Valim, DHH.. I don't know how exactly we'll deal with this at the company, but our software is so flexible I think we wouldn't have much trouble breaking it up & integrating, at the same time too, though, our application code is so easy to work on I don't think it matters much if a new dev is not a rubyist.
In conclusion, I guess it depends where you want to go with your life, I myself have always thought of handling actual heavy duty shit with software, being in a core product team, not being a 'job market b*tch' etc. Even if I'm not writing Ruby one day because we have decided to switch to something other or that I want to work on a different project that is running X, I don't really care.
Rails was originally released in 2004. Since then, it has been used to build a wide range of different websites and applications. Some of the most well-known sites built using Rails are Github and Airbnb, which is why many people think of Rails when they think of web development. While it has lost some popularity in recent years, as other frameworks and languages have become more mainstream, Rails is still very much alive and kicking.
In fact, in 2018, Rails was the 7th most commonly used framework among all developers according to Stack Overflow's annual developer survey. This survey included over 100,000 responses from software developers representing over 150 countries. It showed that about 30 percent of those surveyed had used Rails "in their careers" or "currently use."
The main question you should ask yourself when considering whether or not to use Rails is whether or not you can use another tool that would be better suited for your project. If you're looking to build a website with a lot of dynamic functionality that needs to be delivered at lightning speed, then Rails could definitely be your best option.
If you’re face deep in the Ruby ecosystem then I’m sure it makes sense, but trying to build services alongside it is truly awful.
You want a scalable system that’s easy to write and will grow with you? Write basic Go services.
That makes no sense. It's very easy to build a REST API in Rails in which case you can connect to that API from services written in other languages. Conversely, you can easily call out to other services' APIs from Rails.
In fact, I'll go so far as to say building a few choice services in particularly performant (lower-level) languages alongside a main Rails monolith is the best organizational pattern for larger applications and enterprise deployments. You get all the benefits of Ruby & Rails for most happy paths, as well as the benefits of "This goes to 11!!!" performance for the critical paths which need that.
I've seen great ruby/rails code and I've seen abysmal ruby/rails code. A lot comes down to who wrote it and if they ever refactored the smelly parts.
After 20+ years, I often see that no one likes to refactor the smelly stuff until they're forced to, and we often end up working with a cool racketball of code covered in 2' of duct tape patches.
Go is the new hotness, as was Rails at one point, and in the near future it will be something else. There's a strong neophillic bent to most developers. It's a lot more fun to work in something that's new and evolving and solving crazy problems than something that is stable.
These are all tools in the tool kit. Use what lets you ship.
One year later it was a mess of network calls, no ORMs and nearly-raw queries because who needs an ORM, migrations run by SQL statements on bash scripts because who needs migrations. Validations were custom wrappers on some validation libraries and validation errors were of course not consistent across all of the microservices, not because of lack of agreement, but because new ideas and ways to "do it better" showed up all the time.
Some of these "services" needed translations (for emails, hooks, and some html responses) so a custom "very simple" translation system was invented.
It became an infinite mesh of proxy services on top of proxy services on top of proxy services on top of kubernetes.... and at the end of the day, guess what was paying the bills? guess what still had all the business logic and was the source of truth?
The Rails application.
if just 10% of the effort were put on improving the existing Rails application, all the Go microservices crazynes that was going on at this place would have been avoided.
Do you know why it went everything that way? Because management decided that if they blocked people from using Go then people would leave the company. I was one of the managers there, and pretty opposed to this as you can notice.
But I think this is a huge reality around here. People want to play with new shiny, without even thinking of the drawbacks or if they do have a concurrency or raw cpu performance in their application.
People want to make a CV in what they want to use in their next job. And Rails is not fashionable anymore so "the monolith is bad" and "Go microservices" are good. You're not google 99% of the time.
Thankfully I left all that madness and now I'm in a more sane (although "not so cool" technologically) place where we focus on shipping product and keeping things maintainable, robust and secure.
If you wrote a system in Go as a monolith, it would be hard to trim down, too. Architecture matters MUCH more than the implementation language.
What's so easy about Go? I don't get it. Honestly. What's so hard for you to do in Ruby? And who's to say that in 15 years those shiny Go services you're working on won't become shit after dozens of changing devs had their way with them? Turning a codebase into shit takes time.
When i hear "Rails monolith is a disaster" what it usually boils down to 8 out of 10 times is people putting their business logic inside models or controllers, when really it should live in its own set of classes, usually called services or service objects.
Here's a guide https://codeclimate.com/blog/7-ways-to-decompose-fat-activer...
I ask this genuinely as I am interested to see what pain point people have with Rails.
Yes! Behind every principle there's a promise. https://twitter.com/jessethanley/status/813904788702183425
Hear! Hear!
If you want to learn Ruby on Rails in 2022 please check https://gorails.com
But the question is probably around one's personal choices: is this the framework to invest my energy and time? Are there far better frameworks? Where is the market headed?
In the early days of Rails, and indeed any popular framework, the sense we get of an explosive growth. As a result of this there is an imbalance of jobs and developers and jobs seem easy, plentiful and well compensated.
This is really a question of the ratio of dev:positions. Most answers to this tend to focus on the positions component (take a look at stack, or upwork or indeed or whatever!). Perhaps someone on HN will suggest a metric or public gauge for the competition as well.
Edit: added slightly more context
I ask as I dont understand why people say drop Rails and learn Go. And I am looking to learn a new language along with Ruby and Elixir.
Why is Go compared with Rails and not with Ruby?
If Go does not include a default support for web frameworks then what web framework would you suggest for doing a web SaaS like management of posting on social media?
I dont want to create this but i use it as an example as it has image uploads, date/time, jobs, … things I can do easily in Rails and have already battle tested solutions available.
According to Hired's State of Software engineers 2022, Rails is the 2nd most in demand skill.
- There's lots of RoR jobs.
- They keep improving it.
- What RoR taught me made me a better architect in every other stack.
I really have to second this point. I'm not 100% sure if DHH was the one who coined the phrase, "Convention over Configuration", but he's the first popular technical communicator who I remember emphasizing it in a clear way. Simply trying to be consistent about naming certain things like models or database tables (singular vs. plural) is a big win for any project. Nobody gets everything right, but RoR is filled with lots of little smart choices like that that are worth considering for your own projects.
It’s a great time to start using Ruby for web projects.
I think Rails is one of the most productive and capable frameworks for building and evolving CRUD applications, which is the reason it still remains my recommendation for new startups.
I prefer the “explicit is better than implicit” norm in the Python community over the “powerful yet mystifying magic” I find in Rails. (This is personal preference.)
I also appreciate Python source code being easier to manipulate with tools than Ruby, since Ruby did not have a formal grammar the last time I checked. Any tools that did exist appeared to usually include the yacc/bison file from MRI (the main Ruby implementation) as the best approximation of a language definition.
Django might avoid this to some extent but Django rest framework has you covered.
https://octoverse.github.com/#top-languages-over-the-years
It also has a funky syntax, while not a big deal, doesn't do it any favors in a C --> Javascript world. Django, golang, etc. are free. I don't recommend starting new projects in ruby, but as always YMMV.
Not that those are reason enough to use it. But I wouldn't call it the wrong decision either.
If you were to follow in their footsteps, you'd also be picking the top popularity web framework for your time, which as of now is things like Next.js and Django.
Big recent-era startups:
OpenSea (Django / Next.js)
Notion (Node.js)
ScaleAI (Python, Node.js, Next.js)
Substack (Node.js)
Rippling (Django / Next.js)
So I'd recommend to look for job ads on local platforms and check if companies are looking for rails devs.
Though I would not let that dictate my choice of tools.
However if you want the biggest pool of "talent" and potentially the cheapest "talent" then going with the most popular is probably a good idea
Doesn't mean I'd advocate for the most obscure tech either, but it's all about trade-offs and your situation.
Rails has been around long enough that there's surely no shortage of junior to very very senior engineers that will write code for you from wherever they happen to live.
https://news.ycombinator.com/item?id=5483752
Interesting to compare answers to today.
Note that, just like any other tool it has pros and cons, one should analyze the system requirements and use whatever makes sense. I would however, dare say that it is a great fit for majority of businesses.
Honestly, majority of frameworks out there today will get you 90% of the way: Rails, Laravel, Phoenix and Django just to name a few.
As I get older, I tend to prefer boring tech myself..
Last year during the pandemic I started to work on a side project, I picked Laravel because I heard a lot of good things, and having used Django in the past I know the value these frameworks provide. I'm building it using the "tall stack" [1] and it is just wonderful. The best part is not having to take 1000 decisions every second about what library or how to do this, or how to do that. Everything already has a place, and I can focus the little time I have to actually building what I want to build.
I enjoyed Ruby as a language quite a bit. Having experienced some of Rails' scaling issues, I doubt I'd personally pick it for my next startup. I know time to market is vastly more important than scale, but it's also not hard to pick a different tech that DOES scale easier.
So, yes, there will be plenty of Rails projects to work on for the foreseeable future. The only concern I'd have is if you're being asked to work on a very old code base. That can get really hairy, really quickly. But that's the case with any language/stack.
What part of Rails doesn't scale well? As I see it any mediocre devops can scale just about anything with some basic Kubernetes know-how, doesn't matter of it's Ruby or Java.
My main point here is, that while one can work hard to try and tune Rails (Shopify's done it, Stripe's done it) - and I would argue that it's more of an effort than some DevOps personnel updating a pod count - it's fairly easy to start with something that is already very performant. SpringBoot is an opinionated framework for Java that has very good raw performance. I'm simply advocating that it doesn't hurt to start with something that's already pretty good. That's not premature optimization, it's just making wise decisions from the start.
Judging by the responses here, Rails is no longer fashionable. I find it to be quite boring and predictable, which is how I like my frameworks to be
Just stay the hell away from React and it's great
But Rails is a different story. For jumpstarting a greenfield API or CRUD app, there is nothing quite as good as Rails. Django and Symfony and other frameworks have tried to imitate Rails, but Rails is still way out in front, with better tools, and the marriage of Rails tools with Ruby's advanced meta-programming is something difficult to replicate elsewhere.
If your company needs a custom CRM or CMS, Rails remains the best starting place.
Its a good point, there are absolutely much more simpler frameworks out there, which are good for your own side projects, your own large projects, and what fun and exciting production companies are using.
If someone feels like re-implementing all the wonderful conveniences of rails in Go, more power to them. However, that's a MASSIVE amount of work that you'll be doing _instead_ of actually making the webapp.
Go is great, but it's built in HTTP support isn't even _remotely_ equivalent to the many years of accreted utility in Rails.
To put it another way, it's a false equivalence. No-one should EVER say "learn go" instead of rails. Now, if they said "lean Buffalo" ( https://gobuffalo.io/ a Railsish framework in go) instead of Rails you could have a very reasonable discussion.
I am not familiar with ruby but my understanding is you don't get these out of the box you will need framework like rails for it. How easy/difficult it is to upgrade rails? for golang if you are sticking to stdlib it is trivial. If it is easy to upgrade/maintain/operate rails and you are familiar with it than don't switch.
Rails is also a fairly complete package, and you can get very far without additional libraries. Once you do start to bring in libraries it can get painful, particularly if you stray off the path of very popular libraries, but it's nowhere near the Javascript ecosystem.
You're right that Ruby itself won't get you far in terms of a webserver, but the vast majority of web development is done with Rails so in that context it's analogous to thinking of Rails as almost part of stdlib when thinking about web development specifically.
I like Go, but this is a terrible comparison and I’ve not seen a single comment make a valid point about Ruby’s alleged demise.
Agreed. I don't think Go is that great for normal CRUD web development at all, maybe its interesting for super high concurrency / low level stuff.
I have found that people from the world of Java and similar c-style syntaxes, and especially strongly typed languages, have a sort of allergic reaction to Ruby. The reverse is also often true.
This is a matter of personal preference that actually tells nothing about what any of those languages might be good for.
Ruby/rails is less popular than it once was but it's still pretty popular. It's worth considering if you are open to the style of programming it uses. But if you love the c-style syntax, yes, you'll have problems getting used to Ruby and should try something else.
I had a couple die hard rails members at my last company who claimed nothing was better. We made them write Go for a year and now they are die hard Go fans.
If I were writing a web app I would start with Go. It’s a great language that’s easy to learn and fast to write, with all the security of static compilation. It scales exceptionally well with large teams
Go and RoR couldn't be more dissimilar from each other. One is a relatively slow language with one of the most full-featured and robust frameworks available today, and one is a very fast language with relatively minimal tools for building web applications. The types of projects they're suitable for are completely different
If the above is correct, it presents an interesting question to junior engineers: is it worth it to learn Ruby on Rails as a junior engineer? While there are advantages to learning Rails (it's heavily opinionated, what you learn maps very well to what professional projects look like), there is more job supply in the "python + LeetCode" path (how that relates to competition - who knows).
All my peers who started their careers with Rails that know it like the back of their hands have zero desire to ever work with it again professionally. They're all exceptional engineers who had no problems picking up/migrating to Scala/Rust without productivity loss.
On the other side, I see all the upcoming engineers that missed the initial Rails popularity wave. To them, Rails is often times much more frustrating than TS/Python offerings. There's very little freely available quality onboarding materials, getting the environment set up is incredibly frustrating with how fickle bundler has become, and deployments are still complicated.
My take is Rails is good for those who already know Rails, since the stability of it lets seasoned Rails developers carry forward all their experience. But for someone without that history, TS/Python frameworks offer a much faster/smoother onboarding process, especially with the massive familiarity advantage devs already have with Python/JS from schooling/web.
If you're going to go out of the way to learn a new language, why would you learn one that occupies the same space as one you already know?
Contracted Rails devs are probably working on an enterprise product that is already mature and making money.
At the bottom of the page we get:
Methodology
This report is based on proprietary data gathered and analyzed by Hired’s data science teams. For the purpose of this report, Hired examined software engineering candidate interview requests and salary data from January 2020 through December 2021 inclusive. The data included reflects over 366,000 interactions between companies and software engineering candidates during this time period.
In addition to our proprietary data, we collected survey responses from more than 2,000 software engineers on the Hired marketplace to inform our understanding of software engineers’ working preferences.
1. Ruby is a very flexible language, and that has its ups and downs. While it makes it a very pleasurable easily modifiable syntax, it also leaves a lot of room for bad patterns. Ruby won't judge someone for taking an ill-advised approach to a problem, so it's easy for newcomers or novices to lay foundations that cause trouble later on.
2. Ruby is very prominent in startups, which are the companies most interested in immediate results. This often leads to favoring short-term advantages such as getting a feature out today to secure a deal rather than long-term advantages such as taking the time to keep a maintainable code base. Some startups with strict budgets will also hire people with less experience early on, leading this to pair with point 1 more often than we'd like.
That said, I'm a Ruby dev and have no interest in working in any other language (other than JS on the frontend). It's a beautiful tool to those who treat it well and I'll happily use it for just about any project.
a) they don't like Ruby for whatever reason, b) they probably only deal in backend or only deal in frontend, and so don't understand the value of the bundled dev experience rails delivers, and therefore c) because of a + b they find the moderate learning curve to be extra painful, so they lash out.
at the end of the day it's all just code. why would it be harder to integrate a service in Rails than in Go? of course it isn't.
Also, not that it really matters but I just happen to be a counterpoint to both examples. I'm at home surrounded by hardware for my current work and also wrote / led a remote team instrumental in passing a federal banking audit atop infrastructure as code.
I'm on team sure there's use-cases for local hiring but they're so hard in the minority these days + it's a rails thread that I felt like my stance in my prior comment probably did hold in all cases where that might be the right tool for the job. Like all things though, it depends. :)
This is largely the problem, Go enforces good dev behavior, Ruby leaves it up to the dev
Ruby/Rails' culture is a huge contributor to why Rails monoliths are so much more difficult to maintain compared to other dynamic languages. Things in Rubyland just love to be global and manipulate things globally and go out of their way to make that behavior hidden.
I question that assertion. I have plenty of anecdotes which are the exact opposite: a Rails monolith is much easier to maintain compared to similar approaches in other languages.
"manipulate things globally"
Not sure what you mean by that to be quite honest. If you mean monkey-patching, that's generally been frowned upon except at the framework-level in the Ruby community for quite a while now.
The heyday of "SPA is the right approach for everything" feels like it peaked at least a few years ago.
All of this disregards the speed advantage of go. There is no comparison between the two.
- Migrations are well-implemented, and I've definitely wasted many cycles at other startups dealing with hand-rolled migration tools that are nowhere near Rails.
- The ORM (ActiveRecord), while very opinionated, is pretty full featured and suitable for 95% of use cases (and makes it fairly easy to drop out of it if needed)
- There's a host of security features that are taken care of you by Rails out of the box, including CSRF protection, session security and password hashing with a sane strategy and good algorithms (I'm sure there's others I'm missing)
- Websocket functionality comes out of the box with newer versions of Rails
- Asset handling, including minifying and digesting assets is included.
- Directory structure is set up for you (seems minor, but it's a huge productivity boost when joining a new team knowing where everything should be).
- A standard approach to background queueing, built in a way that it's extensible for different queue / worker backends (i.e. your jobs are cross-compatible with different background libraries and backend servers - I can come onto a Rails job that stores background jobs in Postgres, SQS, Redis, or anything else and how the jobs work is consistent).
Regarding speed, I'm certainly not going to argue that Ruby is faster than Go, but at least for the problems that I tend to work on, raw language execution performance is never really the bottleneck. It's cheap to throw money at, and 99% of the time when I look at poorly performing actions the culprit is the database or an external service.
CSP, csurf tokens, param parsing with array and hash map params, strong params, automatic response codes (201 for created for example), etags, … just from the top of my head. I’m sure I could find dozens more if I start looking.
All of those are possible in every stack of course but rails already gave you all of that from the time you typed “rails new”
That's what I'm saying - you don't need to "work hard" to tune Rails in 99% of cases - your bottlenecks (if any) will probably be in the database layer. k8s simply solves it, so unless your argument is "infrastructure costs" or something I don't agree with your case. Shopify has such tremendous scale I think its ridiculous to use it as an example for the average company.
> When operating a highly dynamic site that services millions of requests a day, scaling k8s pods horizontally ceases to be a "win".
Why does it cease to be a win? Everyone is doing it no matter what stack they are on. So with Rails you might have a few more pods - for any startups that's going to succeed the cost is simply negligible.
So, if I could tell you, that for your next startup, you could start with something that is easier and cheaper to scale (I find "a few more pods" very disingenuous as many benchmarks say otherwise), why would you choose something that requires a lot more resources? Because Rails is neat? I just don't see the allure at that point. It's why we're seeing companies like Podium, Divvy, PagerDuty move away from it. It's great to get a proof of concept out the door. So many stories are out there of folks that are moving away from it for their "next step".
https://octoverse.github.com/#top-languages-over-the-years
However, that doesn't mean it is dead, or you can't still do great things with it. Most platforms continue fine on into their twilight years :rofl:. Lotsa folks here getting shit done with perl and lazarus ide.
This entire exchange would not have happened if you had simply said, Ruby is less popular than it used to be.
“Past its prime” is a derogatory expression that is invalid in this use case.
To go to your bosses and tell them you have to migrate from Ruby to Go to improve productivity is a blatant lie.
But managers/directors, etc aren't idiots. They swallow it and they accept it even if they know the trade offs, because what's not told here is that if management says "No, that's madness" then people quit, and that's worse. So there we go with our super performant microservices for our 10 reqs/s app.
Go has better safeguards to prevent bad dev behavior
There shouldn't be any more tests, you're testing an API either way
“Those who cannot remember the past are condemned to repeat it.” – George Santayana, The Life of Reason, 1905.
> if just 10% of the effort were put on improving the existing Rails application, all the Go microservices crazynes that was going on at this place would have been avoided.
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Gosh I'm old.
Maybe you're doing it wrong?
We're talking about documenting an architecture, how pieces work together, what tools are available, where to put things, etc. Check the documentation of any major web framework. That's what we're talking about.