Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Where is Ruby Headed in 2021?

bignerdranch.com

Post reply on HN
Print view View original

151–160 of 360 posts

Re: Where is Ruby Headed in 2021?

#151

Post by joelbluminator »

wraptile wrote: post #102
revskill wrote: post #100

I see Ruby and RoR is the best gateway to become a senior fullstack engineer. I've seen some folks dealing with Java, NodeJS, Python as their first (and only) tech stack and they never become a senior developer one. So, what i love the most from Ruby and RoR is how it helps you on your career path to become a better engineer in a concise way that no other framework/languages can offer you. Learn from what the Ruby/Ro…

Could you elaborate more? Your comment doesn't make much sense otherwise - if anything I'd argue that NOT tying yourself to a single framework is what makes you grow into a senior developer. I'd argue that Python (or similar) back-end and JS-flavor front-end is a better path to growing since it's just a much wider area of growth.

> if anything I'd argue that NOT tying yourself to a single framework is what makes you grow into a senior developer

I disagree. A lot of this discussion is about semantics - what do we mean when we say senior developer? for FAANG they don't really care what languages you know - in fact they don't really seem to care how well you can code, it's all about your ability to solve algorithms under pressure. Is that a senior dev? Guess for them it is.

But for smaller startups - where your ability to code well and onboard fast is critical to the team, when they hire a senior they will most often prefer someone familiar with their stack. So to them, a senior (preferably) has deep knowledge in their stack already (or is good enough to get up to speed really quickly).

Re: Where is Ruby Headed in 2021?

#152

Post by jamil7 »

fiddlerwoaroof wrote: post #88
abstract_put wrote: post #75

Earlier quoted context omitted.

Do you have any specific examples of things that make JS nice that have been lost because of the popularity of TS? As with types in Ruby, I was under the impression nothing was really lost as TS could be added incrementally as developers saw value. I don't think I've talked to anyone who has gotten "over the hump" with TS and felt like they were missing something from JS - I may be in a bubble though. It's almost fru…

I’ve been writing TS for a year now and I find TS annoying. Especially for react components with state management of some kind, the types get so complex you almost need unit tests to assert they are what you think they are. Additionally, TS being a structural type system with no access to nominal types at all eliminates a whole class of “ghosts of departed proofs” modeling techniques. (And, I know you can work around…

I haven’t touched the ecosystem really for a number of years but my last JS project was in TS and I hated it for the same reason. The overhead of bringing in yet more npm modules and types and build steps for questionable levels type safety. Languages with much better type systems exist.

Re: Where is Ruby Headed in 2021?

#153

Post by louissm_it »

kayodelycaon wrote: post #4

This is really cool. I’ve used a number of languages and dabbled in a few frameworks but nothing I’ve used brings me joy like ruby does. I approach programming creatively. I think in large systems and architecture. Ruby allows me to skip worrying about the details. Code blocks abstract away thinking about loops and just focus on data. Just about every array operation I could want is there, waiting for a code block. I…

You nailed it. I work with Ruby, TypeScript (React, Node) and Elixir.

While Elixir has more than enough uses and I love it dearly, nothing comes close to the productivity and expressiveness of Ruby (+ Rails).

I have very high hopes for JS/TS. Using a single isomorphic language for web development must have some benefits, but I'm afraid it's not there yet.

Re: Where is Ruby Headed in 2021?

#154

Post by rhizome31 »

sanderjd wrote: post #110
Buttons840 wrote: post #74

Earlier quoted context omitted.

> I’ve tried python, but I end up having to deal with the mess of importing modules Without those imports, how will people reading the code find the definitions? How will they track down the source code for all the methods being called? If the answer is "with an IDE / tools", then can't those same tools be used to solve the "mess of importing modules"? If you're using a good IDE, imports and go-to-definition are both…

The often impossibility of finding the definition of the methods I'm calling is the main thing that soured me on Rails. I think a more explicit style is more common nowadays, which is a good thing.

I've worked with Ruby in the past and I currently work with Python and Elixir. This is a caveat that Elixir inherited from Ruby. In Elixir there's the `only` option of `import`, but it doesn't seem idiomatic to use it. In Python there's `import *` but it's an actively discouraged practice whereas in Ruby and Elixir it's the norm. I like all three but on this particular point I think Python got it right.

Re: Where is Ruby Headed in 2021?

#155

Post by joelbluminator »

cpursley wrote: post #150
joelbluminator wrote: post #142

Earlier quoted context omitted.

Are you happy with the way things are going for Elixir? It seemed to me like the Elixir community was hoping for it to become the next Ruby and I don't see that happening anymore. It will have to settle for being a well respected but obscure piece of tech, kinda like what Erlang is.

Elixir and Phoneix are more popular than ever, especially with the release of LiveView. The ecosystem and community continues to absorb refugees from Ruby and other stacks. It's such a better platform than Ruby and Rails that I won't bother writing about it here - there are already hundreds of blog posts about it. Productivity is at least on par with Ruby (I believe better) and performance on another plane of existen…

Sorry that really doesn't add up to what I see when I look at job boards, Elixir has really poor numbers. The Ruby guys who wanted to jump ship to Elixir already did so a few years ago (some of them will continue to jump ship from Elixir to Rust or Go because hey why not). So I don't know where new growth will come to Elixir.

It's not just jobs, by any metric you can think of Elixir is an obscure tech, if you want I will add sources to this claim but hopefully we can agree.

Re: Where is Ruby Headed in 2021?

#156

Post by rhizome31 »

inopinatus wrote: post #119
saagarjha wrote: post #118

Earlier quoted context omitted.

I don’t see how this helps?

Ruby's dispatch is Smalltalk-like, not Java-like; it is (very) late-bound. The consequences for interface design are dramatic, the natural style being one in which objects notify each other, rather than telling each other what to do, and the result is loose coupling and ease of composition. People trying to write Java-like OO in Ruby end up confused and frustrated.

I've worked with Java, Ruby and Python but I don't get your point. Can you recommend any resource to help understand what you mean? Or maybe some short examples in Python and Ruby that would highlight how implicit imports allow solving problems in a way that explicit imports prevent?

Re: Where is Ruby Headed in 2021?

#157

Post by rhizome31 »

devoutsalsa wrote: post #112
sanderjd wrote: post #110

Earlier quoted context omitted.

The often impossibility of finding the definition of the methods I'm calling is the main thing that soured me on Rails. I think a more explicit style is more common nowadays, which is a good thing.

“git grep” is pretty amazing for tracking things down.

Of course that's what we end up doing in practice, using external tools (CLI or IDE) to work around a limitation in expressiveness of the language. This advice is a testimony that there's indeed a problem upfront :) And it comes short when searching from commonly used names...

