[joelbluminator]

> Right, so either you're working for a struggling company, or you're working on the old stack while things are gradually being migrated and most new stuff is being done in a different stack

Well, currently I'm working for neither. Just a Ruby company that's doing well. I'm sure there's more of them. It's not as if the idea of a rewrite was never thrown, but honestly why would they? It would take years, all the while your old dev team needs to pick up a new language and your new hires need to pick up both Ruby and the rewrite language. If the whole architecture was service oriented that may be not too bad but many Ruby companies are running a few big monoliths. Besides, this whole idea of lack of Ruby jobs seems weird to me especially if you're from North America. Mainland Europe is a different beast though.

[lmm]

Well, if a company is successfully running a Ruby monolith without hitting the scaling problems that would make it start cutting out services to implement in other languages then that suggests the company either hasn't grown past a certain point, or isn't doing anything particularly heavy technically.

[joelbluminator]

That's a controversial topic though. Keep in mind that companies like Github and Shopify showed us it's damn well possible to scale massively with a monolith. But I take your point as being correct, there are quite a few Ruby companies who didn't reach Shopify/Stripe scale (is that a problem though? and if so - why?)

[lmm]

> there are quite a few Ruby companies who didn't reach Shopify/Stripe scale (is that a problem though? and if so - why?)

I think it makes for an environment that may be comfortable, but one where it's harder for a technical person to grow. It's not just about scaling, it suggests the company doesn't have major technical challenges - in which case the company probably isn't technically innovative (which doesn't make it a bad company or a bad business, but does make it a bad environment to pursue a purely technical career). Of course scaling isn't the only way to get interesting technical problems, but I've not seen people favour Ruby for heavy algorithmic work or anything like that either (though I'd stand to be corrected) - rather the great strength of Ruby is rapidly rolling out UI, so it tends to be chosen for problems where the UI is a large proportion of the thing you're building.

[joelbluminator]

> but I've not seen people favour Ruby for heavy algorithmic work or anything like that either

I suppose if Shopify / Github have heavy algorithmic work they do do it in Ruby. I think you have a somewhat different understanding than I do on what software devs do most days. And it doesn't matter if it's php/ruby or java/c++, so many of us, I believe, just glue pieces of business logic together. If you happen to have a problem that's purely algorithmic (let's say finding the shortest path on some map), the first thing most devs I know would do is look for an open source solution for that (and if one doesn't exist in Ruby, you can always wrap it in a Ruby API). That's what I know about most of software engineering, you have a different take (now of course there are different fields like embedded etc which I'm not referring to, I speak only of high level business logic coding).

[lmm]

> I suppose if Shopify / Github have heavy algorithmic work they do do it in Ruby.

I'd be surprised. I'd expect they'll implement it in something else and interface to it in Ruby.

> I think you have a somewhat different understanding than I do on what software devs do most days. And it doesn't matter if it's php/ruby or java/c++, so many of us, I believe, just glue pieces of business logic together. If you happen to have a problem that's purely algorithmic (let's say finding the shortest path on some map), the first thing most devs I know would do is look for an open source solution for that (and if one doesn't exist in Ruby, you can always wrap it in a Ruby API). That's what I know about most of software engineering

I think most software devs spend 95% of their time plumbing together existing things. But I think there's actually a very big difference between that and spending 100% of your time just plumbing together existing things. I wouldn't expect to do serious algorithmic work every day or even every month, but I think if a company is truly technical then it should be doing something that goes a little beyond what's in pre-packaged libraries, and that's often the most fulfilling part of the job.