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

101–110 of 360 posts

Re: Where is Ruby Headed in 2021?

#101

Post by stickfigure »

fastball wrote: post #69
emodendroket wrote: post #61

Don't get me wrong. I'm happy to see type declaration support in Ruby and have sorely missed it working on long-lived Rails codebases. But it is pretty funny that after years of rah-rah about how static typing was a pointless barrier to productivity, all the "duck-typing" languages have eventually added it after all.

I think it's less funny and more an endorsement of how good tooling has gotten over the last few years. Intellisense et al. have changed the game so that you can actually be more productive from the start with statically typed languages because the inference (and UX/DX to utilize those inferences) is so much better than with dynamic/duck typing.

Last few years? Java IDEs have been doing this for decades (plural). C++ IDEs for another decade beyond that.

Re: Where is Ruby Headed in 2021?

#102

Post by wraptile »

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.

Re: Where is Ruby Headed in 2021?

#103

Post by revskill »

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.

Updated my original comment to include my story. Once learning Ruby/RoR techstack, you can jump to all other techstack in NO time as it already taught you everything you need. The rest is ecosystem and syntax.

About your concern, other frameworks/languages offer you only part of story, Ruby and RoR offers you complete story in a concise way, it's the difference.

Re: Where is Ruby Headed in 2021?

#104

Post by mykowebhn »

hsn915 wrote: post #72
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 started using dynamic languages since around 2008 (Python and Javascript). Before that I was more into C/C++. Granted, I've only written C in University settings where I'm writing small programs. I had no idea how to write "real" programs. But with Python and Javascript it felt like I could more easily write "real" programs. What I found out is that I quickly burned out. Around 2011 I felt like I don't know how to…

Have you wrangled with JSON using Go? Absolutely dreadful.

Have you written multiple microservices in Go? The lack of an opinionated framework often means that each microservice contains code that is organized in its own unique ad-hoc way with lots of repeated boiler-plate code. The learning-curve to understand how each service's code is organized gets old fast. With Ruby and with RoR I never have to waste time with this and I can get straight to the business logic.

When writing one-off scripts, I can see the advantages of dealing with just structs and functions.

Re: Where is Ruby Headed in 2021?

#105

Post by joelbluminator »

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

Ruby is NOT becoming static. It will just have tools like Sorbet or rbs files. The community will for sure stay mostly in dynamic programming. The huge orgs like Shopify or Stripe who want more strictness will now be able to do it in their Ruby codebases.

Re: Where is Ruby Headed in 2021?

#106

Post by joelbluminator »

eropple wrote: post #12
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).

This is a set of statements that strike me as pretty unreflective of the state of things these days. I have slung a lot of Ruby in my life and I literally-not-figuratively stopped the second I laid my hands on TypeScript because we've hit the point where gradual static typing is both easily available and super easy to work with . (And there's also Rust, which can scratch a whole different set of itches that I don't h…

Out of date how? Tons of people write pure javascript and not typescript. They are all not as productive as you?

Re: Where is Ruby Headed in 2021?

#107

Post by whakim »

JohnBooty wrote: post #95
whakim wrote: post #78

Earlier quoted context omitted.

In my experience this here (usually some method unexpectedly getting passed `nil`) is the single biggest class of bugs in production Ruby applications. Also, what happens when you don't get a NoMethodError? Duck typing is an extremely common practice in Ruby, which means that you can easily run into situations where code "runs" but the output is nonsensical.

In my experience this here (usually some method unexpectedly getting passed `nil`) is the single biggest class of bugs in production Ruby applications. Right, but how do tests help you here? Your specs aren't passing those unexpected nils, and if they were, your specs would fail on the resulting NoMethodError. Static analysis can find these potential problems in a statically typed language - I miss the days when Resh…

> But, this particular comment thread is about addressing this class of bug in Ruby via tests, and my vote would be generally no.

I'm pretty sure I started the comment thread ;).

I think there's a couple of scenarios when a function gets some rogue input (e.g., a string instead of an integer) which then triggers a NoMethodError. I agree that tests don't really help you here - what are you testing, that your method correctly throws a NoMethodError? That being said, to combat this issue you often see dynamically typed codebases littered with scattershot validation, i.e. fail gracefully if you somehow wind up with an unexpected input. And then you often write tests for that. Static typing often obviates these tests, because presumably the rogue input has already been handled further up the call stack. Stubbing is the other issue; I think it happens much more frequently than you suggest that A is tested (stubbing B) and B is tested in isolation; or perhaps there's only one test of A which doesn't stub B, and that test doesn't happen to trigger the NoMethodError.

So I think we're mostly agreeing, but I do think you get to write fewer tests overall.

> It obviously can happen, but I just don't see those name collisions ever happening.

It has happened to me (I think in the Rails context less often) but I agree it's not exactly common. It is deadly when it does, though.

Re: Where is Ruby Headed in 2021?

#108

Post by JBits »

Mikeb85 wrote: post #19
eropple wrote: post #12

Earlier quoted context omitted.

This is a set of statements that strike me as pretty unreflective of the state of things these days. I have slung a lot of Ruby in my life and I literally-not-figuratively stopped the second I laid my hands on TypeScript because we've hit the point where gradual static typing is both easily available and super easy to work with . (And there's also Rust, which can scratch a whole different set of itches that I don't h…

The static languages I've used most are actually Haskell and recently Pony (mostly for things that involve a bunch of maths and processing in parallel). Just brought Go/Java up because it seems everyone is trying to turn every language into those. I don't want Ruby to become another TS because I'd use a typed language if I wanted one. The problems I use Ruby for don't need the speed of a statically typed language and…

Wait, Pony as in https://www.ponylang.io/ ? Since this is the first time I've seen someone bring it up, can I what your experience using it has been like? And also what you were using it for?

Re: Where is Ruby Headed in 2021?

#109

Post by arcanon »

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…

The year is 2021.

People argue for a toolchain that takes a static language, compiles it to a dynamic one, then runs it with an interpreter on the server side.

Humanity ended shortly thereafter.

Re: Where is Ruby Headed in 2021?

#110

Post by sanderjd »

Buttons840 wrote: post #74
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…

> 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.
Post reply on HN