Re: Where is Ruby Headed in 2021?

#158

Post by vidarh »

Mikeb85 wrote: post #8

Honestly I don't get why some people want to move to static types. Ruby is a dynamic language, that's the point of it... Giant orgs can just use Java or something. We need some languages to stay productive for those of us who work solo or in small groups. If I wanted static types I'd use Java, Go or something (probably Haskell).

I don't want a move to enforced static typing everywhere in Ruby. But rbs is relatively non-intrusive. Having the standard library covered by it, and allowing people to tighten up things where they make sense makes it less cumbersome to avoid elsewhere. And it allows those people who feel they need to have type hints everywhere in their IDE to still use Ruby. I find it clutters things up more than it helps, but if it helps others then that's great.

I'm slightly concerned that people will overdo it. E.g. I've more than once wanted to pass an input to something that enforced stricter typing than necessary via guards e.g. checking its input with #kind_of? when it otherwise only needed a class that implemented a sensible #read (for example). But Rubyists are pragmatic - I think after a period of overzealous annotations (the way people went totally overboard with monkey patching for a while) most people will keep the type declarations just loose enough.

Re: Where is Ruby Headed in 2021?

#159

Post by Lio »

grncdr wrote: post #145
sanderjd wrote: post #110

Earlier quoted context omitted.

The often impossibility of finding the definition of the methods I'm calling is the main thing that soured me on Rails. I think a more explicit style is more common nowadays, which is a good thing.

Maybe you already know it, but I find `something.method(:mystery_method).source_location` points me to the right place more often than not. I only mention it because I have noticed a lot of people work productively in Ruby without leveraging it's dynamic/reflective features[0], but little idioms like the above are absolute lifesavers for me. [0]: A big disadvantage of the above is it's not statically resolvable, so y…

The two tools I'd recommend for navigating ruby code in addition to #source_location are Solargraph[1] and, my favourite, good 'ol exuberant ctags[2].

Solargraph is an amazing project but ctags is still just so fast and low overhead that it's what I mostly use.

ctag support is available for most editors and is built into Vim. You need to first generate a tag file (or have an editor plugin do it for you[3]) and then press Ctrl-] to go to definition.

1. https://solargraph.org/

2. http://ctags.sourceforge.net/

3. https://github.com/tpope/gem-ctags

Post reply on HN