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

41–50 of 360 posts

Re: Where is Ruby Headed in 2021?

#41

Post by friedman23 »

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

> Honestly I don't get why some people want to move to static types

I don't understand how anyone that has experience with dynamically typed languages and the insane runtime errors that can result from them would ever consider using a dynamically typed language. It's terrible and it actually provides little to no benefit in development speed. People always say development is faster in a dynamically typed language, this is not my experience. You need to actually run the program and step into it with a debugger in order to determine the type of anything at run time.

Given the popularity of typescript and how nearly all major internet companies have moved to typed versions of their dynamically typed languages it's clear to me the whole dynamic typing experiment has failed absolutely miserably.

Re: Where is Ruby Headed in 2021?

#42

Post by abstract_put »

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…

I think what the parent comment is saying (that I agree with) is that it's easy to over-estimate the cost and under-estimate the value. You don't _have_ to do anything with types, but it's another tool to use where it makes sense. Or put another way, provided it's not mandatory what's the downside to having another tool in the toolbox?

Re: Where is Ruby Headed in 2021?

#43

Post by tambourine_man »

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…

> But that's a pretty out-of-date take

Gradual/optional static typing are not new ideias. It’s just that they are fashionable now.

It used to be that not having to deal with types at all was the cool place to be in. Our computers were getting so much faster every year, why would performance be a concern? Programmers are more productive in dynamic languages and computer time is cheap, etc, etc.

The “correctness” pitch, the required for larger projects, compiletime vs runtime errors are all discussable, even though they are often thrown in the conversation as irrefutable advantages of static typing.

The performance angle, not so much. Static will almost always be faster then dynamic typing, even with all the crazy tricks we’ve developed over the decades.

Re: Where is Ruby Headed in 2021?

#44

Post by kayodelycaon »

RangerScience wrote: post #23
jamesfinlayson wrote: post #18

Earlier quoted context omitted.

Having used inline typing in PHP and Python I don't really see the benefit of putting it in a separate file either, but when I was reading about it earlier in the year it sounded like Matz wanted types relegated to a separate file, so that's what happened.

My understanding is that this is gentlest possible introduction of types, since you don't have to anything to your existing code. AFAICT the Ruby community is big on gentle iterations, and this is that: enough of type system to start playing with, and to get to the whatever the next step might be.

Sometimes. Ruby 1.8 -> 1.9 was harsh. Forced every string to have an encoding and was absolutely merciless about it; UTF-8 encoding errors everywhere.

In a language where so many things are fast and loose, it seemed like an odd decision, but I agree with it.

Re: Where is Ruby Headed in 2021?

#45

Post by imachine1980_ »

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…

you don't use static type for speed, the first time i write some code in TS(wh compile to js) i typed something of web-storage the editor say this function assume string and you put a num, if i use js i need to run the program to know that. is cool ultra expressive typing(haskell) but you don need nothing so fancy to have huge gains in productivity. ruby and python are grate langues to write scripts and rails make a lot for you but having the compiler take your hand slaps bugs like nothing

Re: Where is Ruby Headed in 2021?

#47

Post by sankha93 »

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 and will be the same language even after static types. A Ruby programmer will need to opt-in to writing type annotations in an external file and run a separate type checker (that is not a part of MRI binary). The benefit is if libraries ship with type definitions, type inference can detect type errors early in the IDE. If no type definitions are available, you do not get ahead of runtime type errors.

Re: Where is Ruby Headed in 2021?

#48

Post by VectorLock »

kayodelycaon wrote: post #46
VectorLock wrote: post #32

I know I'm going to take it on this chin for this but if I'm gonna be honest I hope "away, forever."

Why? Ruby is relatively harmless. Now C… that’s a blight that’s never going away. ;)

I think Python does everything in Ruby's niche but better and Ruby's only benefit is to be different.

Re: Where is Ruby Headed in 2021?

#49

Post by JohnBooty »

abstract_put wrote: post #39
BurningFrog wrote: post #34

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'm not the person you're responding to, but I would say: "yeah, but it'd probably be bad practice."

What would you be testing for, exactly? That `SomeClass#some_method` raises a `NoMethodError` when you pass it the wrong thing?

You could test for that, but I don't think that would be a good use of code or your time. If A is passing the wrong things to B, your specs will fail anyway on that `NoMethodError` once B tries to actually do something with those improper argument(s).

I suppose it could be useful in cases where you'd stubbed out B in your specs, but ehhhh.

Re: Where is Ruby Headed in 2021?

#50

Post by Mikeb85 »

abstract_put wrote: post #42
Mikeb85 wrote: post #19

Earlier quoted context omitted.

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…

I think what the parent comment is saying (that I agree with) is that it's easy to over-estimate the cost and under-estimate the value. You don't _have_ to do anything with types, but it's another tool to use where it makes sense. Or put another way, provided it's not mandatory what's the downside to having another tool in the toolbox?

The downside is the ecosystem turning into the JS/TS ecosystem. Where the zealots have pushed TS to the point it all just looks like C# and what makes JS nice is being lost.
Post reply on HN