4 ms·

I actually think it's both. The language: Tech companies are becoming more aware of the dangers posed by maintaining and updating large codebases written in an

I actually think it's both. 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.

zdragnar 4y ago
To wit, a personal anecdote: 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.
- ezekiel11 4y ago
- notpachet 4y ago
  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.
  - zdragnar 4y ago
    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.
- mulmen 4y ago
  200k for a senior engineer doesn't sound like too much. If anything it sounds like a bargain.
  - zdragnar 4y ago
    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.
    - mulmen 4y ago
      If you can’t hire I question if it is high for your area. I am sympathetic to your position but the market seems to have spoken.
      - zdragnar 4y ago
        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.
- JohnBooty 4y ago
  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.
  - ayewo 4y ago
    > I'm implementing a curriculum like that now in my current role. Will you be making this public or internal it will remain?
    - JohnBooty 4y ago
      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."
- codex_irl 4y ago
  What's the company? (if you don't mind sharing) I have been working with ruby for 10 years, kind of / sort of thinking of jumping ship to a new company / job soon.
LAC-Tech 4y ago
The language: Tech companies are becoming more aware of the dangers posed by maintaining and updating large codebases written in an untyped language. Ruby is not untyped. It's dynamically typed. FORTH is untyped.
- mr_ruby_man 4y ago
  In this circle, untyped is vernacular for languages that don't do static typing as a default. So yes you are correct, but the OP is also very aware it is dynamically typed.
  - LAC-Tech 4y ago
    Is he? No offence but if someone can't get basic terms right, then maybe they should speak with a little less confidence.
    - notpachet 4y ago
      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.
lbrito 4y ago
>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.

zdragnar 4y ago

To wit, a personal anecdote: 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.

ezekiel11 4y ago
notpachet 4y ago
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.
- zdragnar 4y ago
  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.
mulmen 4y ago
200k for a senior engineer doesn't sound like too much. If anything it sounds like a bargain.
- zdragnar 4y ago
  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.
  - mulmen 4y ago
    If you can’t hire I question if it is high for your area. I am sympathetic to your position but the market seems to have spoken.
    - zdragnar 4y ago
      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.
JohnBooty 4y ago
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.
- ayewo 4y ago
  > I'm implementing a curriculum like that now in my current role. Will you be making this public or internal it will remain?
  - JohnBooty 4y ago
    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."
codex_irl 4y ago
What's the company? (if you don't mind sharing) I have been working with ruby for 10 years, kind of / sort of thinking of jumping ship to a new company / job soon.

LAC-Tech 4y ago

The language: Tech companies are becoming more aware of the dangers posed by maintaining and updating large codebases written in an untyped language. Ruby is not untyped. It's dynamically typed. FORTH is untyped.

mr_ruby_man 4y ago
In this circle, untyped is vernacular for languages that don't do static typing as a default. So yes you are correct, but the OP is also very aware it is dynamically typed.
- LAC-Tech 4y ago
  Is he? No offence but if someone can't get basic terms right, then maybe they should speak with a little less confidence.
  - notpachet 4y ago
    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.

lbrito 4y ago

>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.