Live data from Hacker News

Where is Ruby Headed in 2021?

bignerdranch.com

81–90 of 360 posts

Re: Where is Ruby Headed in 2021?

#81
post #10
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).

Mostly, I really want Rails in a typed language.

This is the most frustrating part - having worked in an enterprise Rails project, I wouldn't wish that on anyone valuing their own time. At the same time, it is the most complete offering I've used by a long shot for getting started.

I was writing a web app in Rust (I want to be cool!) and only after a couple hours of implementing CRUD did I realize I'd effectively made an inconsistently implemented rails scaffolding. The default opinionated round trip for DB -> application -> UI for CRUD is still really slick.

Re: Where is Ruby Headed in 2021?

#82
post #9

Earlier quoted context omitted.

> Rust micro services might be the new trend Golang is the trend. (I don't have any opinion in either Golang or Rust; but most jobs out there are looking for Golang microservice deployed in K8S)

If you are really paying attention to the hype train, I think Rust has more energy and blog posts behind it at the current moment. Golang probably gets more use like ruby on rails does.

If you are actually really really paying attention to the hype train, Next.js is actually the trendiest app development tool. Go is a bit more infra and Rust more niche performance cases.

Source:

https://insights.stackoverflow.com/trends?tags=next.js%2Crus...

https://star-history.t9t.io/#rust-lang/rust&golang/go&vercel...

Re: Where is Ruby Headed in 2021?

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

Static typing is awesome because I don't have to just "know" what's being passed in, I can see exactly the structure of it right there. The nice thing too is that another person who has never touched the code can know this as well without reading the entire code base.

Dynamic languages are fine for quick and dirty stuff. For full fledged software, they still make things too difficult to maintain. Javascript to me personally at least attempts to address this with Typescript.

Re: Where is Ruby Headed in 2021?

#84

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 wonder if the "rah-rah" was coming more from business analysts and general sys-admins and less from SWE's or fullstack devs.

Re: Where is Ruby Headed in 2021?

#85
post #62

Earlier quoted context omitted.

I just really like writing silly in/out tests less. Were you writing a bunch of tests to make sure that A is passing arguments of the right type to B? I'm not sure that's a great use of time. If A is passing the wrong thing to B, B will throw a `NoMethodError` anyway once it tries to do anything with the arguments, which will make the spec test fail anyway. But maybe I'm misunderstanding what you mean by "silly in/ou…

You can get away with that if you're writing something for immediate delivery, though I think it leads to a lot of not-my-problem thinking in teams that have to scale. On the other hand, I write a lot of libraries, both for internal and external consumption, and there are a lot of operations, in that context, where you won't get a `NoMethodError`--serialization, for example. You can happily serialize an integer if it…

Those are really good counterexamples and I love your points.

However... just kidding, there's no "however." Great reply.

    You can get away with that if you're writing 
    something for immediate delivery, 
I've worked on some big Rails monoliths and this just wasn't an issue very often.

But as you say, I think library code is another story.

Incidentally, whether library or application code, I've found that keyword arguments with well-chosen names have reduced this problem even further. It's not clear that `do_something("blue")` is incorrect, but `do_something(user_age: "blue")` is self-evidently bad.

Re: Where is Ruby Headed in 2021?

#86

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…

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 that come to love Ruby it feels more natural to think about a program that way as opposed to thinking about a purely lexical context of a piece of code.

Re: Where is Ruby Headed in 2021?

#87

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’m sad about the move to mounds of JavaScript. Nothing can match the productivity of simple_form and bootstrap.

You might like some of the recent Rails 7 previews. I believe they’re removing Webpack out of the box and trying to simplify things on that end[0].

[0] https://weblog.rubyonrails.org/2021/9/15/Rails-7-0-alpha-1-r...

Re: Where is Ruby Headed in 2021?

#88
post #50

Earlier quoted context omitted.

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.

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 this, but those workarounds are ugly.)

My view is that I’d use TS if I have to but I’d pick either plain JS / CLJS or something like purescript if I really wanted types.

Re: Where is Ruby Headed in 2021?

#89

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…

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.

Re: Where is Ruby Headed in 2021?

#90

Earlier quoted context omitted.

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

When it comes to code, I'm fairly certain "correctness" is in fact an irrefutable advantage. The argument has always been whether or not the price of that correctness is too high. But at this point if you're using a modern IDE / code editor (e.g. VSCode), it's actually easier to write statically typed code because the inference / auto-completion / etc is so much better when you do. At least with TypeScript in VSCode.

[deleted]
Post reply on HN