Live data from Hacker News

Where is Ruby Headed in 2021?

bignerdranch.com

221–230 of 360 posts

Re: Where is Ruby Headed in 2021?

#221

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…

>Node.js comes so close but anemic standard library The nodejs API is rather big really. If you're using Ruby as your standard of normal sized almost everything would look small in comparison, but "anemic" is a stretch. You'd really hate Lua. If you're taking suggestions, you might enjoy Janet[1]. It has a pretty large user API, lots of bells and whistles included in the standard libs like you'd find in Ruby, and lot…

>If you're taking suggestions, you might enjoy Janet[1].

Just curious about why you'd suggest going from a popular stack to Janet? I'd rather suggest Common Lisp as it's a way more stable, mature and standardized technology.

Re: Where is Ruby Headed in 2021?

#222

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.

Yeah that's been a major pain in my ass more than once, totally get where you're coming from there. One tip for you, and anyone else who might be reading this from the future (hi! do we have flying cars yet? what about time machines? can you bring me one of each, in like, 10 minutes?): RubyMine, the IDE from JetBrains (commercial, Java-based desktop app but not nearly as bad/sluggish as you might expect, though not native fluidity) has a feature to show you where a given method ultimately comes from, going all the way up the chain of source code and abstractions to where it's really defined, including within Rails or other libraries/gems/imported files in a given project. It's a really killer feature for this particular pain point, in my opinion.

Short of that, assuming all your dependencies are unpacked under your project's directory (likely .gitignore'd but there nonetheless, instead of in somewhere like /opt/ or /usr/local/lib or something) you could also `grep -ir 'def method_name' | less` or something to try to figure that out, though it's nowhere near as smooth as RubyMine.

Other editors have Ruby and/or Rails plugins that may help ease this pain point as well, though personally I haven't done anything with that on the editor front in a very, very long time. Generally I'm outright militant about keeping my dependencies to an absolute minimum in a project, and doing everything the most "vanilla" (standard, accepted, most widely adopted patterns, naming conventions, etc.) way possible, and therefore I usually know what gem/lib is providing what particular method, so I don't really need that kind of utility most of the time because I can google up some API docs...when there are API docs anyway.

But in cases where you're having a legacy project/monolith dropped in your lap and nobody knows anything because "the business guy" fired the one developer who actually knew how everything worked and now that guy won't answer his calls because working for free is dumb? Yeah, in those cases, RubyMine or a real good editor plugin can be a lifesaver for this.

Re: Where is Ruby Headed in 2021?

#223
post #76

Earlier quoted context omitted.

A good test suite is better at keeping the code bug free. Not needing types is another benefit of good testing. That's my experience, at least.

I don't think that static typing obviates the need for tests. However: * Static typing catches many kinds of bugs earlier by simply not allowing you to write incorrect code in the first place. * No matter how good your test suite is, you're still putting the burden on the human to always remember to write tests for corner cases. * Static typing allows you have to write many fewer tests by making invalid data unrepres…

If you do TDD, you catch bugs before the code is even written.

I don't write a million tests. There are much better strategies for testing.

Simple tests that just executes the code will catch the vast majority of type mistakes.

Re: Where is Ruby Headed in 2021?

#224

Earlier quoted context omitted.

A good test suite is better at keeping the code bug free. Not needing types is another benefit of good testing. That's my experience, at least.

Do you think it's possible for well used types to displace the need for some tests?

I came the other way. As in, tests displaced types.

Did Java for 13 years. Then moved to Ruby and lost the type system I had leaned so hard on.

After an adjustment period I got into the new groove of just testing all code, and I don't miss my hard typed days at all.

Re: Where is Ruby Headed in 2021?

#225

Earlier quoted context omitted.

Those are fair points, but I just kind of hold the entire program space in my head. I work on a pretty large and complicated Rails app that does real world things (handle money, deal with people and companies, etc) and it's daunting at first but after a while it's sort of become one big system of objects interacting with other objects in a global objectspace and that's how it exists in my head. I think for people tha…

Which isn't to say lexical scope isn't important in a ruby program -- it's paramount, especially for resolving constants -- it's just that after a while it's not that big of a deal that there is some ambiguity about where things come from. For me it's one of the most intuitive languages I've ever worked with but it requires a sense of intuition that is learned over time, as contradictory as that sounds.

It also requires a certain sense of confidence that whoever named that method you're calling gave it a good name. Fortunately (and not, I think, coincidentally) the ruby community has always tended towards good naming being really important.

Re: Where is Ruby Headed in 2021?

#226

Earlier quoted context omitted.

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.

I _much_ prefer Elixir’s way of not using imports much and prefixing most function calls with the module name. That way when I jump to a function definition, I often don’t need to do any further jumping around—I know exactly where everything is coming from right there. I especially hate when language idioms encourage using a shorthand name for the module when importing. Just be explicit!

> [...] I especially hate when language idioms encourage using a shorthand name for the module when importing. Just be explicit!

