Live data from Hacker News

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

poignant.guide

201–210 of 213 posts

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

#201
post #175

Earlier quoted context omitted.

Thanks for the insight. I’ll start looking into it more.

Keep in mind opportunity cost. In the average city across the world, I'd say that the order in which you get a job as a developer is: 1. Javascript. 2. Java. 3. Python. 4. C#. 5. C/C++. I'm also weighing each of the against the difficulty of learning the language and the ecosystem. Ruby could be nice but I doubt it breaks top 10 anymore. Your mileage may vary.

I think if you ask ten developers, you'll get ten different rankings like this, with minor overlap :)

It's going to be really really really dependent on your field of work, your career experience and network.

I'm not even going to attempt to offer a top five list, because I'm sure it will be wrong :D

FWIW, I would not base your decision on what language to learn only (or even mainly) based on "what's the most common language in use".

There's more than enough work in the world in all common languages, unless you're talking about really obscure research langs.

There's also value in getting expertise in something more niche - because fewer people know it, you can make a bigger impact and have less competition. It's also a powerful status signal - if you tell me you enjoy working in "Python and Haskell" or "Ruby and Erlang", versus "C# and Java" I'll have a very different impression of you (as unfair as that may be).

In summary, I'd say, try out a few languages, and learn the ones that you enjoy the most and feel most productive in. You'll spend most of your waking hours thinking in it, you might as well pick something that is fun for you to express yourself in, rather than a language that you have to fight.

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

#202

Earlier quoted context omitted.

> A lot of nerd/hacker culture falls into this kind of recognition of unique humor and wit, then squeezing every little drop of joy out of it until it's as empty as a Garfield cartoon. Or maybe they truly enjoy it, and you're also witnessing the lucky 10,000 effect ( https://xkcd.com/1053/ )? I mean, not to be insulting, but talk about humorless . . .

I think the parent was suggesting that if you enjoy something and want to replicate that feeling in others, one won't be able to do it by simply recreating the surface elements without the context of what made it unique. Garfield is a great example. Garfield's initial popularity stemmed from him being a sharp turn from the cat depicted as the "cute, lovable pet". He was fat, judgmental, and sarcastic. Countless movie…

But he mentioned "Rick and Morty" and Monty Python. I myself didn't even see a single episode of "Rick and Morty" until last December when I binged them all at my brother's place. Yeah, I had heard of it, was vaguely aware of the memes, but paid it little attention. When I did finally watch it without having previously been bathed in the hubbub surrounding it, I found it at times darkly funny and deeply touching.

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

#203
post #133

Earlier quoted context omitted.

Broad generalisations incoming: I don't see a lot of new and exciting things being done in Ruby, and I don't think it's a popular choice for highly technical companies any more; even if you find one company doing cool stuff with it, do you want to be looking for a job in 5 years' time having spent 5 years in Ruby? Rails is still the fastest way to bang out a CRUD webapp, and there's a lot of companies who use those w…

Well there's all the companies that were built around 2006-2015 with Ruby, when Rails was hot stuff. Many of them can't afford migrating to a new stack, or want to. But generally I kinda agree - more is being created with other stack nowadays. A byproduct of that is way more people learn Python / Java as a first language, so you also perhaps need to think if being a Python guy gives you any edge when you turn 45-50 a…

> Well there's all the companies that were built around 2006-2015 with Ruby, when Rails was hot stuff. Many of them can't afford migrating to a new stack, or want to.

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. Maybe you'd find a company that is sticking with Ruby because they like it, but that's pretty rare, and probably means that company hasn't scaled past a certain point.

> A byproduct of that is way more people learn Python / Java as a first language, so you also perhaps need to think if being a Python guy gives you any edge when you turn 45-50 as hordes of young people learn it as we speak. Outsourcing a Python project is gonna be way easier 10 years from now than doing the same with Ruby.

Well if it's hard to replace you in your current position then that cuts both ways. So you might be able to find a comfortable position, but there won't be much opportunity for growth.

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

#204
post #203

Earlier quoted context omitted.

Well there's all the companies that were built around 2006-2015 with Ruby, when Rails was hot stuff. Many of them can't afford migrating to a new stack, or want to. But generally I kinda agree - more is being created with other stack nowadays. A byproduct of that is way more people learn Python / Java as a first language, so you also perhaps need to think if being a Python guy gives you any edge when you turn 45-50 a…

> Well there's all the companies that were built around 2006-2015 with Ruby, when Rails was hot stuff. Many of them can't afford migrating to a new stack, or want to. 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. Maybe you'd find a company that is sticking with Ruby because t…

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

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

#205

Earlier quoted context omitted.

I don’t see your point. A large base of Nim users are looking for a pragmatic alternative to the C/C++ family without the aggressive anti-modernism of Go. Nim is certainly not the only player in this realm, but far as I know there isn’t a “Nim Drama” Twitter or tumblr. The drama queen stereotype of Ruby and Rails is very well earned on a repeated basis. All the communities have had their dramas but Ruby and Rust to a…

Hardly anyone uses Nim. It's extremely niche, even compared to something like Rust. That's why there's no Nim infighting. Before you can have dozens of people fighting about a thing, you need more than a dozen people to care about that thing.

Oh believe me. There definitely is infighting. The people doing the infighting just haven’t started trying to involve the wider audience (yet?) :)

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

#206
post #167
post #153

Earlier quoted context omitted.

> It pretty much did, but then Rails and Ruby's hype cycle faded a bit It was Rails' hype cycle that turned me off using Ruby & Rails in the first place. It had more in common with the cult I grew up with than I wanted to be part of, and made it hard for a sceptical outsider to get in. Which is a shame as I think I'd have enjoyed it very much.

I agree. I couldn't stand DHH's "I'm right" attitude about everything. I listened about programming and then he started talking about things I know lots about and I realised he wasn't exactly wrong, just hadn't seen other ways of doing things.

That is still a problem today in Rails. So it is a double edge sword for Ruby and Rails.

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

#207

Earlier quoted context omitted.

There are tons of Ruby jobs: https://stackoverflow.com/jobs?tl=ruby&sort=p https://hnhiring.com/technologies/ruby

Also check out https://hnhiring.com/trends

Thank You!.

So Ruby Rails is bottom of the list.

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

#208
post #203

Earlier quoted context omitted.

> Well there's all the companies that were built around 2006-2015 with Ruby, when Rails was hot stuff. Many of them can't afford migrating to a new stack, or want to. 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. Maybe you'd find a company that is sticking with Ruby because t…

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

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.

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

#209
post #208

Earlier quoted context omitted.

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

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.

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

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

#210
post #208

Earlier quoted context omitted.

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.

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

Post reply on HN