Your HN handle been a pretty vocal ambassador of Pivotal/VMware Tanzu on a lot of threads that the employee-employer association has become permanent in my lizard brain, which is why I had to do a double-take when I read your comment [plus the fact that I'm up a bit late ...]
It only just dawned on me that you might have switched your employer allegiance to Shopify :)
I was vocally at Pivotal->VMware for a total of 7 years, so a reasonable enough association to form. I've been at Shopify for a little over a year now.
> How did the conversation about doing this start? Who made the case and sold it internally?
I made the initial pitch that we should support Ruby Central, but it took off very quickly once senior leadership saw the pitch. Once we got the go-ahead it was mostly worked out by Mike Dalessio (aka flavorjones) and Rafael França for Shopify and Evan Phoenix for Ruby Central.
Being a dev myself and knowing how the sausage is made and how FOSS is the casing that holds it all together, this investment makes perfect sense. But I can also see how investment types would complain, it doesn't exactly look like an investment in the books.
>Paying for that software is one way or another is a normal business expense.
It should be, but conventional bookkeeping hasn't really kept up with the economic realities of this industry. Same reason why they fail to account tech debt as a liability, refactoring as amortization and debugging as interest payments.
Shopify is the Canadian meme stock. When I worked there everyone I met knew about them, not because of the product, but because the news loved to talk about Canada's one domestic tech success in the last 10 years. During the pandemic they briefly became Canada's most valuable company, and then lost all their gains for the past 2 years, then did a stock split because it was trendy with retail investors.
They have a ton of terrific engineers but the nouveau riche people from the IPO are largely insufferable, and the amount of reverence for tobi inside and outside of the company is just unhinged.
This amount of money is well within what you'd expect to pay for various proprietary software packages. You can probably add up all unused-but-not-deleted VMs, S3 buckets, and their payroll/vacation tracking software and you're at 1 million dollars.
I've started responding to "hey, do you want to talk to sales?" messages with "sure", just to see what stuff costs in the real world. Everything is 5 or 6 figures, even static website hosting. I wouldn't pay $20,000 a month to host a static website, but someone must be, because that's what people are asking for on these calls. I can see a world where you say yes to even a few of these vendors, and the cost of securing the entire Ruby ecosystem looks like a rounding error in comparison.
At the end of the day, I doubt the investors care. If they want to cut costs, there are much better ways.
(I helped make the case internally at Shopify.) The key points we emphasized are in the Ruby Shield announcement, but to summarize:
- Attacks on supply chains are way up
- Use of open-source software is way up
- Shopify is already contributing engineering time to bundler and rubygems.org
- And there is additional shovel-ready work that Ruby Central could execute on with a financial contribution.
Proactive security work now reduces the chances of a successful supply chain attack and the costs associated with recovery, investigation, and mitigation in addition to reputational damage.
There are secondary benefits, too: when we're confident in the supply chain, we can more confidently update our dependencies in a timely fashion, meaning our developers have access to the newest library features; and we're able to patch known vulnerabilities faster. We invest a lot in feedback loops internally, and this is just another facet of that build/measure/learn cycle.
I can give a limited answer based on my own day-to-day work. I work in Ruby Dependency Security, which is the team who are most involved in helping out with rubygems.org and RubyGems work. Our biggest effort lately has been about rolling out MFA requirements for owners of top-most-downloaded gems. What I'd like to do afterwards is focus on gem signing using sigstore, which would make it a "one click" experience for authors. We did some work on it earlier this year[0] but chose to focus on MFA as our first big push. We also aim to devote a substantial fraction of our time to chopping wood and carrying water: looking at honeybadger exception reports, etc.
In terms of the long run there's a whole bunch that can be done to continuously harden every aspect of the Ruby supply chain. One thing we've been involved in founding is the OpenSSF Securing Software Repos working group[1], which has meant that RubyGems maintainers are now talking directly with folks from PyPI, npm, Maven Central, Cargo and others. We all face shared threats (eg, dependency confusion, resurrection attacks etc), so getting together to work collectively and share ideas has been super awesome.
They have different impacts. That million allows shopify to get features it wants and aligns the project to it's goals. That $2.44 comes without those strings.
You can afford more developers with a million but you end up building something shopify supports which pulls existing resources away from current priorities.
There is a section in the post exactly about that. Let me quote here:
> What influence does this partnership give Shopify over Ruby Central?
> This was an important consideration in Ruby Central moving forward the partnership. After discussion with Shopify and amongst the Ruby Central directors, the agreement was formulated as a donation without strings. Both parties have made it clear that usage of the donation is at the discretion of Ruby Central. As a good steward of the Ruby community, Ruby Central plans to disclose how the funds were used both for full transparency on the partnership as well as to highlight the work that was done.
You do realize that market cap is not real money, right? That's like saying that an average American who earns 30K USD/year over 33 years will earn 1M USD and thus they should be considered a millionaire.
Shopify's revenue last year was $4.6m last year, and that's before expenses, so I'd say it's quite a meaningful contribution. But regardless, a $1m donated to OSS is still $1m.
If you want to talk crap about a company that gives 0.002% of their "market cap" to FOSS development, at least be ready to show that you are doing better than that. Otherwise, your indignation sounds like nothing but a mere cheap attempt at virtue signalling, and FOSS devs can not use that to pay their bills.
What amazes me is they are giving money with no strings attached, and of course there will be some entitled prick who will try to find fault at that. I wish more companies did "PR stunts" like these...
Your comparison is still flawed. Market cap is the value of the company in the eyes of its investors, which in theory factors in current assets, current profits, and future expectation of profits. You compared that to the net worth of a single individual, which accounts for nothing but current assets.
That said, you weren't all that far off. Based on Shopify's revenue of $4.6 billion and an average household income of $67k, this is equivalent to a donation of $14.57.
I still argue that the presence of this kind of negativity in every thread about corporate donations is toxic. Corporations don't donate to FOSS nearly as often as they should, and there's no harm in giving them some credit on the rare occasions when it happens.
/u/ufuk has already pointed how this comparison is flawed, but even if it were not - now do the same comparison of how much other companies donate to OSS projects.
More big companies that use open source should do this or something similar. The dividends to security, developer productivity, etc are probably extremely high, particularly for a company with hundreds or thousands of engineers already. It's such an efficient use of money to give it to the people who already have the expertise to do the work.
It seems like my peers at other such companies are being modest, so I will speak up on their behalf.
Microsoft and Google have jointly funded the OpenSSF Alpha-Omega project to the tune of $5M. In turn Alpha-Omega has granted $300k for Node.js security[0] and $400k each to the Python Software Foundation and the Eclipse Foundation for security work[1]. Google are also forming an "Open Source Maintenance Crew"[2], a group of engineers dedicated solely to helping OSS projects improve security. Meanwhile Google, Microsoft, VMware, Intel, Ericsson and Amazon have contributed $30M ($10M from Amazon alone![5]) to the OpenSSF[3] towards a $150M plan to address OSS ecosystem security more broadly[4]. This will begin to bear substantial fruit over the next few years.
For Shopify, Ruby Central is close to our history and our heart; it makes both logical and moral sense for us to give back generously. But that by no means diminishes that many companies are starting to step up in a big way across the board. It is an exciting and promising time for open source security.
This is such great news for ruby. Here’s hoping with these resources rubygems and bundler can add improved support for signature verification. Rubygems supports gem signing but without a good scheme for trust, key rotation, etc it is not particularly usable. Sprucing this aspect of the ecosystem up would go a long way towards allowing ruby to maintain its historical role at the vanguard of language specific package management.
Another thing I would love to see is the ability to incorporate a signed attestation that a gem was built from a given signed commit. A common dirty trick by supply-chain blackhats is to publish a gem which contains code other than that of the corresponding tag in source control. Given that rubygems has no means to browse package contents other than downloading and extracting the tarballs for manual inspection this means that people typically reference changelog or diff links on source control hosts, despite the fact that those diffs will only be accurate for gems published by good-faith actors following platform norms.
There are a number of ways to fix this and I sure hope one of them gets implemented.
brasic is also welcome to participate in the OpenSSF Securing Software Repos working group, where we collectively discuss these kinds of efforts across multiple ecosystems. The best place to get started is the OpenSSF "Get Involved" page: https://openssf.org/getinvolved/
yet ruby on rails and ruby is in decline. its getting harder to hire younger developers in this field, many don't even know what Ruby is or cares for it.
Seems like its another PHP type of situation, one which companies will move away from in the coming years. Not the fault of the ecosystem or language but simply because it gets expensive and the talent pool shrinks, not a good driver for business decision makers to back.
edit: i really dont understand the downvotes here I am simply mentioning the changing requirements in many companies that used to be on RoR that cannot find enough senior developers with the budget they are used to, to the point that they are moving to a new platform. theres just not enough RoR jobs and not enough RoR senior devs in the marketplace today and it will be far more bleak in the near future. there's not a lot of new minds coming into RoR and thats the talent pool you are gonna be stuck with if you keep the trajectory. Ask any new graduate and what tech stack language they are using, I'm willing to bet it isn't Ruby or RoR. Their attention is in Javascript or Python or more niche languages like Rust/Elixir/Clojure
attention is in decline. developers are paying more attention to other languages that yields greater number of employment options.
it should be that RoR devs get increasing rates as they become rarer but its not, demand is also dwindling as enterprises feel uneasy about banking the future on a smaller talent pool.
Why is Rails in decline? I see a lot of people say they're developing instead with rust, or python, or javascript.
But Rust has little to do with what Ruby/Rails is used for, and Python is mostly used in other fields also (it's not like Django is taking over the world). Every time I look at the various JS frameworks it seems like just a huge lift to get something going versus Rails, for typical SME type business problems. Most problems don't really seem to require SPA.
Things like Elixir/Phoenix look very interesting and promising, but their ecosystem is (for now) much smaller. And just the size of the Elixir community right now suggests that it's not like all the RoR developers went to Elixir.
So what is the thing that is so much more attractive than Rails, to solve your everyday business logic issues for small to medium scale problems?
Does all engineers and companies think they are solving Google-scale problems or something?
Your observation is correct but its that companies can't hire like they used to when RoR was at its peak. Like I said, unless you have growing revenues to continue to retain senior talent, its going to be tough in the future as there is no continued queue of talent making it through the pipelines. Maybe one day RoR will become the Java EE and will rely on a very limited pool of workers, and that is the situation that many are trying to correct. You absolutely need to pay attention to what the new generation of developers are learning in order to suppress wages, failure to do so without consistent revenue growth you introduce issues that will seep into your business, especially if you rely on being online.
The language: Tech companies are becoming more aware of the dangers posed by maintaining and updating large codebases written in an untyped language. I know there's a lot of work still being done in Rubyland on this problem but it feels like the horse left the barn long ago. A lot of Rubyists seem aesthetically opposed to types, including influential language stewards. Sorbet is arguably the Typescript of Rubyland, but it doesn't feel like it's taking off to nearly the same degree. (My theory is that the expressiveness required to support a language as flexible as Ruby results in poor developer ergonomics in terms of the necessary type annotations.)
The ecosystem: Rails is still king, for better and for worse. Back when Rails was in its prime, there weren't as many CRUD web use cases that required marshalling lots of async i/o. Now it's a pretty ubiquitous requirement. You need to fetch data from upstream A and upstream B, then combine them to send back to the client. With Rails, the de facto way to do this is to make these requests serially, which isn't very scalable. Hell, even a single call to a slow remote host can easily end up saturating all of your web workers. Like the types issue, there's a lot of work happening trying to make it easier to perform non-blocking i/o in Ruby/Rails, but it seems like too little too late.
My tiny company is torn between throwing out our ruby code and trying to hire more ruby developers. Our senior ruby guy is leaving, and the one senior candidate we had accepted, then later rejected, our offer. Of the other interviews we have had, candidates were asking for too much (i.e. over $200k base salary) and often barely qualified as a senior, or were simply too inexperienced to replace the person who was leaving.
I'm about one more round of interviews from throwing in the towel and doing a hulkamania hackathon in a new language. The existing code really isn't great either (deprecated gems, lots of accidental complexity, etc) so it is almost tempting to think it would work.
Would it be possible to wall off the legacy Ruby code behind a stable interface and switch to writing new features in a different language? Then instead of hulkmania you could perhaps whittle away at the legacy stuff incrementally.
That would require having competing ORMs (rails plus whatever library or ad-hoc we roll in the new code) working against the same database.
Unfortunately, it's a pretty complex system, and the changes we have slated don't really leave room for updating one endpoint at a time. Even if it were simpler, I don't recall anyone ever contemplating having two ORMs running against the same database without a shudder of horror.
It's a very high salary for the geographic market we're in, and we are far too small a company to compete directly with FAANGs.
Even having worked for west coast companies, I've never gotten $200k base salary- adjusted for my region, most pay in the $150-175 range, and I've got quite a few years under my belt.
If that's the case, then ruby developers are severely overpaid for the quality and quantity of code they produce.
Of course, I don't believe that's the case, but rather that there is a shortage based on it being a relatively unpopular technology compared to java / .net / node / etc.
Yeah, it's been hard to find Ruby/Rails devs for... as long as I can remember. 2015 at least. Not sure if it's become harder.
What about hiring experienced devs and simply giving them an intro Ruby + Rails course? (which could be as simple as say, giving them 2-3 weeks to go through some self-directed learning)
I think companies often do this badly: they hire non-Ruby devs and expect them to learn by osmosis, which usually results devs simply writing a bunch of bad code - for example, Rails code that fights against core Rails assumptions and looks like Java/PHP/etc.
However, I also think it's pretty easy to get it right. If the company and developer have a good attitude about getting the dev immersed in Ruby/Rails a bit before turning them loose on the main codebase. I'm implementing a curriculum like that now in my current role.
Well, now that I read my post, "curriculum" probably makes it sound more grand than it is. With the range of Ruby learning options out there we're definitely not planning on reinventing any wheels.
Part 1 - We've gone through "The Well-Grounded Rubyist" and listed most chapters as "learn" and some as "skim". The "skim" chapters are things that are not generally useful for Rails development e.g. explicit threading, file I/O, etc. The idea is that the student should simply know those things are there in case they're needed later.
Part 2 - Same thing with the Rails guide from "Learn Enough To Be Dangerous" from Michael Hartl. We like this option because there's the book and then there are screencasts. So students can pick one or the other to suit their learning style.
Part 3 - Small standalone project of the student's choosing, we have a few suggestions if they don't have any. Something they can finish in a few days.
It is mildly "innovative" in the sense that, for whatever reason, most companies don't seem to do this. Companies I've worked at in the past have had generous onboarding periods, and have given devs lists of learning resources, but generally expect the devs to learn as they go. Which is fundamentally sort of broken, because "learning as they go" typically involves "learning by osmosis from an existing fragile production app that has a lot of tech debt."
Eh, yes I'm aware. You're right, I should have said dynamically typed. I was just thinking faster than I was writing. Kind of an annoying nitpick but I guess it's on brand for HN.
edit: or writing faster than I was thinking? Potato potato.
>The language: Tech companies are becoming more aware of the dangers posed by maintaining and updating large codebases written in an untyped language.
This (insinuation that dynamic typing is inherently worse to maintain) actually isn't true. There's no evidence proving this. Its one of those things that slowly became common sense and goes unquestioned.
There was a Github repo with scientific publications demonstrating the above. I think it made it to HN a while ago. Wish I could find it now.
Same thing happening to Java. Lack of a strong enough pull to get people into it.
If you are learning something new or just graduating, you're way more likely to learn rust/python/javascript as those languages offer something unique (low level speed/machine learning/browser stuff).
Rails used to be miles ahead of the competition, but the competition has largely caught up. Rails is still probably the best choice(in my opinion at least) for building a feature-rich webapp backend quickly unless you've got some crazy unrealistic performance requirements(spoiler: most engineers love to pretend they do, but they probably don't)
But these days there are frameworks everywhere so you can write your backend in whatever you're most comfortable with.
I bet you that you won't. Hope I'm wrong.
They just split their stock and it's continuing to tank. Had a friend get his interview canceled today because they removed the position, said it was for financial reasons.
Gotta love employees leaking internal information. Not that any software development projects were ever late... Haven't heard about laying off 50 people anywhere else but compared to hiring 2000+ last year it seems not unheard of.
Other companies split their stock too.
I think there's no denial that we're in a different economic situation than we were a year or so ago - it's all about how you deal with it
Kudos to Shopify! that's exemplary of what I think businesses that leveraged on Open-source should mimic. It's a gesture of gratitude and being appreciative. In addition, it keeps the lights on and motivates the community.
101 comments
[ 17.0 ms ] story [ 2628 ms ] threadIt only just dawned on me that you might have switched your employer allegiance to Shopify :)
Unless there's more to the story I don't think it's fair to assign guilt by association because someone else did nefarious things in Trudeau's name.
I made the initial pitch that we should support Ruby Central, but it took off very quickly once senior leadership saw the pitch. Once we got the go-ahead it was mostly worked out by Mike Dalessio (aka flavorjones) and Rafael França for Shopify and Evan Phoenix for Ruby Central.
Being a dev myself and knowing how the sausage is made and how FOSS is the casing that holds it all together, this investment makes perfect sense. But I can also see how investment types would complain, it doesn't exactly look like an investment in the books.
It should be, but conventional bookkeeping hasn't really kept up with the economic realities of this industry. Same reason why they fail to account tech debt as a liability, refactoring as amortization and debugging as interest payments.
They have a ton of terrific engineers but the nouveau riche people from the IPO are largely insufferable, and the amount of reverence for tobi inside and outside of the company is just unhinged.
I've started responding to "hey, do you want to talk to sales?" messages with "sure", just to see what stuff costs in the real world. Everything is 5 or 6 figures, even static website hosting. I wouldn't pay $20,000 a month to host a static website, but someone must be, because that's what people are asking for on these calls. I can see a world where you say yes to even a few of these vendors, and the cost of securing the entire Ruby ecosystem looks like a rounding error in comparison.
At the end of the day, I doubt the investors care. If they want to cut costs, there are much better ways.
- Attacks on supply chains are way up
- Use of open-source software is way up
- Shopify is already contributing engineering time to bundler and rubygems.org
- And there is additional shovel-ready work that Ruby Central could execute on with a financial contribution.
Proactive security work now reduces the chances of a successful supply chain attack and the costs associated with recovery, investigation, and mitigation in addition to reputational damage.
There are secondary benefits, too: when we're confident in the supply chain, we can more confidently update our dependencies in a timely fashion, meaning our developers have access to the newest library features; and we're able to patch known vulnerabilities faster. We invest a lot in feedback loops internally, and this is just another facet of that build/measure/learn cycle.
In terms of the long run there's a whole bunch that can be done to continuously harden every aspect of the Ruby supply chain. One thing we've been involved in founding is the OpenSSF Securing Software Repos working group[1], which has meant that RubyGems maintainers are now talking directly with folks from PyPI, npm, Maven Central, Cargo and others. We all face shared threats (eg, dependency confusion, resurrection attacks etc), so getting together to work collectively and share ideas has been super awesome.
[0] https://github.com/rubygems/rfcs/pull/37
[1] https://github.com/ossf/wg-securing-software-repos
The average net worth of an American is 122k[0]. So this is like the average American donating $2.44 to a cause.
[0] https://www.fool.com/research/average-net-worth-americans
They have different impacts. That million allows shopify to get features it wants and aligns the project to it's goals. That $2.44 comes without those strings.
You can afford more developers with a million but you end up building something shopify supports which pulls existing resources away from current priorities.
It can boost or even kill a project.
Did you hear about the $2.44 I gave? No you didn't.. there was no press release or hn article.
> What influence does this partnership give Shopify over Ruby Central? > This was an important consideration in Ruby Central moving forward the partnership. After discussion with Shopify and amongst the Ruby Central directors, the agreement was formulated as a donation without strings. Both parties have made it clear that usage of the donation is at the discretion of Ruby Central. As a good steward of the Ruby community, Ruby Central plans to disclose how the funds were used both for full transparency on the partnership as well as to highlight the work that was done.
Most of an individuals networth is likely tied up in their primary residence and highly illiquid.
If you want, you can repeat my math comparing personal income to corporate income. The difference you will find out is not substantial.
What amazes me is they are giving money with no strings attached, and of course there will be some entitled prick who will try to find fault at that. I wish more companies did "PR stunts" like these...
That said, you weren't all that far off. Based on Shopify's revenue of $4.6 billion and an average household income of $67k, this is equivalent to a donation of $14.57.
I still argue that the presence of this kind of negativity in every thread about corporate donations is toxic. Corporations don't donate to FOSS nearly as often as they should, and there's no harm in giving them some credit on the rare occasions when it happens.
You’re making this sound like a bad thing. It’s a kind gesture nonetheless.
Microsoft and Google have jointly funded the OpenSSF Alpha-Omega project to the tune of $5M. In turn Alpha-Omega has granted $300k for Node.js security[0] and $400k each to the Python Software Foundation and the Eclipse Foundation for security work[1]. Google are also forming an "Open Source Maintenance Crew"[2], a group of engineers dedicated solely to helping OSS projects improve security. Meanwhile Google, Microsoft, VMware, Intel, Ericsson and Amazon have contributed $30M ($10M from Amazon alone![5]) to the OpenSSF[3] towards a $150M plan to address OSS ecosystem security more broadly[4]. This will begin to bear substantial fruit over the next few years.
For Shopify, Ruby Central is close to our history and our heart; it makes both logical and moral sense for us to give back generously. But that by no means diminishes that many companies are starting to step up in a big way across the board. It is an exciting and promising time for open source security.
[0] https://openssf.org/blog/2022/04/18/openssf-selects-node-js-...
[1] https://openssf.org/blog/2022/06/20/openssf-funds-python-and...
[2] https://blog.google/technology/safety-security/shared-succes...
[3] https://openssf.org/press-release/2022/05/12/the-linux-found...
[4] https://openssf.org/oss-security-mobilization-plan/
[5] https://aws.amazon.com/blogs/opensource/aws-investing-an-add...
Open Source software is essential for progress, but can be scary to rely on. Efforts to harden it should be celebrated.
Another thing I would love to see is the ability to incorporate a signed attestation that a gem was built from a given signed commit. A common dirty trick by supply-chain blackhats is to publish a gem which contains code other than that of the corresponding tag in source control. Given that rubygems has no means to browse package contents other than downloading and extracting the tarballs for manual inspection this means that people typically reference changelog or diff links on source control hosts, despite the fact that those diffs will only be accurate for gems published by good-faith actors following platform norms.
There are a number of ways to fix this and I sure hope one of them gets implemented.
https://reproducible-builds.org/
Part of that is that each builder signs statements about what inputs they used and build results they got and then you trust the ones that agree.
Seems like its another PHP type of situation, one which companies will move away from in the coming years. Not the fault of the ecosystem or language but simply because it gets expensive and the talent pool shrinks, not a good driver for business decision makers to back.
edit: i really dont understand the downvotes here I am simply mentioning the changing requirements in many companies that used to be on RoR that cannot find enough senior developers with the budget they are used to, to the point that they are moving to a new platform. theres just not enough RoR jobs and not enough RoR senior devs in the marketplace today and it will be far more bleak in the near future. there's not a lot of new minds coming into RoR and thats the talent pool you are gonna be stuck with if you keep the trajectory. Ask any new graduate and what tech stack language they are using, I'm willing to bet it isn't Ruby or RoR. Their attention is in Javascript or Python or more niche languages like Rust/Elixir/Clojure
it should be that RoR devs get increasing rates as they become rarer but its not, demand is also dwindling as enterprises feel uneasy about banking the future on a smaller talent pool.
But Rust has little to do with what Ruby/Rails is used for, and Python is mostly used in other fields also (it's not like Django is taking over the world). Every time I look at the various JS frameworks it seems like just a huge lift to get something going versus Rails, for typical SME type business problems. Most problems don't really seem to require SPA.
Things like Elixir/Phoenix look very interesting and promising, but their ecosystem is (for now) much smaller. And just the size of the Elixir community right now suggests that it's not like all the RoR developers went to Elixir.
So what is the thing that is so much more attractive than Rails, to solve your everyday business logic issues for small to medium scale problems?
Does all engineers and companies think they are solving Google-scale problems or something?
I feel like I'm missing something obvious.
I don't need an ORM, I don't need ActiveRecord, and I don't need MVC.
I want the framework to be out of my way, which is what FastAPI and ExpressJS provide.
Ruby itself isn't attractive, as a scripting/dynamic language it's worse than Python, therefore no point in using it.
Keep in mind, I don't like Python either, that's why you can trust my opinion since I don't have bias for either or.
The language: Tech companies are becoming more aware of the dangers posed by maintaining and updating large codebases written in an untyped language. I know there's a lot of work still being done in Rubyland on this problem but it feels like the horse left the barn long ago. A lot of Rubyists seem aesthetically opposed to types, including influential language stewards. Sorbet is arguably the Typescript of Rubyland, but it doesn't feel like it's taking off to nearly the same degree. (My theory is that the expressiveness required to support a language as flexible as Ruby results in poor developer ergonomics in terms of the necessary type annotations.)
The ecosystem: Rails is still king, for better and for worse. Back when Rails was in its prime, there weren't as many CRUD web use cases that required marshalling lots of async i/o. Now it's a pretty ubiquitous requirement. You need to fetch data from upstream A and upstream B, then combine them to send back to the client. With Rails, the de facto way to do this is to make these requests serially, which isn't very scalable. Hell, even a single call to a slow remote host can easily end up saturating all of your web workers. Like the types issue, there's a lot of work happening trying to make it easier to perform non-blocking i/o in Ruby/Rails, but it seems like too little too late.
My tiny company is torn between throwing out our ruby code and trying to hire more ruby developers. Our senior ruby guy is leaving, and the one senior candidate we had accepted, then later rejected, our offer. Of the other interviews we have had, candidates were asking for too much (i.e. over $200k base salary) and often barely qualified as a senior, or were simply too inexperienced to replace the person who was leaving.
I'm about one more round of interviews from throwing in the towel and doing a hulkamania hackathon in a new language. The existing code really isn't great either (deprecated gems, lots of accidental complexity, etc) so it is almost tempting to think it would work.
Unfortunately, it's a pretty complex system, and the changes we have slated don't really leave room for updating one endpoint at a time. Even if it were simpler, I don't recall anyone ever contemplating having two ORMs running against the same database without a shudder of horror.
Even having worked for west coast companies, I've never gotten $200k base salary- adjusted for my region, most pay in the $150-175 range, and I've got quite a few years under my belt.
Of course, I don't believe that's the case, but rather that there is a shortage based on it being a relatively unpopular technology compared to java / .net / node / etc.
What about hiring experienced devs and simply giving them an intro Ruby + Rails course? (which could be as simple as say, giving them 2-3 weeks to go through some self-directed learning)
I think companies often do this badly: they hire non-Ruby devs and expect them to learn by osmosis, which usually results devs simply writing a bunch of bad code - for example, Rails code that fights against core Rails assumptions and looks like Java/PHP/etc.
However, I also think it's pretty easy to get it right. If the company and developer have a good attitude about getting the dev immersed in Ruby/Rails a bit before turning them loose on the main codebase. I'm implementing a curriculum like that now in my current role.
Will you be making this public or internal it will remain?
Part 1 - We've gone through "The Well-Grounded Rubyist" and listed most chapters as "learn" and some as "skim". The "skim" chapters are things that are not generally useful for Rails development e.g. explicit threading, file I/O, etc. The idea is that the student should simply know those things are there in case they're needed later.
Part 2 - Same thing with the Rails guide from "Learn Enough To Be Dangerous" from Michael Hartl. We like this option because there's the book and then there are screencasts. So students can pick one or the other to suit their learning style.
Part 3 - Small standalone project of the student's choosing, we have a few suggestions if they don't have any. Something they can finish in a few days.
It is mildly "innovative" in the sense that, for whatever reason, most companies don't seem to do this. Companies I've worked at in the past have had generous onboarding periods, and have given devs lists of learning resources, but generally expect the devs to learn as they go. Which is fundamentally sort of broken, because "learning as they go" typically involves "learning by osmosis from an existing fragile production app that has a lot of tech debt."
I have been working with ruby for 10 years, kind of / sort of thinking of jumping ship to a new company / job soon.
Ruby is not untyped. It's dynamically typed.
FORTH is untyped.
So yes you are correct, but the OP is also very aware it is dynamically typed.
No offence but if someone can't get basic terms right, then maybe they should speak with a little less confidence.
edit: or writing faster than I was thinking? Potato potato.
This (insinuation that dynamic typing is inherently worse to maintain) actually isn't true. There's no evidence proving this. Its one of those things that slowly became common sense and goes unquestioned.
There was a Github repo with scientific publications demonstrating the above. I think it made it to HN a while ago. Wish I could find it now.
If you are learning something new or just graduating, you're way more likely to learn rust/python/javascript as those languages offer something unique (low level speed/machine learning/browser stuff).
Rails used to be miles ahead of the competition, but the competition has largely caught up. Rails is still probably the best choice(in my opinion at least) for building a feature-rich webapp backend quickly unless you've got some crazy unrealistic performance requirements(spoiler: most engineers love to pretend they do, but they probably don't)
But these days there are frameworks everywhere so you can write your backend in whatever you're most comfortable with.
going all the way to tensorflow, google ought to have a lot of interest in the ecosystem to mature.
but event the top story today - https://news.ycombinator.com/item?id=32002057 - were primarily Microsoft engineers
I see a reference to them firing 50 people since April. They are still hiring aggressively, I'm talking to one of their recruiters next week.
Other companies split their stock too.
I think there's no denial that we're in a different economic situation than we were a year or so ago - it's all about how you deal with it