THIS. 100%!

I also think Python seems to do this better with the namespace pattern of `import x.y.z`. Never seen the `import *` pattern before, didn't know Python can do that (never done Python really though either, only browsed some code here or there).

But one addition to your statement I'd like to add: not just idioms, but documentation can spread this antipattern too.

Noobs come to a language, read the documentation for some tool, library, etc., and understandably come away thinking "Oh ok, this is how it's done" when in reality, while they're not doing anything wrong per se, they're being taught a bad habit right off the bat. And that makes the inevitable hard slap across the face that reality (or a co-worker) eventually hits you with all the more shocking, possibly even leading to resentment of others when this happens.

I myself had this problem many years ago; "why the hell do you need all these subclasses and so many layers of abstraction?!" I once asked. "Because those class/method names already exist within other classes loaded at runtime, or will likely be added in future external dependencies, and we don't want to accidentally overwrite those."

Well, I thought that was a stupid idea. In my (very limited at the time) experience, when I had that problem, I just insisted on finding a damn good descriptive name that wasn't going to be used for anything else, even if it was wicked long or a pain to type. Too long? Don't be lazy. Typos more probable with length? Learn to copy/paste. That was the approach I learned at some point from some documentation somewhere on the internet, and it always worked for me, so it was the "one true path" and all others were inferior, making proponents or users/adherents of any other way "wrong" and inferior to me and my superior, non-lazy intellect. You're telling me that you do it differently? You must be stupid or lazy, and I'm neither therefore I'm better than you; thus forcing me to adopt your inferior standard?! Preposterous! Insulting! Offensive! That's how I saw it.

God, was I dumbass.

I developed this attitude by learning my skills in a near total vacuum, other than documentation written by people on the internet back in the 90's. Not official company-published technical docs, mind you, but forum and BBS posts, mailing list discussions, and way too much IRC to be considered "healthy" by any stretch of the imagination.

Those who taught me did so in a way that was efficient and they did no wrong at all of course - this failure was entirely of my own making, from my own arrogance. But it's also true that had I been taught at the same time that "there are other ways in other languages that are totally valid; this is just for simplicity's sake" and then been shown, or better yet required to use other patterns in school/projects/etc., I might have been able to see the short-sightedness of my own arrogance sooner. Instead, it resulted in an antipattern that allowed me to become overconfident, arrogant, and more difficult to work with than I should've been.

----------

In case you're wondering, I can't remember what I read or where that came from so long ago. Sorry. Might have been C, C++, Java, DOS BASIC (non-GUI/non-Windows), Visual Basic (before .NET) or maybe even PHP 3.something, no idea - that was 20+ years ago. I was inexperienced, arrogant, and a fool; none of that was the author's fault whatsoever. We're all young and stupid at some point in life. I'm no longer young, but at least now I know I'm stupid! :-)

Re: Where is Ruby Headed in 2021?

#227

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 It's funny, the fact that Ruby doesn't have a facility to import modules is one of my biggest gripes with it. Instead of importing into a specific scope, the global namespace becomes a dumping ground for anything that has ever been loaded, and you need something like Zeitwerk to do auto-loading for you. Which I guess can be seen as a…

I have mixed feelings about autoloading. I never use it for my own stuff, ever: explicit `require`s all the way. But I do appreciate not needing the boilerplate in Rails.

It would have been nice to be able to do something like: `MyActiveRecordImport = require('activerecord')` to take control of the constant name, but honestly it's not something I hugely miss.

Re: Where is Ruby Headed in 2021?

#228

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 used a number of languages and dabbled in a few frameworks but nothing I’ve used brings me joy like ruby does. Totally agree, 100%. Ruby isn't "perfect", but it's a pleasure to use. As in, I actually want to use it, not just am "ok" or ambivalent about it. I have my nitpicks about Ruby, about Rails and other things just like anyone, but I second your comment that nothing else has been able to match that…

I wonder why Crystal is not more popular today that it reached 1.X, as you say, it fixes some important Ruby issues but most importantly it also fixes Elixir's weaker points.

Re: Where is Ruby Headed in 2021?

#229

Earlier quoted context omitted.

I would argue that’s anything. I started by web service development career in C# and moved to Python and Rails was easy enough to figure out except for the magic junk. Most systems use similar-enough patterns you can carry them over where-ever. It doesn’t have to be rails, but it was for you.

Because the ease of installation of Ruby, RoR and deployment to Heroku. It's cross-platform. So u can bring your application to production in like 30 mins. In era 2010, .NET stack couldn't offer you that. I wrote about 4 production application in Ruby stack in 6 months, it's super productive and the Ruby language has OOP/FP done right in comparison of other languages, too.

The only reason this seems special to you is because its your story. Your story could have happened with a lot of different languages though.

Re: Where is Ruby Headed in 2021?

#230
post #72
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…

Dynamic languages start becoming problematic as more the size of the codebase increases. It becomes very hard to maintain.
Post reply on HN