Live data from Hacker News

Why's (Poignant) Guide to Ruby (2004)

poignant.guide

211–213 of 213 posts

Re: Why's (Poignant) Guide to Ruby (2004)

#211
post #210

Earlier quoted context omitted.

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?)

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

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

Re: Why's (Poignant) Guide to Ruby (2004)

#213
post #210

Earlier quoted context omitted.

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

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

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

Post reply on HN